james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Stephenson <tstephenso...@gmail.com>
Subject Re: J2EE as "Avalon" replacement on James ?
Date Sun, 03 Apr 2005 06:57:15 GMT
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

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


On Mar 31, 2005 10:04 PM, Jean-Baptiste Bugeaud <bugeaud@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

View raw message