james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anne S <hyperfl...@gmail.com>
Subject Re: Proposal for Web Admin Console
Date Fri, 17 Jun 2005 16:14:31 GMT
Oy, oy, oy people! Let's not forget that I haven't been accepted yet!
No code has been laid down as of yet, so we can discuss this to our
heart's content. (Although, maybe somebody could slip a kind word to
the Apache people deciding on SOC projects about this project, that
would be much appreciated ;-) )

I'm perfectly comfortable speaking to JMX if need be, but as Jason
noted, security is a big issue. I'll explore the docs for JMX and see
what can be done.

And no, as Noel pointed out, the webapp should NOT be the final word
on the management of James. Somebody may prefer to write another
management app in the future for some reason, or integrate James
support into an existing package. Giving future developers an API
would be a terrific springboard for them. Opening up a servlet
container for each process is definitely a waste of memory.

As for the Tomcat embedded vs. Jetty, a quick look at the docs for
both shows that embedded Tomcat is a 2.8 MB download, while Jetty's
homepage claims to be able to provide a fully functioning server in a
350 KB jar file. Can anybody explain the big difference in size, and
if it's important for our uses?



On 6/17/05, Noel J. Bergman <noel@devtech.com> wrote:
> Juan Carlos Murillo wrote:
> 
> > I understood that Avalon was in the process of being replaced by Spring
> > as the Container.
> 
> I would sooner use the Geronimo microkernel than Spring.
> 
> > > However, I don't believe that we want to embed a web container with
> JAMES.
> > > Rather, I feel that we want to enhance our primitive JMX support, and
> have
> > > administration tools use that interface.
> 
> > I understand the issues for not wanting to embed the servlet container
> 
> Actually, I am not sure that everyone yet fully grasps all of the issues.
> JAMES is currently a single process, but once we have multiple managed
> processes: SMTP handler(s), POP3 handler(s), pipeline processor(s), etc., we
> need JMX support embedded in each managed process.  For a standalone JAMES,
> we could look at embedding the web container in the JAMES process, but that
> won't be scalable.  We don't want to embed a web container and admin webapp
> in each managed process, nor would that provide a satisfactory UI, nor
> should a webapp be the only management interface.
> 
> What we're look at probably lays out as:
> 
>   - JMX support w/MBeans embedded in each managed process
>   - Admin service (model)
>   - Admin webapp in a web container of the user's choice
>   - Admin script interface (uses BSF)
> 
> where the webapp and script interface are just clients of the admin service.
> For Anne's purposes, since she has a defined timeframe and task, as long as
> she talks to JMX, we're probably fine, and later refactoring can handle
> remaining issues.
> 
>         --- Noel
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message