Giacomo Pati wrote:
>
> Another issue is the missing interface Recomposable which has vanished in
> the service package. We use it internally on some component. Most of their
> use is publicate code like:
>
> public void compose( ComponentManager manager )
> {
> this.manager
Stephen McConnell wrote:
>
>
> Giacomo Pati wrote:
>
>> On Mon, 30 Sep 2002, Carsten Ziegeler wrote:
>>
>>
>>
>>> Giacomo Pati wrote:
>>>
>>>
Ok, this thread had made alot of people think about it and the
conclusion
is that we should not switch to a newer/better container at
Stephen McConnell wrote:
>
>>
>> which can be ported to:
>>
>> public void service( ServiceManager manager )
>> {
>>if( this.mainManager == null )
>>{
>> this.mainManager = manager;
>>}
>> this.manager = manager;
>> }
>>
>>
Giacomo Pati wrote:
>On Mon, 30 Sep 2002, Carsten Ziegeler wrote:
>
>
>
>>Giacomo Pati wrote:
>>
>>
>>>Ok, this thread had made alot of people think about it and the conclusion
>>>is that we should not switch to a newer/better container at least until a
>>>2.1 release is out, right?
>>>
>
On Mon, 30 Sep 2002, Carsten Ziegeler wrote:
> Giacomo Pati wrote:
> >
> > Ok, this thread had made alot of people think about it and the conclusion
> > is that we should not switch to a newer/better container at least until a
> > 2.1 release is out, right?
> >
> Yupp.
>
> > I've allready commit
Giacomo Pati wrote:
>
> Ok, this thread had made alot of people think about it and the conclusion
> is that we should not switch to a newer/better container at least until a
> 2.1 release is out, right?
>
Yupp.
> I've allready commited the step 1 (Loggable -> LogEnabled).
>
Nice work!
> Now I'm
Stefano Mazzocchi wrote:
>Hmmm, tell me: which version of Avalon are you guys implementing? Where
>is the line that separates "framework" from "implementations"?
>
>So, the real question should be:
>
> when should Cocoon use a component container based on the design
>principles of the next versi
Giacomo Pati wrote:
> Ok, this thread had made alot of people think about it and the conclusion
> is that we should not switch to a newer/better container at least until a
> 2.1 release is out, right?
>
> I've allready commited the step 1 (Loggable -> LogEnabled).
>
> Now I'm on step 2 (as there
Ok, this thread had made alot of people think about it and the conclusion
is that we should not switch to a newer/better container at least until a
2.1 release is out, right?
I've allready commited the step 1 (Loggable -> LogEnabled).
Now I'm on step 2 (as there has not been any -1). This can b
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>> Stefano Mazzocchi wrote:
>>
>>
>>> -1 for 2.1, no question about it.
>>>
>>> Let me repeat this for those worried guys that are reading this thread:
>>>
>>> WE WILL NOT CHANGE FUNDAMENTAL CONTRACTS UNDER YOUR FEET
>>>
>>>
>>
>> Couldn't
Carsten Ziegeler wrote:
>Stefano Mazzocchi wrote:
>
>
>>-1 for 2.1, no question about it.
>>
>>It is true that Cocoon needs a much better component containment
>>technology for us to be able to implement cocoon blocks as designed so
>>far.
>>
>>But you have my word that I'll continue to -1 any
Stefano Mazzocchi wrote:
>
> -1 for 2.1, no question about it.
>
> It is true that Cocoon needs a much better component containment
> technology for us to be able to implement cocoon blocks as designed so
> far.
>
> But you have my word that I'll continue to -1 any change to the 2.x
> family of
Stephen McConnell wrote:
>
>
> Berin Loritsch wrote:
>
>> Carsten Ziegeler wrote:
>>
>>> Ok, I think we should have a look at a features list of fortress
>>> and merlin compared to the ECM.
>>>
>>> Is this somewhere available?
>>>
>>> I learned by this thread that some marker interface are not
Vadim Gritsenko wrote:
> >So the remaining question is, is fortress/merlin stable and usable?
> >If these both points can be answered positiv, I would say: +1.
> >
>
> -1 for 2.1. If you read this thread, you will see that the changes are
> too drastic to make this in 2.1, and it already has loa
Stephan Michels wrote:
>On Tue, 24 Sep 2002, Vadim Gritsenko wrote:
>
>
>
>>Carsten Ziegeler wrote:
>>
>>
>>
>>>Giacomo Pati wrote:
>>>
>>>
>>>
>>>
Hi Team
I'll have some spare time this week and thought of moving the HEAD branch
away from deprecated stuff from newest
Carsten Ziegeler wrote:
>Ok, I think we should have a look at a features list of fortress
>and merlin compared to the ECM.
>
The closest thing I can point you to is the Merlin FAQ which provides a
summary of the differences between Merlin and other related work in
Avalon land.
http://jaka
Berin Loritsch wrote:
> Carsten Ziegeler wrote:
>
>> Ok, I think we should have a look at a features list of fortress
>> and merlin compared to the ECM.
>>
>> Is this somewhere available?
>>
>> I learned by this thread that some marker interface are not
>> available anymore and have to be confi
Stephan Michels wrote:
>
> On Tue, 24 Sep 2002, Vadim Gritsenko wrote:
> For some time ago, I tried to replace also the deprecated LogKitManageable
> classes, but the Avalon people don't want to apply my patch :-/
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=11491
I think it has more t
On Tue, 24 Sep 2002, Vadim Gritsenko wrote:
> Carsten Ziegeler wrote:
>
> >Giacomo Pati wrote:
> >
> >
> >>Hi Team
> >>
> >>I'll have some spare time this week and thought of moving the HEAD branch
> >>away from deprecated stuff from newest Avalon Framework/Excalibur jars.
> >>
> >>My plan will
Carsten Ziegeler wrote:
>Giacomo Pati wrote:
>
>
>>Hi Team
>>
>>I'll have some spare time this week and thought of moving the HEAD branch
>>away from deprecated stuff from newest Avalon Framework/Excalibur jars.
>>
>>My plan will be:
>>
>> 1. Get rid of Loggable in favor of LogEnabled
>> 2
Berin wrote:
>Could you put some line breaks in your messages?
Yeah, I know, this webmail client isn't nice to work with. Sorry about that :-(
>I only use reflection when there is no better alternative.
OK, agreed. I thought I'd just issue the warning. But I guess you know what you're
doing
On Tue, Sep 24, 2002 at 04:10:04PM +0200, Carsten Ziegeler wrote:
> Ok, I think we should have a look at a features list of fortress
> and merlin compared to the ECM.
>
> Is this somewhere available?
Merlin docs are at:
http://jakarta.apache.org/avalon/excalibur/merlin/i
Tom Klaasen wrote:
>
> [EMAIL PROTECTED] wrote:
>
>
>
>>
>>It's not that bad--not that pretty either. However it allows us to
>>handle the Recyclable issues well. Otherwise I have to use reflection
>>to determine if it implements
>>"org
[EMAIL PROTECTED] wrote:
>Tom Klaasen wrote:
>> Berin wrote:
>>
>>
We need a way to invoke the recycle() method in the current implementations,
so a support for Recyclable is required.
>>>
>>>:) I can do that without requiring
Carsten Ziegeler wrote:
> Ok, I think we should have a look at a features list of fortress
> and merlin compared to the ECM.
>
> Is this somewhere available?
>
> I learned by this thread that some marker interface are not
> available anymore and have to be configured somewhere for fortress.
> Is
Ok, I think we should have a look at a features list of fortress
and merlin compared to the ECM.
Is this somewhere available?
I learned by this thread that some marker interface are not
available anymore and have to be configured somewhere for fortress.
Is this right?
So which marker interface
Peter Royal wrote:
> On Tuesday, September 24, 2002, at 09:47 AM, Sylvain Wallez wrote:
>
>> Carsten Ziegeler wrote:
>>
>>> Berin Loritsch wrote:
>>>
Fortress is moving toward a MetaInfo enabled component matching system,
but that is done in a separate container. You will be able to t
Tom Klaasen wrote:
> Berin wrote:
>
>
>>>We need a way to invoke the recycle() method in the current implementations,
>>>so a support for Recyclable is required.
>>
>>:) I can do that without requiring that interface! I will use the
>>reflection facilities to determine if there is a "recycle(
On Tuesday, September 24, 2002, at 09:47 AM, Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>> Berin Loritsch wrote:
>>> Fortress is moving toward a MetaInfo enabled component matching
>>> system,
>>> but that is done in a separate container. You will be able to take
>>> advantage of that when
Carsten Ziegeler wrote:
>Thanks for clarification, Berin! Inline are some comments:
>
>Berin Loritsch wrote:
>
>
>>>What does this mean in terms of compatibility and a stable Cocoon? Are
>>>written components using a CM with Composable and Component still working?
>>>
>>>
>>>I think noone
Berin wrote:
>> We need a way to invoke the recycle() method in the current implementations,
>> so a support for Recyclable is required.
>
>:) I can do that without requiring that interface! I will use the
>reflection facilities to determine if there is a "recycle()" method
>with public access
Marcus Crafter wrote:
> On Tue, Sep 24, 2002 at 03:04:59PM +0200, Carsten Ziegeler wrote:
>
>>>My question for you guys is whether you want me to force you to change
>>>your interface for Resettable, or to have MPool work by reflection and
>>>discover if there is a reset() method with public acce
Carsten Ziegeler wrote:
> Thanks for clarification, Berin! Inline are some comments:
>
> Berin Loritsch wrote:
>>The biggest thing you will have to do to migrate to Fortress is to
>>change your cocoon.roles file format. It is the roles file that now
>>determines the "lifestyle" of a component,
On Tue, Sep 24, 2002 at 03:04:59PM +0200, Carsten Ziegeler wrote:
>
> > My question for you guys is whether you want me to force you to change
> > your interface for Resettable, or to have MPool work by reflection and
> > discover if there is a reset() method with public access. If that is
> > t
Thanks for clarification, Berin! Inline are some comments:
Berin Loritsch wrote:
> >
> > What does this mean in terms of compatibility and a stable Cocoon? Are
> > written components using a CM with Composable and Component
> still working?
> > I think noone will recode all the components he has
Carsten Ziegeler wrote:
> Giacomo Pati wrote:
>
>>Hi Team
>>
>>I'll have some spare time this week and thought of moving the HEAD branch
>>away from deprecated stuff from newest Avalon Framework/Excalibur jars.
>>
>>My plan will be:
>>
>> 1. Get rid of Loggable in favor of LogEnabled
>> 2.
Giacomo Pati wrote:
>
> Hi Team
>
> I'll have some spare time this week and thought of moving the HEAD branch
> away from deprecated stuff from newest Avalon Framework/Excalibur jars.
>
> My plan will be:
>
>1. Get rid of Loggable in favor of LogEnabled
>2. Get rid of Component and m
Giacomo Pati wrote:
>Hi Team
>
>I'll have some spare time this week and thought of moving the HEAD branch
>away from deprecated stuff from newest Avalon Framework/Excalibur jars.
>
>My plan will be:
>
> 1. Get rid of Loggable in favor of LogEnabled
>
Good idea.
> 2. Get rid of Component
Hi Team
I'll have some spare time this week and thought of moving the HEAD branch
away from deprecated stuff from newest Avalon Framework/Excalibur jars.
My plan will be:
1. Get rid of Loggable in favor of LogEnabled
2. Get rid of Component and move to Service infrastructure
1. is str
39 matches
Mail list logo
