You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2007/05/02 12:10:38 UTC
JAMES technology uplift
So we're talking about a major technology uplift for JAMES. One piece being
talked about is the replacement of our data store with JCR. There are
others ...
Conceptually, JAMES is made up of the following pieces:
- Wire level protocol handlers, which break down into:
- Incoming Message Acceptors (e.g., SMTP)
- Incoming Message Providers (e.g., POP3)
- Outgoing Message Delivery (e.g., RemoteDelivery)
- Data store
- Mailet Container
The data store, e.g., JCR, is shared across space.
The parts can be implemented as POJOs, but they need to know how to
communicate. We need to balance flexibility with implementation of random
ad hoc interfaces. For example, if we adopt JCR, we should document how we
are using it, and provide some convenience wrappers for common things that
we do, but we should not try to create another abstraction for storage. The
JCR *would be* the abstraction. Period. In other areas, POJOfication
allows a lot of flexibility, but we still have to build a working server.
Danny raised an interesting idea, which would be to host the mailet pipeline
in an EJB container, e.g., OpenEJB. My revised spooler notes from way back
when also made some mention of the possibility of using an MDB, but I hadn't
really given much thought to actually running JAMES in an EJB container.
However, although there may be some initial resistance, it does make some
sense. For one thing, it provides a standard platform for JAMES, and opens
up lots of options for deployment. So how might this work?
Once the SMTP server has put the message into JCR, a JMS message can be sent
to a destination attached to an MDB, which in turn invokes the spool manager
to start processing the message. By providing two standalone methods:
message storage (JCR) and messge processing initiation (JMS), any Java code
could provide messages for a pipeline. A pipeline, not *the* pipeline,
because the JMS destination would be a configurable means to determine where
the message starts processing.
Internally, the spooler can be implemented however it wants to be
implemented. We need to have an implementation, but someone could provide
their own if they were so inclined. The Mailet container breaks down to:
- Spooler: mechanism for moving messages amongst units of work
- Processor: addressable unit of work
- Mailet/Matcher: actual workers
There needs to be (re-)scheduling, too, as described in my revised spooler
notes. I have though to implement scheduling as a shared service provided
by a mailet, but it could be moved into a formally defined part of the
Mailet Container environment.
So the touching points can be quite small: JCR for a unified data model, and
some means of initiating message processing (JMS or other, as appropriate
for whatever hosts the spooler).
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann ha scritto:
> From my experience EJB incl. MDB does _not_ open options for
> deplyoment, they _narrow_ them.
> You would need an EJB container, and add much more footprint by the
> way than by adding a JMS implementation.
>
> There are so many lightweight and more flexible component models.
> Spring also offers lightweight messaging, transactions etc.
+1
> One important observation to add: We are talking about general
> architectural overview and what backends to use for some concerns
> (storage, message proc).
>
> 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.
>
> Bernd
I agree.
I guess Noel was suggesting that SMTP server communicate with the main
spooler/container via JMS/JCR apis. I'm not completely convinced by this
idea: maybe we need much simpler contracts for message submission and
jms/jcr can be used to write exchangeable implementations.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by Stefano Bagnara <ap...@bago.org>.
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: JAMES technology uplift
Posted by "Noel J. Bergman" <no...@devtech.com>.
Bernd Fondermann wrote:
> other important parts are
> - User DB
Subsumed by "data store", at least for the moment.
> - Server Management
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.
> - Message Orchestration
If I understand your meaning, this is subsumed by "Mailet Container".
> > However, although there may be some initial resistance, [running
> > JAMES in an EJB container] does make some sense. For one thing,
> > it provides a standard platform for JAMES, and opens up lots of
> > options for deployment.
> 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.
> 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.
> 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.
> +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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by Bernd Fondermann <be...@googlemail.com>.
On 5/2/07, Noel J. Bergman <no...@devtech.com> wrote:
> So we're talking about a major technology uplift for JAMES. One piece being
> talked about is the replacement of our data store with JCR. There are
> others ...
>
> Conceptually, JAMES is made up of the following pieces:
>
> - Wire level protocol handlers, which break down into:
> - Incoming Message Acceptors (e.g., SMTP)
> - Incoming Message Providers (e.g., POP3)
> - Outgoing Message Delivery (e.g., RemoteDelivery)
>
> - Data store
>
> - Mailet Container
other important parts are
- User DB
- Server Management
- Message Orchestration
> The parts can be implemented as POJOs, but they need to know how to
> communicate. We need to balance flexibility with implementation of random
> ad hoc interfaces. For example, if we adopt JCR, we should document how we
> are using it, and provide some convenience wrappers for common things that
> we do, but we should not try to create another abstraction for storage. The
> JCR *would be* the abstraction. Period. In other areas, POJOfication
> allows a lot of flexibility, but we still have to build a working server.
+1 (minus the "Period:")
> Danny raised an interesting idea, which would be to host the mailet pipeline
> in an EJB container, e.g., OpenEJB. My revised spooler notes from way back
> when also made some mention of the possibility of using an MDB, but I hadn't
> really given much thought to actually running JAMES in an EJB container.
> However, although there may be some initial resistance, it does make some
> sense. For one thing, it provides a standard platform for JAMES, and opens
> up lots of options for deployment. So how might this work?
>From my experience EJB incl. MDB does _not_ open options for
deplyoment, they _narrow_ them.
You would need an EJB container, and add much more footprint by the
way than by adding a JMS implementation.
There are so many lightweight and more flexible component models.
Spring also offers lightweight messaging, transactions etc.
> Once the SMTP server has put the message into JCR, a JMS message can be sent
> to a destination attached to an MDB, which in turn invokes the spool manager
> to start processing the message. By providing two standalone methods:
> message storage (JCR) and messge processing initiation (JMS), any Java code
> could provide messages for a pipeline. A pipeline, not *the* pipeline,
> because the JMS destination would be a configurable means to determine where
> the message starts processing.
> Internally, the spooler can be implemented however it wants to be
> implemented. We need to have an implementation, but someone could provide
> their own if they were so inclined. The Mailet container breaks down to:
>
> - Spooler: mechanism for moving messages amongst units of work
> - Processor: addressable unit of work
> - Mailet/Matcher: actual workers
>
> There needs to be (re-)scheduling, too, as described in my revised spooler
> notes. I have though to implement scheduling as a shared service provided
> by a mailet, but it could be moved into a formally defined part of the
> Mailet Container environment.
>
> So the touching points can be quite small: JCR for a unified data model, and
> some means of initiating message processing (JMS or other, as appropriate
> for whatever hosts the spooler).
+1 for the basic architectural approach.
One important observation to add: We are talking about general
architectural overview and what backends to use for some concerns
(storage, message proc).
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.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by David Blevins <da...@visi.com>.
On May 2, 2007, at 10:29 PM, David Blevins wrote:
>
> On May 2, 2007, at 3:36 AM, Stefano Bagnara wrote:
>
>> Noel J. Bergman ha scritto:
>>> [..]
>>> Conceptually, JAMES is made up of the following pieces:
>>>
>>> - Wire level protocol handlers, which break down into:
>>> - Incoming Message Acceptors (e.g., SMTP)
>>> - Incoming Message Providers (e.g., POP3)
>>> - Outgoing Message Delivery (e.g., RemoteDelivery)
>>
>> We have all of them (you forgot fetchmail)
>> - Outgoing messages via PUSH model (remotedelivery)
>> - Outgoing messages via POP model (pop3server/imapserver)
>> - Incoming messages via PUSH model (smtpserver)
>> - Incoming messages via POP model (fetchmail)
>>
>>> [...]
>>> The parts can be implemented as POJOs, but they need to know how to
>>> communicate. We need to balance flexibility with implementation
>>> of random
>>> ad hoc interfaces. For example, if we adopt JCR, we should
>>> document how we
>>> are using it, and provide some convenience wrappers for common
>>> things that
>>> we do, but we should not try to create another abstraction for
>>> storage. The
>>> JCR *would be* the abstraction. Period. In other areas,
>>> POJOfication
>>> allows a lot of flexibility, but we still have to build a working
>>> server.
>>
>> About JCR being the abstraction "period", I would say.. "maybe comma"
>> ;-) Let's see it working before placing periods.
>>
>>> Danny raised an interesting idea, which would be to host the
>>> mailet pipeline
>>> in an EJB container, e.g., OpenEJB. My revised spooler notes
>>> from way back
>>> when also made some mention of the possibility of using an MDB,
>>> but I hadn't
>>> really given much thought to actually running JAMES in an EJB
>>> container.
>>> However, although there may be some initial resistance, it does
>>> make some
>>> sense. For one thing, it provides a standard platform for JAMES,
>>> and opens
>>> up lots of options for deployment. So how might this work?
>>>
>>> Once the SMTP server has put the message into JCR, a JMS message
>>> can be sent
>>> to a destination attached to an MDB, which in turn invokes the
>>> spool manager
>>> to start processing the message. By providing two standalone
>>> methods:
>>> message storage (JCR) and messge processing initiation (JMS), any
>>> Java code
>>> could provide messages for a pipeline. A pipeline, not *the*
>>> pipeline,
>>> because the JMS destination would be a configurable means to
>>> determine where
>>> the message starts processing.
>>
>> So you revamped JMS, too ;-)
>>
>> I'm fine with JCR and JMS (if they satisfy our requisites). I
>> prefer to
>> not require a full J2EE stack for running it.
>
> Just an FYI, OpenEJB is extremely non-intrusive and it's very easy
> to use as "just a library" in various ways. We of course support
> the standard "setup the server, put apps in server" model, but the
> "put ejb container into the app" is just really handy in many a
> case; junit test cases for one, but also for projects that are more
> or less platforms themselves and aren't interested in loosing the
> spot of top dog :)
>
> Don't know what you all had in mind, but I figured I'd let you know
> that it is possible to invert the whole container/app relationship
> with OpenEJB.
Here we go, here's a small example that configures/creates a stateful
container and related support (transaction, security, jca connection
manager) and then deploys an bean in and immediately looks it up and
invokes it. No config files required, you get full programatic
control if you want it.
http://fisheye6.cenqua.com/browse/openejb/trunk/openejb3/container/
openejb-core/src/test/java/org/apache/openejb/core/stateful/
Compat3to2Test.java
This example doesn't use business interfaces, but you probably
wouldn't use session beans anyway (guessing MDBs) unless you wanted
to write say an admin console that you could wrap with fat client,
web, or web services front ends.
Ok, I'll leave you alone now :)
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by Søren Hilmer <sh...@widetrail.dk>.
On Thu, May 3, 2007 11:40, Bernd Fondermann wrote:
> On 5/3/07, Søren Hilmer <sh...@widetrail.dk> wrote:
>> Hi,
>>
>> Well, just thinking, this being ASF. Shouldn't we eat our own dogfood,
>> and
>> go for Geronimo as our default deployment if/when we choose to take the
>> EJB-container road?
>
> I'd rather be able to deploy to Geronimo _and_ other containers.
> OpenEJB by the way is Geronimo's standard EJB container and currently
> applying for becoming top-level ASF.
Was not aware of that, thanks for the info!
>
>>
>> Also I might be wrong, but as we talk directly to the network, the
>> authorized way to integrate into an EJB container is through a JCA
>> adapter, and they are kind of beastly to implement :-)
>
> Unfortunately, you aren't wrong :-)
No, actually I did not believe I was :-)
>
> Bernd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
--
Søren Hilmer, M.Sc., M.Crypt.
wideTrail Phone: +45 25481225
Pilevænget 41 Email: sh@widetrail.dk
DK-8961 Allingåbro Web: www.widetrail.dk
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by robert burrell donkin <ro...@gmail.com>.
On 5/6/07, David Blevins <da...@visi.com> wrote:
>
> On May 6, 2007, at 6:26 AM, robert burrell donkin wrote:
>
> > On 5/3/07, David Blevins <da...@visi.com> wrote:
> >>
> >> On May 3, 2007, at 2:55 AM, Søren Hilmer wrote:
> >> > On Thu, May 3, 2007 11:40, Bernd Fondermann wrote:
> >> >> On 5/3/07, Søren Hilmer <sh...@widetrail.dk> wrote:
> >> >>>
> >> >>> Also I might be wrong, but as we talk directly to the network,
> >> the
> >> >>> authorized way to integrate into an EJB container is through a
> >> JCA
> >> >>> adapter, and they are kind of beastly to implement :-)
> >> >>
> >> >> Unfortunately, you aren't wrong :-)
> >> >
> >> > No, actually I did not believe I was :-)
> >>
> >> They can definitely get a little convoluted, but you wouldn't need to
> >> support transacted delivery, security or outbound connections which
> >> does cut the problem space down considerably. It'd definitely be a
> >> doable task. If you were to try it I'd recommend liberally swiping
> >> ActiveMQ's Resoure Adapter code and just start tearing out bits and
> >> reworking it for James. I'm sure they have unit tests for it and
> >> everything.
> >>
> >> It's actually something I've hoped would happen. I know at some
> >> apachecon a couple years ago I cornered some poor JAMES developer and
> >> bored him for a good 45 minutes on the benefits of having a JAMES JCA
> >> adapter so people could write MDBs that consumed email. Ok... so
> >> maybe I did that more than once :)
> >
> > there are some interesting possibilities in this area both inbound
> > and outbound
>
> I never really considered outbound as javamail sessions are already a
> built-in supported type for javaee. What kind of neat things do you
> imagine?
both advanced and integrated email capabilities in java including
mix'n'match busing
rather than posting an email to a particular server using a particular
protocol, post to a mail queue. this could be the input spool of an
embedded email server, transport (either using a conventional email
protocol or a mail bus) to a remote email server or just another mail
to be processed by an MDB or mailet in a container (either local or
remote).
being protocol agnostic has a lot of advantages given the progress
which has been made on buses. shouldn't matter whether the mail is
transported through SMTP, IMAP, web services, JMS, HTTP or whatever.
the java developer should just post'n'go.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by David Blevins <da...@visi.com>.
On May 6, 2007, at 6:26 AM, robert burrell donkin wrote:
> On 5/3/07, David Blevins <da...@visi.com> wrote:
>>
>> On May 3, 2007, at 2:55 AM, Søren Hilmer wrote:
>> > On Thu, May 3, 2007 11:40, Bernd Fondermann wrote:
>> >> On 5/3/07, Søren Hilmer <sh...@widetrail.dk> wrote:
>> >>>
>> >>> Also I might be wrong, but as we talk directly to the network,
>> the
>> >>> authorized way to integrate into an EJB container is through a
>> JCA
>> >>> adapter, and they are kind of beastly to implement :-)
>> >>
>> >> Unfortunately, you aren't wrong :-)
>> >
>> > No, actually I did not believe I was :-)
>>
>> They can definitely get a little convoluted, but you wouldn't need to
>> support transacted delivery, security or outbound connections which
>> does cut the problem space down considerably. It'd definitely be a
>> doable task. If you were to try it I'd recommend liberally swiping
>> ActiveMQ's Resoure Adapter code and just start tearing out bits and
>> reworking it for James. I'm sure they have unit tests for it and
>> everything.
>>
>> It's actually something I've hoped would happen. I know at some
>> apachecon a couple years ago I cornered some poor JAMES developer and
>> bored him for a good 45 minutes on the benefits of having a JAMES JCA
>> adapter so people could write MDBs that consumed email. Ok... so
>> maybe I did that more than once :)
>
> there are some interesting possibilities in this area both inbound
> and outbound
I never really considered outbound as javamail sessions are already a
built-in supported type for javaee. What kind of neat things do you
imagine?
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by robert burrell donkin <ro...@gmail.com>.
On 5/3/07, David Blevins <da...@visi.com> wrote:
>
> On May 3, 2007, at 2:55 AM, Søren Hilmer wrote:
> > On Thu, May 3, 2007 11:40, Bernd Fondermann wrote:
> >> On 5/3/07, Søren Hilmer <sh...@widetrail.dk> wrote:
> >>>
> >>> Also I might be wrong, but as we talk directly to the network, the
> >>> authorized way to integrate into an EJB container is through a JCA
> >>> adapter, and they are kind of beastly to implement :-)
> >>
> >> Unfortunately, you aren't wrong :-)
> >
> > No, actually I did not believe I was :-)
>
> They can definitely get a little convoluted, but you wouldn't need to
> support transacted delivery, security or outbound connections which
> does cut the problem space down considerably. It'd definitely be a
> doable task. If you were to try it I'd recommend liberally swiping
> ActiveMQ's Resoure Adapter code and just start tearing out bits and
> reworking it for James. I'm sure they have unit tests for it and
> everything.
>
> It's actually something I've hoped would happen. I know at some
> apachecon a couple years ago I cornered some poor JAMES developer and
> bored him for a good 45 minutes on the benefits of having a JAMES JCA
> adapter so people could write MDBs that consumed email. Ok... so
> maybe I did that more than once :)
there are some interesting possibilities in this area both inbound and outbound
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by Bernd Fondermann <bf...@brainlounge.de>.
David Blevins wrote:
>
> On May 3, 2007, at 2:55 AM, Søren Hilmer wrote:
>> On Thu, May 3, 2007 11:40, Bernd Fondermann wrote:
>>> On 5/3/07, Søren Hilmer <sh...@widetrail.dk> wrote:
>>>>
>>>> Also I might be wrong, but as we talk directly to the network, the
>>>> authorized way to integrate into an EJB container is through a JCA
>>>> adapter, and they are kind of beastly to implement :-)
>>>
>>> Unfortunately, you aren't wrong :-)
>>
>> No, actually I did not believe I was :-)
>
> They can definitely get a little convoluted, but you wouldn't need to
> support transacted delivery, security or outbound connections which does
> cut the problem space down considerably. It'd definitely be a doable
> task. If you were to try it I'd recommend liberally swiping ActiveMQ's
> Resoure Adapter code and just start tearing out bits and reworking it
> for James. I'm sure they have unit tests for it and everything.
>
> It's actually something I've hoped would happen. I know at some
> apachecon a couple years ago I cornered some poor JAMES developer and
> bored him for a good 45 minutes on the benefits of having a JAMES JCA
> adapter so people could write MDBs that consumed email. Ok... so maybe
> I did that more than once :)
I agree it would be cool for many users.
We are getting nearer to it rather slowly.
But please stay tuned...
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by David Blevins <da...@visi.com>.
On May 3, 2007, at 2:55 AM, Søren Hilmer wrote:
> On Thu, May 3, 2007 11:40, Bernd Fondermann wrote:
>> On 5/3/07, Søren Hilmer <sh...@widetrail.dk> wrote:
>>>
>>> Also I might be wrong, but as we talk directly to the network, the
>>> authorized way to integrate into an EJB container is through a JCA
>>> adapter, and they are kind of beastly to implement :-)
>>
>> Unfortunately, you aren't wrong :-)
>
> No, actually I did not believe I was :-)
They can definitely get a little convoluted, but you wouldn't need to
support transacted delivery, security or outbound connections which
does cut the problem space down considerably. It'd definitely be a
doable task. If you were to try it I'd recommend liberally swiping
ActiveMQ's Resoure Adapter code and just start tearing out bits and
reworking it for James. I'm sure they have unit tests for it and
everything.
It's actually something I've hoped would happen. I know at some
apachecon a couple years ago I cornered some poor JAMES developer and
bored him for a good 45 minutes on the benefits of having a JAMES JCA
adapter so people could write MDBs that consumed email. Ok... so
maybe I did that more than once :)
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by Søren Hilmer <sh...@widetrail.dk>.
On Thu, May 3, 2007 11:40, Bernd Fondermann wrote:
> On 5/3/07, Søren Hilmer <sh...@widetrail.dk> wrote:
>> Hi,
>>
>> Well, just thinking, this being ASF. Shouldn't we eat our own dogfood,
>> and
>> go for Geronimo as our default deployment if/when we choose to take the
>> EJB-container road?
>
> I'd rather be able to deploy to Geronimo _and_ other containers.
> OpenEJB by the way is Geronimo's standard EJB container and currently
> applying for becoming top-level ASF.
Was not aware of that, thanks for the info!
>
>>
>> Also I might be wrong, but as we talk directly to the network, the
>> authorized way to integrate into an EJB container is through a JCA
>> adapter, and they are kind of beastly to implement :-)
>
> Unfortunately, you aren't wrong :-)
No, actually I did not believe I was :-)
>
> Bernd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
--
Søren Hilmer, M.Sc., M.Crypt.
wideTrail Phone: +45 25481225
Pilevænget 41 Email: sh@widetrail.dk
DK-8961 Allingåbro Web: www.widetrail.dk
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by Søren Hilmer <sh...@widetrail.dk>.
On Thu, May 3, 2007 11:40, Bernd Fondermann wrote:
> On 5/3/07, Søren Hilmer <sh...@widetrail.dk> wrote:
>> Hi,
>>
>> Well, just thinking, this being ASF. Shouldn't we eat our own dogfood,
>> and
>> go for Geronimo as our default deployment if/when we choose to take the
>> EJB-container road?
>
> I'd rather be able to deploy to Geronimo _and_ other containers.
> OpenEJB by the way is Geronimo's standard EJB container and currently
> applying for becoming top-level ASF.
Was not aware of that, thanks for the info!
>
>>
>> Also I might be wrong, but as we talk directly to the network, the
>> authorized way to integrate into an EJB container is through a JCA
>> adapter, and they are kind of beastly to implement :-)
>
> Unfortunately, you aren't wrong :-)
No, actually I did not believe I was :-)
>
> Bernd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
--
Søren Hilmer, M.Sc., M.Crypt.
wideTrail Phone: +45 25481225
Pilevænget 41 Email: sh@widetrail.dk
DK-8961 Allingåbro Web: www.widetrail.dk
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by Søren Hilmer <sh...@widetrail.dk>.
On Thu, May 3, 2007 11:40, Bernd Fondermann wrote:
> On 5/3/07, Søren Hilmer <sh...@widetrail.dk> wrote:
>> Hi,
>>
>> Well, just thinking, this being ASF. Shouldn't we eat our own dogfood,
>> and
>> go for Geronimo as our default deployment if/when we choose to take the
>> EJB-container road?
>
> I'd rather be able to deploy to Geronimo _and_ other containers.
> OpenEJB by the way is Geronimo's standard EJB container and currently
> applying for becoming top-level ASF.
Was not aware of that, thanks for the info!
>
>>
>> Also I might be wrong, but as we talk directly to the network, the
>> authorized way to integrate into an EJB container is through a JCA
>> adapter, and they are kind of beastly to implement :-)
>
> Unfortunately, you aren't wrong :-)
No, actually I did not believe I was :-)
>
> Bernd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
--
Søren Hilmer, M.Sc., M.Crypt.
wideTrail Phone: +45 25481225
Pilevænget 41 Email: sh@widetrail.dk
DK-8961 Allingåbro Web: www.widetrail.dk
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by Søren Hilmer <sh...@widetrail.dk>.
On Thu, May 3, 2007 11:40, Bernd Fondermann wrote:
> On 5/3/07, Søren Hilmer <sh...@widetrail.dk> wrote:
>> Hi,
>>
>> Well, just thinking, this being ASF. Shouldn't we eat our own dogfood,
>> and
>> go for Geronimo as our default deployment if/when we choose to take the
>> EJB-container road?
>
> I'd rather be able to deploy to Geronimo _and_ other containers.
> OpenEJB by the way is Geronimo's standard EJB container and currently
> applying for becoming top-level ASF.
Was not aware of that, thanks for the info!
>
>>
>> Also I might be wrong, but as we talk directly to the network, the
>> authorized way to integrate into an EJB container is through a JCA
>> adapter, and they are kind of beastly to implement :-)
>
> Unfortunately, you aren't wrong :-)
No, actually I did not believe I was :-)
>
> Bernd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
--
Søren Hilmer, M.Sc., M.Crypt.
wideTrail Phone: +45 25481225
Pilevænget 41 Email: sh@widetrail.dk
DK-8961 Allingåbro Web: www.widetrail.dk
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by Bernd Fondermann <be...@googlemail.com>.
On 5/3/07, Søren Hilmer <sh...@widetrail.dk> wrote:
> Hi,
>
> Well, just thinking, this being ASF. Shouldn't we eat our own dogfood, and
> go for Geronimo as our default deployment if/when we choose to take the
> EJB-container road?
I'd rather be able to deploy to Geronimo _and_ other containers.
OpenEJB by the way is Geronimo's standard EJB container and currently
applying for becoming top-level ASF.
>
> Also I might be wrong, but as we talk directly to the network, the
> authorized way to integrate into an EJB container is through a JCA
> adapter, and they are kind of beastly to implement :-)
Unfortunately, you aren't wrong :-)
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by Bernd Fondermann <be...@googlemail.com>.
On 5/3/07, Stefano Bagnara <ap...@bago.org> wrote:
> Danny Angus ha scritto:
> >> I would not neccessarily suggest to change a running
> >> system. Mail infra is very critical to the ASF!
> >
> > What's more James is better suited to complex processing than to
> > handling very large volumes. FWIW I heard that a few years ago Apache
> > sent 1,000,000+ mails per day.
> > James would need to be optimised to manage that volume effectively.
>
> I send around 50000 mails per hour using JAMES Server (arithmetically
> 1.2M per day ;-) ) on a very cheap server on a 1 mbps limited internet
> connection. I had to tune some parameter and I currently use a custom
> RemoteDelivery service, but for performance concerns it is not so
> different from the official RemoteDelivery (I had to reduce the number
> of attempts, and to avoid cycling over each multihomed address for an
> MX: I simply cycle over the first 4 mx servers, 1 IN A address for each MX)
>
> In my specific case mails are generated by JAMES and not relayed mails.
> I receive not more than 1000 mails per hour on that server.
>
> Stefano
wow!
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by Stefano Bagnara <ap...@bago.org>.
Danny Angus ha scritto:
>> I would not neccessarily suggest to change a running
>> system. Mail infra is very critical to the ASF!
>
> What's more James is better suited to complex processing than to
> handling very large volumes. FWIW I heard that a few years ago Apache
> sent 1,000,000+ mails per day.
> James would need to be optimised to manage that volume effectively.
I send around 50000 mails per hour using JAMES Server (arithmetically
1.2M per day ;-) ) on a very cheap server on a 1 mbps limited internet
connection. I had to tune some parameter and I currently use a custom
RemoteDelivery service, but for performance concerns it is not so
different from the official RemoteDelivery (I had to reduce the number
of attempts, and to avoid cycling over each multihomed address for an
MX: I simply cycle over the first 4 mx servers, 1 IN A address for each MX)
In my specific case mails are generated by JAMES and not relayed mails.
I receive not more than 1000 mails per hour on that server.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by Danny Angus <da...@apache.org>.
> I would not neccessarily suggest to change a running
> system. Mail infra is very critical to the ASF!
What's more James is better suited to complex processing than to
handling very large volumes. FWIW I heard that a few years ago Apache
sent 1,000,000+ mails per day.
James would need to be optimised to manage that volume effectively.
To those people who say that James isn't good enough for Apache to use
I say that that is because James is a tool for solving a *different*
problem.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Ahmed Mohombe wrote:
>> If it would be good for ASF mail delivery - I would not like to put
>> that on a test. ASF is sending quite a lot of mails!
> IMHO it would be the duty of the "JAMES team" to lobby this trial to the
> other ASF members
> to make a first try and get feedback what's required to be able to 100%
> run the entire ASF emails on JAMES.
One basic requirement is to handle tens of thousands of mails each day
very reliably.
=> We are only starting to make this testable (James Postage project).
Another requirement is to very flexibly handle management.
=> We are working on management features.
As long as we have not enough people working on these things, we are not
fullfilling these requirements.
Everyone is welcome to help and improve.
> It would be the ultimate argument for every manager for adopting JAMES.
> In the last 4 years, I was always had to hear: "if it's not even good
> for their own use, why should
> it be good enough for us?" :).
Would be a strong argument, but probably not the ultimate one. When
chosing a product, check your own requirements, not the requirements of
others!
Even if the ASF infrastructure team is coming to the conclusing that
James is an option, I would not neccessarily suggest to change a running
system. Mail infra is very critical to the ASF!
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by Ahmed Mohombe <am...@yahoo.com>.
>>> Well, just thinking, this being ASF. Shouldn't we eat our own dogfood...
>> If that would be so, than the entire ASF "messaging" infrastructure
>> should run on JAMES in *first* place, including newsgroups and mailing
>> lists (and this since years) :).
>
> Well, that would at least dramatically increase the attention JAMES
> would get. ;-)
Of course :). JAMES also brings attention to Apache, cause not all
users search Apache first than find JAMES: most of them search an email server,
than discover JAMES and then see that it's on Apache :).
> If it would be good for ASF mail delivery - I would not like to put that
> on a test. ASF is sending quite a lot of mails!
IMHO it would be the duty of the "JAMES team" to lobby this trial to the other ASF members
to make a first try and get feedback what's required to be able to 100% run the entire ASF emails on
JAMES.
It would be the ultimate argument for every manager for adopting JAMES.
In the last 4 years, I was always had to hear: "if it's not even good for their own use, why should
it be good enough for us?" :).
Ahmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Ahmed Mohombe wrote:
>> Well, just thinking, this being ASF. Shouldn't we eat our own dogfood...
> If that would be so, than the entire ASF "messaging" infrastructure
> should run on JAMES in *first* place, including newsgroups and mailing
> lists (and this since years) :).
Well, that would at least dramatically increase the attention JAMES
would get. ;-)
If it would be good for ASF mail delivery - I would not like to put that
on a test. ASF is sending quite a lot of mails!
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by Søren Hilmer <sh...@widetrail.dk>.
On Thu, May 3, 2007 11:48, Ahmed Mohombe wrote:
>> Well, just thinking, this being ASF. Shouldn't we eat our own dogfood...
> If that would be so, than the entire ASF "messaging" infrastructure should
> run on JAMES in *first*
> place, including newsgroups and mailing lists (and this since years) :).
>
He he, good one!
> Also, AFAIK the Geronimo food has a strong Maven taste :).
>
Uhmm, yes and that is good tasting food IMO.
> Ahmed.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
--
Søren Hilmer, M.Sc., M.Crypt.
wideTrail Phone: +45 25481225
Pilevænget 41 Email: sh@widetrail.dk
DK-8961 Allingåbro Web: www.widetrail.dk
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by Ahmed Mohombe <am...@yahoo.com>.
> Well, just thinking, this being ASF. Shouldn't we eat our own dogfood...
If that would be so, than the entire ASF "messaging" infrastructure should run on JAMES in *first*
place, including newsgroups and mailing lists (and this since years) :).
Also, AFAIK the Geronimo food has a strong Maven taste :).
Ahmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by Søren Hilmer <sh...@widetrail.dk>.
Hi,
Well, just thinking, this being ASF. Shouldn't we eat our own dogfood, and
go for Geronimo as our default deployment if/when we choose to take the
EJB-container road?
Also I might be wrong, but as we talk directly to the network, the
authorized way to integrate into an EJB container is through a JCA
adapter, and they are kind of beastly to implement :-)
--Søren
--
Søren Hilmer, M.Sc., M.Crypt.
wideTrail Phone: +45 25481225
Pilevænget 41 Email: sh@widetrail.dk
DK-8961 Allingåbro Web: www.widetrail.dk
On Thu, May 3, 2007 08:46, Danny Angus wrote:
> On 5/3/07, David Blevins <da...@visi.com> wrote:
>
>> Just an FYI, OpenEJB is extremely non-intrusive and it's very easy to
>> use as "just a library" in various ways.
>
> I hadn't really thought of that, I know Noel had mentioned OpenEJB,
> but I couldn't figure out why, and I used it years ago so I should
> have remembered.
>
> I'm still not sure exactly where we should go with all this, but it
> was worth reminding us. Thanks.
>
> d.
>
> ---------------------------------------------------------------------
> 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
Re: JAMES technology uplift
Posted by Danny Angus <da...@apache.org>.
On 5/3/07, David Blevins <da...@visi.com> wrote:
> Just an FYI, OpenEJB is extremely non-intrusive and it's very easy to
> use as "just a library" in various ways.
I hadn't really thought of that, I know Noel had mentioned OpenEJB,
but I couldn't figure out why, and I used it years ago so I should
have remembered.
I'm still not sure exactly where we should go with all this, but it
was worth reminding us. Thanks.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by David Blevins <da...@visi.com>.
On May 2, 2007, at 3:36 AM, Stefano Bagnara wrote:
> Noel J. Bergman ha scritto:
>> [..]
>> Conceptually, JAMES is made up of the following pieces:
>>
>> - Wire level protocol handlers, which break down into:
>> - Incoming Message Acceptors (e.g., SMTP)
>> - Incoming Message Providers (e.g., POP3)
>> - Outgoing Message Delivery (e.g., RemoteDelivery)
>
> We have all of them (you forgot fetchmail)
> - Outgoing messages via PUSH model (remotedelivery)
> - Outgoing messages via POP model (pop3server/imapserver)
> - Incoming messages via PUSH model (smtpserver)
> - Incoming messages via POP model (fetchmail)
>
>> [...]
>> The parts can be implemented as POJOs, but they need to know how to
>> communicate. We need to balance flexibility with implementation
>> of random
>> ad hoc interfaces. For example, if we adopt JCR, we should
>> document how we
>> are using it, and provide some convenience wrappers for common
>> things that
>> we do, but we should not try to create another abstraction for
>> storage. The
>> JCR *would be* the abstraction. Period. In other areas,
>> POJOfication
>> allows a lot of flexibility, but we still have to build a working
>> server.
>
> About JCR being the abstraction "period", I would say.. "maybe comma"
> ;-) Let's see it working before placing periods.
>
>> Danny raised an interesting idea, which would be to host the
>> mailet pipeline
>> in an EJB container, e.g., OpenEJB. My revised spooler notes from
>> way back
>> when also made some mention of the possibility of using an MDB,
>> but I hadn't
>> really given much thought to actually running JAMES in an EJB
>> container.
>> However, although there may be some initial resistance, it does
>> make some
>> sense. For one thing, it provides a standard platform for JAMES,
>> and opens
>> up lots of options for deployment. So how might this work?
>>
>> Once the SMTP server has put the message into JCR, a JMS message
>> can be sent
>> to a destination attached to an MDB, which in turn invokes the
>> spool manager
>> to start processing the message. By providing two standalone
>> methods:
>> message storage (JCR) and messge processing initiation (JMS), any
>> Java code
>> could provide messages for a pipeline. A pipeline, not *the*
>> pipeline,
>> because the JMS destination would be a configurable means to
>> determine where
>> the message starts processing.
>
> So you revamped JMS, too ;-)
>
> I'm fine with JCR and JMS (if they satisfy our requisites). I
> prefer to
> not require a full J2EE stack for running it.
Just an FYI, OpenEJB is extremely non-intrusive and it's very easy to
use as "just a library" in various ways. We of course support the
standard "setup the server, put apps in server" model, but the "put
ejb container into the app" is just really handy in many a case;
junit test cases for one, but also for projects that are more or less
platforms themselves and aren't interested in loosing the spot of top
dog :)
Don't know what you all had in mind, but I figured I'd let you know
that it is possible to invert the whole container/app relationship
with OpenEJB.
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by Stefano Bagnara <ap...@bago.org>.
Danny Angus ha scritto:
>> I prefer to
>> not require a full J2EE stack for running it. If we build upon JCR and
>> JMS we already provide lots of options for deployment. Btw it seems you
>> switch deployment options too fast ;-) .. yesterday (some months ago)
>> everyone was for OSGi... I don't read OSGi in this mail...
>
> I don't think we should *require* J2EE, but the point I made to Noel
> is that there are benefits in some circumstances, of making an MDB
> deployment of the spoolmanager an attractive *option*.
>
> OSGi is still a possibility. The thing we should be focussed on is
> changing James so that it could be deployed as easily in any of many
> different environments, and pick *one* for our core distribution.
>
> d.
+1 Rephrased this way I agree ;-) [ Noel has a special ability to make
things looks bad to me :-P ]
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by Danny Angus <da...@apache.org>.
> I prefer to
> not require a full J2EE stack for running it. If we build upon JCR and
> JMS we already provide lots of options for deployment. Btw it seems you
> switch deployment options too fast ;-) .. yesterday (some months ago)
> everyone was for OSGi... I don't read OSGi in this mail...
I don't think we should *require* J2EE, but the point I made to Noel
is that there are benefits in some circumstances, of making an MDB
deployment of the spoolmanager an attractive *option*.
OSGi is still a possibility. The thing we should be focussed on is
changing James so that it could be deployed as easily in any of many
different environments, and pick *one* for our core distribution.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: JAMES technology uplift
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> About JCR being the abstraction "period", I would say.. "maybe comma"
> ;-) Let's see it working before placing periods.
You must have missed the *IF* earlier in the paragraph. :-)
> So you revamped JMS, too ;-)
For a specific purpose, not for the internal implementation of spooling.
> maybe the message driven pojo approach (see
> http://jencks.org/Message+Driven+POJOs) is more lightweight than MDB.
MDB is really just a JMS listener. :-)
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES technology uplift
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman ha scritto:
> [..]
> Conceptually, JAMES is made up of the following pieces:
>
> - Wire level protocol handlers, which break down into:
> - Incoming Message Acceptors (e.g., SMTP)
> - Incoming Message Providers (e.g., POP3)
> - Outgoing Message Delivery (e.g., RemoteDelivery)
We have all of them (you forgot fetchmail)
- Outgoing messages via PUSH model (remotedelivery)
- Outgoing messages via POP model (pop3server/imapserver)
- Incoming messages via PUSH model (smtpserver)
- Incoming messages via POP model (fetchmail)
> [...]
> The parts can be implemented as POJOs, but they need to know how to
> communicate. We need to balance flexibility with implementation of random
> ad hoc interfaces. For example, if we adopt JCR, we should document how we
> are using it, and provide some convenience wrappers for common things that
> we do, but we should not try to create another abstraction for storage. The
> JCR *would be* the abstraction. Period. In other areas, POJOfication
> allows a lot of flexibility, but we still have to build a working server.
About JCR being the abstraction "period", I would say.. "maybe comma"
;-) Let's see it working before placing periods.
> Danny raised an interesting idea, which would be to host the mailet pipeline
> in an EJB container, e.g., OpenEJB. My revised spooler notes from way back
> when also made some mention of the possibility of using an MDB, but I hadn't
> really given much thought to actually running JAMES in an EJB container.
> However, although there may be some initial resistance, it does make some
> sense. For one thing, it provides a standard platform for JAMES, and opens
> up lots of options for deployment. So how might this work?
>
> Once the SMTP server has put the message into JCR, a JMS message can be sent
> to a destination attached to an MDB, which in turn invokes the spool manager
> to start processing the message. By providing two standalone methods:
> message storage (JCR) and messge processing initiation (JMS), any Java code
> could provide messages for a pipeline. A pipeline, not *the* pipeline,
> because the JMS destination would be a configurable means to determine where
> the message starts processing.
So you revamped JMS, too ;-)
I'm fine with JCR and JMS (if they satisfy our requisites). I prefer to
not require a full J2EE stack for running it. If we build upon JCR and
JMS we already provide lots of options for deployment. Btw it seems you
switch deployment options too fast ;-) .. yesterday (some months ago)
everyone was for OSGi... I don't read OSGi in this mail...
Hint: maybe the message driven pojo approach (see
http://jencks.org/Message+Driven+POJOs) is more lightweight than MDB.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org