avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [VOTE] RE: ComponentManager interface
Date Mon, 11 Feb 2002 18:17:45 GMT
Stephen McConnell wrote:
> Berin:
> 
> See notes in-line.
>>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
> application.

Seemingly minor design changes can cause a ripple effect and make other
projects that depend on us mad.  Consider the change to PriorityQueue from
handling Comparables to handling Objects (the original intention).  Sam
and GUMP pointed out that this "seemingly" minor change caused issues in
other projects.



>>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.

I understand your delema, but what we are talking about is a fundamental
shift.  It may be that for your purposes, JNDI would be a better fit than
the ComponentManager.  Excalibur has a couple of implementations of JNDI
classes that should help you out.

We want to be able to remove the requirement for any marker interface,
but we also want to address deficiencies in the ComponentManager usage as well.
I am not in favor of band-aid fixes.  period.




>>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
> restriction.

It is still working out a solution.  There are other deficiencies in the
CM approach that are not addressed by this solution.  The first of which
is the ability to obtain a reference to a specific configuration of a
Component without going through the ComponentSelector step.  The second of
which is the ability to release all Components with one call.  All of
these things do need to be considered.



>>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.

Neither you or I know the full extent of what a seemingly simple change
will cause.



>>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
> silly.

Holder == Handler.  I am working out the formalized approach to that in
Excalibur.



>>or you may find out it was a dead end.
>>
> 
> The wrapping objects that don't implement Component is a dead-end.

True, but now er are faced with a change--and we want the change to be
the most correct.



>>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.

And there are things that multiple people *don't* like about the interface.
Should we throw them to the curb?  If we are going to introduce change, lets
get the best solution--not necessarily the easiest solution.



>>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.

What you are proposing is technically an "enhancement", so its too late.
I understand all your points, so I say again, what are your oppinions on the
Resolver code?  Would this elegantly handle your requirements while solving
the necessity of the ComponentSelector and easily releasing all Components
that are managed resources?

I mean, if we are going to introduce change, let's do it right.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


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


Mime
View raw message