james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Brewin" <sbre...@synsys.com>
Subject RE: James deployed as plugin on Geronimo!
Date Tue, 20 Mar 2007 20:30:51 GMT
danny.angus@gmail.com wrote:
> Noel,
> I'm in favour of a JCA deployment option because it would let people
> embed mail functionality in J2EE applications making it available to
> systems assembled from J2EE components.
> The big win this would have would be that administrators wouldn't have
> to get right out of their comfort zone, the email functionality could
> be monitored and operated through the same administration toolsets
> they currently use for managing their *other* J2EE applications.
> The cost of ownership of James isn't all about through-put and
> hardware, it is also about the cost of administering applications and
> training, and retaining, specialist administrators. If James
> installations could be administered by people with a commonly
> available skills profile, and tools which are already in place, it
> would be a real benefit.
> d.


Was this in reply to something posted here? If so, I never received it and
can't find it in the archives.

Anyways, I entirely agree. Particularly as the use of a JCA allows use to
expose just what we want to the app. server and leave the rest to run
unfetered in its own VM. Sure a remotely connected adapter is a performance
hit, but I cannot think of anything we need to expose remotely via the
adapter that shifts a substantial amount of data which isn't exposed in a
similar way already.

I'm thinking we should expose administration API's and mailbox access,
perhaps the API for injecting messages into the spool (as SMTP and fetchmail
do). All other network traffic would be routed exactly as before, directly
to the JVM running James, there would be no performance impact.

The app. server can also be exploited. Its identity and authentication
mechanisms for instance.


-- Steve

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

View raw message