Noel J. Bergman ha scritto: > JMX, and I agree that we as long as we're going to do this uplift, we should > make sure that we provide appropriate JMX support. And see also JSR-138.
Can you elaborate on JSR-138 ? I never heard of it, and from a fast google search I only found Oracle had an implementation in 2001... no news since that. >> From my experience EJB incl. MDB does _not_ open options for >> deplyoment, they _narrow_ them. > > I meant that it could be deployed in "any" EJB server. Yes, right. But.. any J2SE application can be deployed in a J2EE server. The opposite is not always true. So, requiring an J2EE environment is more narrow than requiring a J2SE environment. >> You would need an EJB container, and add much more footprint by the >> way than by adding a JMS implementation. > > Actually, we'd have to compare the footprint of Phoenix vs OpenEJB as a > standalone container. Or Spring, or OSGi, or Spring-OSGi or anything else. >> There are so many lightweight and more flexible component models. > > And none of them standard. As I understood Danny and a couple of others, > the goal is to lower the barrier to acceptance by being able to package > JAMES such that it looks as if they are just installing yet another > application into their existing application server. I'm not a big fan of "standards" in themselves. Some standard, like EJB2 , has been a big failure (IMHO). EJB3 is much better, but again, I would prefer to simply choose single standards (like JCR/JMS) instead of a full stack (like J2EE) and to simply bundle our own implementation choince (Jackrabbit/ActiveMQ). This would be a step in the right direction, imho. >> +1 for the basic architectural approach. > >> But. What is completely missing is the important glue in between. The >> APIs which describe how components interact and what each component >> does. And I am not satisfied how it is done ATM. The object model >> would need to be revisited nevertheless. > > The glue between most of them would be the JCR. Depending upon how the > spooler is deployed, JMS or similar event driver can initiate pipeline > processing. > > How much should be in the Mailet API, or just documented use of other > subsystems (e.g., JCR), is TBD. > > --- Noel First let's see working things. After that, we will define what part deserve standardization and to become part of an API. Before spending time in virtual analysis of a possible plan imho we should know who will work on what. Is there anyone willing to try implementing the JCR POC ? Imho a small SEDA tool reading a writing thousands of concurrent, randomly sized, mime messages to Jackrabbit would be a good POC. Is there any other thing to be proved by the POC (like searching capabilities? queue management?) ? Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
