james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: JAMES technology uplift
Date Wed, 02 May 2007 15:50:47 GMT
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

>> 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?) ?


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

View raw message