This sounds lot like what's in the standard java.beans.beancontext package.
It basically provides an environment where you assemble beans (practically,
arbitrary objects); some provide services, some consume services, some do
both. The bean context effectively acts as a randezvous place; you throw the
beans in a context, and they dinamically look for other beans that implement
a specific service they need in their context.
As an additional benefit, contexts are isolated from each other which can be
a great advantage over the "classic" Java way of creating services: through
a static method of a utility class. Furthermore, contexts can be nested (I
guess that's similar to Avalon's "hierarchical ComponentManagers".
I'm using this in a server environment, and it works charmingly. Oh, and
it's a standard part of the JDK since 1.2.
Attila.
----- Original Message -----
From: "Paulo Gaspar" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: 2001. augusztus 20. 2:47
Subject: RE: Velocity Architecture
> Do you know Avalon?
> (It is a bit abstract when you start but then, it gets interesting.)
>
> To make it simple:
> - a ComponentManager is a Map where you can hold objects
> (Components/Resources) by role/name;
> - a Context is a hierarchical Map in the sense that it has a parent
> Context and that it searches in the parent objects that it does
> not find on itself.
>
> These ideas can mix and you can have an hierarchical ComponentManager.
>
> Examples or roles for Velocity objects that could be managed by such
> ComponentManager:
> - Logger;
> - TemplateLoader;
> - TemplateCache;
> - Introspector / IntrospectionCache;
> - IteratorIntrospector;
> - EventCatridge.
>
> Please interpret the above names by what their name suggest and not
> exactly by what existing Velocity classes with the same name do now.
> (And it is intentional that many names do not match the current
> ones.)
>
>
> Some advantages of placing so many Velocity components in such
> structure:
> - Having clean interfaces would be enforced;
> - There would be ONE well defined way of changing any such aspect
> of Velocity.
>
> But, for me, one of the most interesting features would be the
> ability to have a generic Velocity behavior and easily change the
> behavior of one aspect only for a part of the application, trough
> the use of the above mentioned "hierarchical ComponentManagers":
> - You could easily have an Engine for general use and another one
> with just one aspect (let's say the TemplateLoader) changed to
> be used in only one part of the application.
>
>
> Am I dreaming too much here?
>
> Have fun,
> Paulo
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> > Behalf Of Geir Magnusson Jr.
> > Sent: Monday, August 20, 2001 2:10 AM
> >
> >
> > Paulo Gaspar wrote:
> > >
> > > I have been playing around in my framework with Avalon's
> > > ideas on resource management and contexts.
> > >
> > > Does anyone here know Avalon's ComponentManager and
> > > Context ideas together with the "role" concept?
> > >
> > > Velocity could be made much smaller, simple and flexible
> > > using those concepts. If you grok them, I am sure you
> > > will understand what I mean.
> >
> > How so?
> >
> > --
> > Geir Magnusson Jr. [EMAIL PROTECTED]
> > System and Software Consulting
> > Developing for the web? See http://jakarta.apache.org/velocity/
> > Well done is better than well said - New England Proverb
> >
>
