You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Ole Bulbuk <Ol...@ebp.de> on 2002/04/09 16:27:20 UTC
AW: deprecated api (ExcaliburComponentManager????)
> But in a "release", there are again incoherence :
> - incoherence between documentation and released api,
> - from scratch application need to use deprecated classes or methods
> like ECM.
> > ExcaliburComponentManager and friends are *not* deprecated.
> > Using them will definitely cause deprecation warnings in
> the interim,
> > but that is the price to pay for backwards compatibility.
The ExcaliburComponentManager will is going to be deprecated???
I thought the standard ComponentManager should be deprecated and Phoenix was
still using it for some reason.
Is there a new component manager that provides roles, hints, etc ???
I just went through great pain to use the standard ComponentManager I got
from Phoenix only for blocks and to use the ExcaliburComponentManager for
all the components inside the block.
The ExcaliburComponentManager is used all the time in the white
paper/tutorial "Developing With Apache Avalon". Inside this paper it is
favored very much over the standard ComponentManager. There are two full
pages ("Making the Configuration Pretty") only about the advantages of the
ExcaliburComponentManager!!!
I am puzzled.
Could a kind soul please tell me what to use instead?
Regards,
Ole
P.S.: If it is just the DefaultComponentManager in the same package as
the ExcaliburComponentManager everything is fine for me
(I just would like a short note) because both are the same.
--
Ole Bulbuk Tel.: 0331/74759/60
Ernst Basler + Partner Fax: 0331/74759/90
Tuchmacherstr. 47 E-Mail: mailto:ob@ebp.de
14482 Potsdam WWW: http://www.ebp.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AW: deprecated api (ExcaliburComponentManager????)
Posted by Berin Loritsch <bl...@apache.org>.
Ole Bulbuk wrote:
>
>>But in a "release", there are again incoherence :
>>- incoherence between documentation and released api,
>>- from scratch application need to use deprecated classes or methods
>>like ECM.
>
>
>>>ExcaliburComponentManager and friends are *not* deprecated.
>>>Using them will definitely cause deprecation warnings in
>>
>>the interim,
>>
>>>but that is the price to pay for backwards compatibility.
>>
>
> The ExcaliburComponentManager will is going to be deprecated???
Yes, but not yet.
> I thought the standard ComponentManager should be deprecated and Phoenix was
> still using it for some reason.
The standard/default will never be deprecated. It only allows you to
have references to ThreadSafe components (one instance per role). It is
very limited in that respect.
> Is there a new component manager that provides roles, hints, etc ???
> I just went through great pain to use the standard ComponentManager I got
> from Phoenix only for blocks and to use the ExcaliburComponentManager for
> all the components inside the block.
I am working on it. It separates the container from the CM (unlike the
ECM).
Don't worry about that right now. Your work will still pay off. The
new version will have the same configurations roles, etc. I have had to
stop work on it temporarily due to heavy work load.
Even then, they will both be choices.
> The ExcaliburComponentManager is used all the time in the white
> paper/tutorial "Developing With Apache Avalon". Inside this paper it is
> favored very much over the standard ComponentManager. There are two full
> pages ("Making the Configuration Pretty") only about the advantages of the
> ExcaliburComponentManager!!!
And those advantages will remain in the new version. I am attempting to
have all the strengths of the ECM and remove as many of its weaknesses
as I possibly can.
>
> I am puzzled.
>
> Could a kind soul please tell me what to use instead?
I am sorry you got alarmed by the email that spawned your concerns.
The writer was addressing some of his concerns, and made some statements
sound like fact when they are his oppinion. I will be addressing those
soon.
>
> Regards,
>
> Ole
>
> P.S.: If it is just the DefaultComponentManager in the same package as
> the ExcaliburComponentManager everything is fine for me
> (I just would like a short note) because both are the same.
The name DefaultComponentManager was deprecated because it conflicts
with the one in the framework jar.
Feel free to use the ECM for as long as you desire.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AW: deprecated api (ExcaliburComponentManager????)
Posted by David BERNARD <dw...@freesurf.fr>.
> > > ExcaliburComponentManager and friends are *not* deprecated.
> > > Using them will definitely cause deprecation warnings in
> > the interim,
> > > but that is the price to pay for backwards compatibility.
>
> The ExcaliburComponentManager will is going to be deprecated???
> I thought the standard ComponentManager should be deprecated and Phoenix was
> still using it for some reason.
> Is there a new component manager that provides roles, hints, etc ???
> I just went through great pain to use the standard ComponentManager I got
> from Phoenix only for blocks and to use the ExcaliburComponentManager for
> all the components inside the block.
>
> The ExcaliburComponentManager is used all the time in the white
> paper/tutorial "Developing With Apache Avalon". Inside this paper it is
> favored very much over the standard ComponentManager. There are two full
> pages ("Making the Configuration Pretty") only about the advantages of the
> ExcaliburComponentManager!!!
I don't know about deprecation of the ExcaliburComponentManager class
but it currently uses deprecated api for Log. Your remark illustrate
what I wrote, difficulty to use avalon due to the mixe of version (api,
recommendation, tutorial...). And I'm volontaire to help change that.
Regards,
--
--------------------------------------------------------------
David "Dwayne" Bernard Freelance Developer (Java)
mailto:dwayne@java-fan.com
\|/ http://dwayne.java-fan.com
--o0O @.@ O0o-------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>