avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ricardo Rocha <rica...@apache.org>
Subject Re: [C2] ComponentManager/Selector Rearchitecture
Date Mon, 19 Mar 2001 22:32:50 GMT
On Tuesday 20 March 2001 01:15, Peter Donald wrote:
> At 05:43  19/3/01 +0100, Ricardo Rocha wrote:
> >I know the following is pertinent to Avalon more than to C2, but much of
> > the C2 infrastructure is so generic that parts of it could be eventually
> > moved to Avalon or even become separate subdistributions (e.g. the XML
> > compiler, some of the org.apache.cocoon.xml interfaces/abstract classes,
> > etc)
> Theres a new project that is starting up on jakarta ("commons") that is to
> contain "reusable components" which may also be an option.

Cool! We need that! It sounds like a much better option for what we're
seeking now.

> >Thinking bigger, "RoleInfo" actually embodies the notion of "Avalon-based
> >framework", a concept that might well deserve first-class citizen status
> > in the Avalon set of abstractions.
> In Avalon we have ServiceInfo == RoleInfo

It appears to me that BlockInfo comes closer to what we're discussing here,
namely info about the _role protocol_ for a given framework.

While ServiceInfo provides only basic service description, BlockInfo makes
available a list of role-qualified dependencies, which is akin to what C2's
RoleUtils and Bibop's RoleInfo do today.

Q: can we safely asume that the "role protocol" made available by RoleUtils
and RoleInfo has the same semantics as the role dependency list provided by
BlockInfo? We're talking about the roles _defined_ by the framework/block,
rather than (external) roles it might depend on...

At Bibop, we've used C2's component management classes, slightly modified to
decouple them from C2 and make them usable by any framework providing info on
its role protocol, hence the "RoleInfo" interface.

If BlockInfo already provides the same semantics and functionality, the
proposed RoleInfo interface might indeed be redundant...

Ricardo Rocha wrote:
> >The collection of roles defined by an Avalon-based framework is
> > simmetrical to the notion of an OO interface: for the same framework,
> > there could be one or more "implementations", each differing by the
> > actual role-implementing classes and their respective configurations.
> >
> >Using this metaphor, we could say that each C2's sitemap configuration is
> >actually an "implementation" of the C2 framework interface (as currently
> >defined in RoleUtils)

Peter Donald wrote:
> A month or two ago I was talking about TurbineKernel/CocoonKernel and how
> it relates to atlantis+camelot (avalons generic kernel + generic container
> apis). The notion of a CocoonKernel and CocoonApplication. The CocoonKernel
> would be the super-manager that contains many CocoonApplications. The
> CocoonApplication would be the "implementation" you talk about and would
> manage most of inter-component assembly/configuration/support etc. There is
> a scratchy first pass that in CVS but it is not yet up to scratch (mainly
> because I only had two kernel style projects to work on at the time and
> didn't want to develope anything outside reference to real-world problems).

Yes, Camelot interfaces deal with the same concerns we're discussing.

On Monday 19 March 2001 20:37, Berin Loritsch wrote:
> I will try to see where it would fit in the Avalon Framework.  It would be
> perfect for replacing the DefaultComponentManager implementation in
> Avalon--but the Handler and Factory implementations may need a
> subpackage.

The C2 class mentioned by Berin (ComponentFactory) implements ObjectFactory,
not (phoenix) Factory. This class doesn't really deal with pooling, though.

Is there some degree of redundancy between Factory and ObjectFactory?

The C2 component management classes being discussed don't really address
the class loading side of things (they currently use a plain Class.forName()).
Camelot, on the other hand, does account for this through its Loader and
Locator interfaces...

At this point we want to be sure we're making the right decision as to what
to base our blocks upon. At first sight it appeared to us that just
generalizing C2's component management classes and proposing moving them to
the Avalon top-level package would be the right thing to do (tm), but your 
comment appears to suggest that Camelot would be the right place to move these
components. What do you think?



To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

View raw message