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 Jean-Baptiste Bugeaud <bu...@gmail.com> on 2005/03/31 15:38:14 UTC
J2EE as "Avalon" replacement on James ?
Hi all,
As I saw that avalon is apparently EOLed, I just ask myself a question.
I am not sure if the new container has been already choosen. If not,
what could prevent James to become a J2EE application and thus run in
an J2EE application server ?
If so, the new container will be J2EE standard container also one
could use the Apache Geronimo as primary target.
This means that it could benefit from all the distributed caching /
clustering / administration (JMX) mechanism brought by any appserver.
Embeding the James connectors in JCA should also improve the
versatility as plugging new connectors to push streams will be quite
easy and James could benefit from existing connectors as well.
So, my personal oppinion is that James is great but it should not try
to reinvent the wheel and sit on to of existing & proven solutions.
NB: upcoming EJB3 is anticipated to be a big thing with injected
references, lightweight persistence (inspired by Hibernate) and POJO
design. So, lots of things people need but defined on a future J2EE
standard.
Any mind on all that ?
Regards,
JB
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: J2EE as "Avalon" replacement on James ?
Posted by Jean-Baptiste Bugeaud <bu...@gmail.com>.
> Yeah, I've always had this as a personal goal for James, and an MDB
> deployment of the spoolmanager, each MDB spool could have its own
> mailet pipeline.
>
> Mmm :-)
>
> Sadly no time to realise my dream :-(
But dreams have to come true at a point of time ;-)
So, who knows ...
Rgs,
JB
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: J2EE as "Avalon" replacement on James ?
Posted by Danny Angus <da...@gmail.com>.
> Actually, I've always wanted a JCA connector for incoming email so I could have MDBs consume email. Oh how wonderful that would be!
Yeah, I've always had this as a personal goal for James, and an MDB
deployment of the spoolmanager, each MDB spool could have its own
mailet pipeline.
Mmm :-)
Sadly no time to realise my dream :-(
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: J2EE as "Avalon" replacement on James ?
Posted by Tim Stephenson <ts...@gmail.com>.
Actually the other thread going on at the moment about JMS is about
more J2EE in James too, though in a different way to this
conversation.
J2EE is obviously a lot of different things but for me one of the more
important justifications is that it allows applications to play
together better by sharing security, transaction models, naming
service and even shared application services. If you are considering
James only as a standalone mail server this may not matter but being
able to consume and originate email in bigger applications is
something I have long wished for when writing J2EE apps for enterprise
customers.
Tim
On Mar 31, 2005 10:04 PM, Jean-Baptiste Bugeaud <bu...@gmail.com> wrote:
> > > Nothing in JAMES touches J2EE.
>
> Well right now, but it is about a server processing, handling &
> storing data so all this fits in the J2EE space isn't it ;-)
>
> > > > If so, the new container will be J2EE standard container
>
> > > There is no such thing. Yes, support for JMX and related would be good, but
> > > that's not the same as claiming that there is a J2EE container. Actually,
> > > there are many: EJB container, Servlet Container, etc.
>
> Obviously, I am not talking about the servlet container but the EJB
> containter for the core part as its lifecycle fits more to a such a
> service.
>
> I do not see isue with the "POJO" mania. But for lots of people POJO
> means magin persistance container with little/no lifecycle. Such
> lightweight container are nice but when it comes to real QoS it is not
> a simple story. For me, POJO is only about having little technical
> impact on business model. In this way, EJB3 is realy a good
> perspective, because you keep the POJO spirit without having the
> tradoff as beeing in a J2EE space you will benefit if required from
> the QoS services and capabilities.
>
> Going so, James will be able to fit to whatever load on whatever configuration.
>
> > > > Embeding the James connectors in JCA
> > >
> > > JCA doesn't seem to over any benefit in this area at all. Do you see
> > > JavaMail transports written to JCA?
>
> Right, I see SMTP pure java implementation written in JCA that push to
> james the inbound.
> Same for POP3 or IMAP4, or even WEBDAV/WebMail ;-)
>
> All this is connectors pushing or pulling resources to the core
> service that is handling the message life (creation, storage,
> fetching, archiving, grouping, triggering, ...).
>
> >
> > Actually, I've always wanted a JCA connector for incoming email so I could have MDBs consume email. Oh how wonderful that would be!
>
> Exactly ! you get it :) There is a good example of inbound JCA for emails,
> http://www.theserverside.com/articles/article.tss?l=J2EE1_4
>
> With this example you can receive emails thru a JMS message on a method like :
>
> public void onMessage(javax.mail.Message message)
>
> Isn't life simple ? ;-)
>
> Anyway, that is just some late night toughts.
>
> Rgs,
> JB
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
--
Tim Stephenson
e: tim@thestephensons.me.uk
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: J2EE as "Avalon" replacement on James ?
Posted by Jean-Baptiste Bugeaud <bu...@gmail.com>.
> > Nothing in JAMES touches J2EE.
Well right now, but it is about a server processing, handling &
storing data so all this fits in the J2EE space isn't it ;-)
> > > If so, the new container will be J2EE standard container
> > There is no such thing. Yes, support for JMX and related would be good, but
> > that's not the same as claiming that there is a J2EE container. Actually,
> > there are many: EJB container, Servlet Container, etc.
Obviously, I am not talking about the servlet container but the EJB
containter for the core part as its lifecycle fits more to a such a
service.
I do not see isue with the "POJO" mania. But for lots of people POJO
means magin persistance container with little/no lifecycle. Such
lightweight container are nice but when it comes to real QoS it is not
a simple story. For me, POJO is only about having little technical
impact on business model. In this way, EJB3 is realy a good
perspective, because you keep the POJO spirit without having the
tradoff as beeing in a J2EE space you will benefit if required from
the QoS services and capabilities.
Going so, James will be able to fit to whatever load on whatever configuration.
> > > Embeding the James connectors in JCA
> >
> > JCA doesn't seem to over any benefit in this area at all. Do you see
> > JavaMail transports written to JCA?
Right, I see SMTP pure java implementation written in JCA that push to
james the inbound.
Same for POP3 or IMAP4, or even WEBDAV/WebMail ;-)
All this is connectors pushing or pulling resources to the core
service that is handling the message life (creation, storage,
fetching, archiving, grouping, triggering, ...).
>
> Actually, I've always wanted a JCA connector for incoming email so I could have MDBs consume email. Oh how wonderful that would be!
Exactly ! you get it :) There is a good example of inbound JCA for emails,
http://www.theserverside.com/articles/article.tss?l=J2EE1_4
With this example you can receive emails thru a JMS message on a method like :
public void onMessage(javax.mail.Message message)
Isn't life simple ? ;-)
Anyway, that is just some late night toughts.
Rgs,
JB
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: J2EE as "Avalon" replacement on James ?
Posted by David Blevins <da...@visi.com>.
On Thu, Mar 31, 2005 at 02:43:02PM -0500, Noel J. Bergman wrote:
>
> > Embeding the James connectors in JCA
>
> JCA doesn't seem to over any benefit in this area at all. Do you see
> JavaMail transports written to JCA?
>
Actually, I've always wanted a JCA connector for incoming email so I could have MDBs consume email. Oh how wonderful that would be!
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: J2EE as "Avalon" replacement on James ?
Posted by "Noel J. Bergman" <no...@devtech.com>.
> As I saw that avalon is apparently EOLed, I just ask myself
> a question.
Perhaps, but code doesn't degrade like a biological substance.
> I am not sure if the new container has been already choosen.
I think there is general consensus on POJOs, but we still need a container,
and I'd go with Geronimo's.
> If not, what could prevent James to become a J2EE application
Nothing in JAMES touches J2EE.
> If so, the new container will be J2EE standard container
There is no such thing. Yes, support for JMX and related would be good, but
that's not the same as claiming that there is a J2EE container. Actually,
there are many: EJB container, Servlet Container, etc.
> Embeding the James connectors in JCA
JCA doesn't seem to over any benefit in this area at all. Do you see
JavaMail transports written to JCA?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org