avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell" <mcconn...@apache.org>
Subject RE: [VOTE] RE: ComponentManager interface
Date Mon, 11 Feb 2002 17:51:47 GMT


See notes in-line.

> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Monday, 11 February, 2002 17:19
> To: Avalon Developers List
> Subject: Re: [VOTE] RE: ComponentManager interface
> Stephen McConnell wrote:
> > This brings us down to options (3) and (4), both involving
> > creation of quasi parallel interfaces and implementation
> > of ComponentManger and DefaultComponentManager which deal
> > with Object as distinct from Component.
> >
> > I've broken this down into three options which we can vote
> > on, the first option is to go ahead with the proposed
> > framework/service package.  The second option is to go ahead
> > but defer a decision on the package name pending further
> > discussion, and the third option is to add a new interface and
> > implementation to the current component package.
> >
> > (A)  Clone interface, implementation, and exception into a
> >      new package org.apache.avalon.framework.service
> >
> > (B)  Clone interface, implementation, and exception into a
> >      new package and defer package, interface and
> >      implementation naming for further discussion.
> >
> > (C)  Clone interface, implementation, and exception under
> >      the existing framework/component package and defer
> >      interface and implementation naming for further
> >      discussion.
> >
> > To kick things off, here is my vote:
> >
> > (A) +1
> > (B) +0,
> > (C) -0
> >
> > Cheers, Steve.
> Steve, I can't help but think you are rushing things.  Check out
> the proposal I have under Framework's src/proposal/resolver directory.
> It has some interfaces and a package.html file that describes how to
> use it.

The Resolver package in src/proposal/resolver is something new.  I'm
not proposing anything new - simply addressing a minor design issue that
restricts the use of the Avalon component model in mainstream

> I think it deserves some serious consideration.
> I have always been an advocate of not rushing design solutions.  You
> always regret it later on.  Something as foundational as a framework
> *must* be very careful of how we go about introducing change.

The change proposed is to replace "Component" with "Object" in a revised
ComponentManger. Component is an empty interface but the obligation for
classes to implement that interface means that those objects cannot be
treated as components in Avalon.  For example, a industry standard ORB
cannot (according to the current ComponentManager interface) be supplied
as a service to the objects it manages because an industry standard
ORB does not implement "Component".  In fact in cannot - an ORB is a
class with no interfaces - it is instantiated by the JVM based on system
properties that declare an ORB implementation class name.  So there is
a dilemma - either I define a wrapper - ComponentHolder.getObject() - or,
we address the real problem.  The real problem is that ComponentManager
forces objects to implement Component.  The real solution is to lift that
restriction.  This is not changing the framework - it is solving a
an unnecessary restriction that is limiting the application of the
framework in real industrial applications.

> Which one of those options is to have an Avalon 5.0 revision and work
> out our solutions there?  That is the one I am +1 on, and I am strongly
> -1 on anything else.

No problem there - but what I'm proposing isn't "working out a solution".
This is taking something the works, that is clean, simple, and elegant,
eliminating a small but significant restriction with minimal side-effect
and getting on with the job of delivering some important services.  In
respect to an Avalon 5.0 revision - yes - that's the time and place for
enhancing Avalon and working out things like enhancements to component
management.  But lets be very clear about this - I'm not proposing an
enhancement now, I'm proposing the elimination of an unnecessary

> If the current solutions don't satisfy your needs, you have to use
> proprietary extensions.

I've been using Avalon in anger for over a year.  During that time I've
developed workarounds to a number of restrictions.  More recently I moving
some of that work into Avalon under cornerstone apps.  This is work that
leverages the contributions of other open-source activities.  While
including workarounds in proprietary solutions is fine - it really sucks
when your trying to put in place industry standard components (ORB, PSS,
INS, OTS, ...) as pluggable Phoenix service and you are forced to add
wrappers around "EVERYTHING" that does not implement the magic Avalon
Component interface.  This sucks so much and its so simple to fix.

> You may find out that the proprietary extension was truly beneficial,

The "truly beneficial proprietary extension" is a holder class.  The
benefit of the holder class is that people have to write more lines code
wrapping and unwrapping objects just because the Avalon ComponentManger
interface has this small but significant anomaly.  You, I, and everyone
else knows that this is not beneficial, adds extra unnecessary lines
code wrapping and unwrapping non-Component components - is just plain

> or you may find out it was a dead end.

The wrapping objects that don't implement Component is a dead-end.

> The trial
> and error stage will cause unstability in the core API, and I cannot abide
> that at this stage of the game.

That an unfair comment.  There is nothing "trial and error" about what is
being proposed.  We are simply address resolution of a minor technical issue
that unreasonably restricts the application of Avalon interfaces and
implementations on a broad spectrum of software applications.  Do you
really believe that what is being proposed is "error prone" - ? Please take
another look at the existing Avalon ComponentManager, compare this with
the sources in proposal/service and you will see that this is simply a clone
with the single exception of the replacement of "Component" with "Object".
This is a NOT A STABILITY question.  There IS NO TRAIL AND ERROR.

> Consider the proposals in the Framework, and we can work on something that
> is powerful, flexible, elegant, and robust.

Under the scope of Avalon 5 - yes.  As a solution to the unnecessary
restrictions in current Avalon component management - no.  I'm not getting
into discussions now about enhancements (not in this thread).  I'm address
resolution of a issue.  Its an important issue because it effect the
framework - its an important issue because it deals with the usability of
Avalon beyond the Avalon community.  It an important issue because it has
a direct impact on other communities that are considering Avalon for more
that just logging and configuration.

Cheers, Steve.

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

View raw message