geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Re: [picocontainer-dev] Re: ClassLoader Architecture
Date Sun, 26 Jun 2005 19:25:23 GMT
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.


View raw message