Noel J. Bergman wrote:
The level of exposure of these classes to client code is a function of
the container support for isolation. If your running James in Phoneix
then these classes will be exposed. If you running under Merlin then
they will be isolated to the implementing container. For example, under
Merlin the only API exposed by James is the mailet API. This enables
Merlin to export the Mailet API to any component providing that the
importing component includes the Mailet API in its classloader.
Everything else is isolated within a James container.
What about James components that use commons-collections, commons-pool, commons-net, commons-dbcp? And what do we need to do about exposing those classes to mailets where a mailet wants to access a common class?
You don't - pure and simple.
James uses a bunch of implementation classes and components packaged in a a number of different components with particular versions and specific implementation dependencies. None of that should be exposed to a mailet implementation. For example, you james implementation may be dependent on the latest greates 4.1.5 framework release - but a mailet implementation does not need to know this. In fact, the mailet implementation can use whatever it likes providing that the common API classes are consistent.
This means that James can change with practically zero impact on the mailet implementation.
"But" you say!!
And before you ask the question concerning the sharing of resources ... well,
the physical resources are sharable because thay are accessible via a local
resource repository (which is independent of sharing at the level of
classloaders). If mailet needs commons collections, it just includes a
resource reference in its classpath defintion. The resource is cached
locally and accesible by any component implementation.
I guess setting up the environment for Merlin is going to be an interesting
excercise. Obviously you've done it sufficient for your needs. :-)
There is still a lot of scope for exploring posssiblities for mailet management that I have not even looked at. Currently I'm simply deploying james in much the same way that Phoenix does - but there is so much more potential when you look at james as a coposite component.
Cheers, Steve.
--- Noel
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
