Rickard Öberg wrote:
Paul Hammant wrote:
Comp A and B (in separate classloaders) can see Common-API, which can
see the classloader that contains PicoContainer who's parent is the
classes in rt.jar
<snip>
One thing that I have whined about before, and I'm not sure whether it's
been fixed yet, is that a component A needs to be able to have an
internal structure (component!=1 object) and it needs to be able to
expose API implementations to other components without having to expose
its own internal structure. In the discussions so far I have not seen
mention of this problem (but maybe I have simply missed it).
This is the role of a Configuration in Geronimo - to package together a
pre-wired set of closely coupled GBeans and define the external
interfaces (APIs/services offered, dependencies required). It is the
Configurations themselves that are designed to be hot-swapped and not
their constituents.
The implementation we have at this time is horribly naive contributing
to the monolithic mess that is the J2EE Server configuration. Hopefully
we can solve this sooner rather than later and avoid some of the less
maintainable workarounds being considered.
I have my own solution for fixing this, but I am wondering if a more
standard solution to this is available? (now or later) My own solution
is more of a best-practice use of Pico rather than an extension, and if
anyone is interested I can describe it in more detail.
I would be very interested if you have the time.
It really is a big big big issue once you get either loads of components
or large components. We have both cases in our system right now.
Hear, hear - this is a big problem in Geronimo.
--
Jeremy
