hierarchical plexus instances (was Re: Notice of scheduled work)

On Thu, 2003-07-17 at 22:49, Jason van Zyl wrote:
> On Thu, 2003-07-17 at 17:39, Mark H. Wilkinson wrote:
> > On Mon, 2003-07-14 at 01:58, Jason van Zyl wrote:
> > > I'll probably also have time to get around to hiearchical containers
> > > this week too as I need it so that another tool I'm working on will
> > > function.
> > 
> > Oooh; now this I'm interested in. I've got my own hacks that fake
> > hierarchical plexus instances, but I'm reaching the limit of what can be
> > done without more significant changes to the plexus core.
> 
> Yah, I've been living with some work arounds too.

I had some thoughts about this last night, and I'm starting to rethink
whether a hierarchy of plexus instances is actually all that useful. I'm
not saying I don't see the use at all, but I'm starting to think that
most of my use cases might be better served some other way.

First of all, I'm thinking of a plexus instance as more-or-less a set of
components indexed by role and id, along with a few other bits (logging
configuration and such like) provided to all the components.

The hierarchical plexus stuff I've done allows lookup() to cross from
one plexus to another along a chain. It works ok, although the semantics
of release() are wrong (not being able to work out which plexus a
component came from originally).

But I'm now not sure this is the best way of solving the problem. I'd
say the main reason for creating a hierarchy is to allow a child plexus
instance to override the component provided by a given [role,id] key. If
you don't actually need that overriding it would be sufficient to place
all the components in a single plexus instance, and for my use cases I'm
actually happy with having a flat component namespace.

What I was actually trying to achieve was to allow different subsystems
of my code base to find each other dynamically, and to have an easy way
to configure what components were available within a JVM. I'm now
thinking that a single plexus instance could support most of that, but
it would need to be a bit more flexible about the ways in which
components are loaded into it. I guess what I really want is
decentralization of where the component configurations are loaded from,
rather than hierarchy at run-time. At the moment, components are loaded
according to instructions in the main plexus configuration file and
files loaded from a directory specified in the configuration file. It'd
be useful to be able to load more components from files stored as a
resource, or even directly with Java code.

So, what *is* useful about hierarchical plexus instances? Well, you can
have different logging settings and other bits and pieces (lifecycle
implementations I guess) in each plexus, but that doesn't require
hierarchy. It's also useful to be able to lookup one plexus from
another: I have a root plexus that my servlets use, and it contains two
further plexus instances that form the main components of the system.
That said, if I was better able to load these unrelated components into
a single plexus instance, I'd probably do it.

But I don't think that having a complete hierarchy and making lookup()
traverse that hierarchy is worth the effort (and complexity).

I noticed the resource manager stuff in org.apache.plexus.classloader -
was that originally intended to allow further components (and their
resources) to be loaded from a set of defined locations?

-Mark.