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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
