You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Giacomo Pati <gi...@apache.org> on 2002/09/23 13:05:08 UTC
Getting rid of deprecated Interfaces/Classes/Methods
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 straight forward and doesn't need any voting I think
2. can be done in two steps:
a. move from Component to Service infrastructure as the
ExcaliburComponentManager supports this.
b. use Fortress/Merlin (don't know the status of those and which one
makes more sense for Cocoon to be used, so I need some advice of
Avalonians here)
Ok, can those of you more familiar with Fortress/Merlin (Berin?) give some
status about those ServiceManagers and also a suggestion to move the b.
step or to postpone it for later because of the status of hose
ServiceManagers?
I know using one of these ServiceManagers means rewriting the
configuration files and/or use additional tools like phoenix-xdoclet
NB: why is that tool so phoenix specific? Should be a avalon-doclet more
appropriate or have I missed some discussion on Avalonland?
What are the drawbacks I will face?
What do I have missed in my reflections?
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Stephen McConnell <mc...@apache.org>.
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 and move to Service infrastructure
>
>
Dito.
>1. is straight forward and doesn't need any voting I think
>
>2. can be done in two steps:
>
> a. move from Component to Service infrastructure as the
>ExcaliburComponentManager supports this.
>
> b. use Fortress/Merlin (don't know the status of those and which one
>makes more sense for Cocoon to be used, so I need some advice of
>Avalonians here)
>
I'm available to help out with any tests related to Merlin. In practice
the ideal solution would be complete protability of components between
either Merlin or Fortress (something that both Berin and I are aiming
towards). Berin has recently added lifestyle support to Merlin whcih
bring both Merlin and Fortress to an equivalent level on that front -
and lifecycle estensions between Fortress and Merlin are interchangable.
The main differences not are the Fortress orientation with role manager
(which does not exist in Merlin) and the Merlin strong support for
meta-info (which is at inital stage of development in Fortress).
>
>Ok, can those of you more familiar with Fortress/Merlin (Berin?) give some
>status about those ServiceManagers and also a suggestion to move the b.
>step or to postpone it for later because of the status of hose
>ServiceManagers?
>
Both Merlin and Fortress support both the ComponentManager and
ServiceManager interfaces. However, it's a very good idea to move from
ComponentManager to ServiceManager because you reduce the degree of
"Avalon" lockin. It's much easier to use external objects as service
providers and publish legacy applications as component solutions (and
the transition isn't that difficult).
>
>I know using one of these ServiceManagers means rewriting the
>configuration files and/or use additional tools like phoenix-xdoclet
>
>NB: why is that tool so phoenix specific? Should be a avalon-doclet more
>appropriate or have I missed some discussion on Avalonland?
>
>
The phoneix-xdoclet content deals with component descriptors that are
specific to phoenix. A more comprehensive component descriptor API that
is used by both Merlin and Fortress is the excalibur/meta package - but
it does not include xdoclet support at this time Using xdoclet as the
generation mechanism is somewhat painful (today) because the xdoclet
APIs have yet to be finalized. As an interim mesure its easy to write
descriptors by hand (lots of examples over in the excalibur/assembly
package).
>What are the drawbacks I will face?
>
>
The primary objective should be to deliver container independent
components. This basically means not using a container API unless you
are specifically dealing with a deployment tool of some kind. From this
point of view your in safe territory if you use the excalibur/meta
package for the component descriptors and the excalibur/container
package with respect to lifecycle extensions.
>What do I have missed in my reflections?
>
>
One of the main "issues" concerning ECM to "container" migration
concerns the role management legacy from ECM. This is included in
Fortress but not in Merlin. In effect the Merlin container provides
similar functionality to the role manager through the use of the
meta-model - at the end of the day you have a much stronger API but its
an overhead to be dealt with when considering transition.
Cheers, Steve.
>Giacomo
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Stephen McConnell <mc...@apache.org>.
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 version of Avalon?
>
>Answer this.
>
Hi Stafano:
As a author of one of those new-fangled containers I thought I'd put
together one or two comments concerning the relationship between
containers, Avalon 4, Avalon 5 (based on your defintion) and a couple of
Cocoon related observations.
Where Cocoon is today:
----------------------
There is a *very* big difference between an active lookup (ECM,
Fortress) verus a scoped lookup (Merlin, Phoneix) - two different models
that have existed in the Avalon community for a long time now. Based on
the Avalon 4 spec for a component or service manager, the role key is
determined by the implementation (i.e. specification of lookup semantics
are minimal). In terms of project like Cocoon, a pure Avalon model
would ensure that your client components are interacting with a
container through things like service and component managers - they are
NOT interacting with the container. But in reality Cocoon is based on
ECM and ECM blurs the distinction between the manager and container.
Cocoon isn't strict Avalon - its Avalon + ECM - a.k.a. Avalon 4 + an
active lookup implementation policy + ECM semantics + ECM role
management semantics (which is not a perfect world).
Avalon 4 versus 5
-----------------
I like your distinction between A4 and A5 (noteably the question of
marker interfaces). Its the kind of defintion that makes me feel a lot
more comfortable about a possible emergence of A5 (if and when).
Following along this line of thinking, its perfectly reasonable to
envisage the introduction of things like a formal seperation of lookup
semantics, leading to the eliminating of the inconsitencies that exist
today in the Avalon 4 specification. Secondly, it provides a clean
defintion of what backward compatability would mean realtive to Avalon 5
in a way that has not been well articulted todate.
On containment strategies:
----------------------------
In that other email I suggested something along the lines of a Cocoon
subproject that explores the internal "container" achitecture needed for
Cocoon - because when you get inside Cocoon it looks like, smells like,
and feels like a container. But this does not mean that these aspects
should be exposed to client components. The Avalon 4 model provides the
component and service manager (and those other assorted things like
configuration, parameters, context etc.) as the contract towards a
client - and the client exposes marker interfaces as its defintion of
itself towards the container - but none of this dictates what the
container is, or how it fuctions with respect to compliance with Avalon
4 or 5. For example, a Cocoon core container could be build using an
advanced meta-driven container that provided the services required by
any Avalon 4 (or 5) based component.
Personally I'm not looking at this as a migration strategy - instead, I
looking at this is a 100% compatible engineering evolution - the
development of a a Cocoon 3.x core containment architecture that
replaces the ECM based architecture and delivers totally seamless
support for components as they exist today (including all of those
implied semantics).
Does that make sense?
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Berin Loritsch <bl...@apache.org>.
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>> Stefano Mazzocchi wrote:
>>
>>
>>> -1 for 2.1, no question about it.
>>>
<snip/>
>>> Let me repeat this for those worried guys that are reading this thread:
>>>
>>> WE WILL NOT CHANGE FUNDAMENTAL CONTRACTS UNDER YOUR FEET
>>>
>>>
>>
>> Couldn't have said this better - and really don't mean this ironically.
>>
>> So, let's put this with the blocks on our new list for 2.2.
>>
>>
>
> +1. Same feeling about Stefano's answer : we *need* stability, or nobody
> will want to use Cocoon for a large or long-lived project.
We (at Avalon) will provide you with it. I agree that you need to get
2.1 out the door. No issues with that. In the mean time, while you
take care of Cocoon 2.1, we will be preparing for the release of
Fortress 1.0. That process will require the release of all the packages
it relies on before hand. That release includes documentation,
testcases, etc. The Documentation has four main focuses: What (is it?),
When (to use it), Why (it was developed), and How (to use it). The
first of such releases will occur soon (for the Event Package).
Looking forward to the Fortress release, here is what you can expect:
* One big jar with all of its dependencies included.
* ANT and utility class enabled migration of ECM RoleManager config
files to Fortress Config files.
* ANT and utility class enabled migration of ECM configuration files
to Fortress Config files.
* Easier migration from *needing* a ComponentSelector to not needing
one.
* Faster execution and more efficient pool management. NO NEED TO
EXPLICITLY SET POOL SIZES!!!
* An additional lifestyle: per-thread. That means each thread of
execution has its own component, which is shared with any component
requesting it. It works really nicely in Servlet environments...
* Good documentation
* Well tested environment.
* Ability to extend and create your own containers with relative ease.
The only things left in this list is the conversion utilities, and
documentation. There might be a couple more testcases to write, but
the system has been thoroughly tested.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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 change to the 2.x
>>family of Cocoon releases if some fundamental contract like marking
>>interface to represent component behavior stop working.
>>
>>My suggestion to the current avalon developers that share Cocoon's
>>concerns (not all of them do) is: think incrementally, think about
>>migrations paths, think about small evolutionary steps.
>>
>>I know (by experience) that this is extremely hard to do (or take a huge
>>amount of time and energy) but Cocoon *is* a stable technology and we
>>want to continue it to be.
>>
>>We will not change some fundamental interfaces or contracts any time
>>soon.
>>
>>Let me repeat this for those worried guys that are reading this thread:
>>
>> WE WILL NOT CHANGE FUNDAMENTAL CONTRACTS UNDER YOUR FEET
>>
>>
>>
>Couldn't have said this better - and really don't mean this ironically.
>
>So, let's put this with the blocks on our new list for 2.2.
>
>
+1. Same feeling about Stefano's answer : we *need* stability, or nobody
will want to use Cocoon for a large or long-lived project.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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 Cocoon releases if some fundamental contract like marking
> interface to represent component behavior stop working.
>
> My suggestion to the current avalon developers that share Cocoon's
> concerns (not all of them do) is: think incrementally, think about
> migrations paths, think about small evolutionary steps.
>
> I know (by experience) that this is extremely hard to do (or take a huge
> amount of time and energy) but Cocoon *is* a stable technology and we
> want to continue it to be.
>
> We will not change some fundamental interfaces or contracts any time
> soon.
>
> Let me repeat this for those worried guys that are reading this thread:
>
> WE WILL NOT CHANGE FUNDAMENTAL CONTRACTS UNDER YOUR FEET
>
Couldn't have said this better - and really don't mean this ironically.
So, let's put this with the blocks on our new list for 2.2.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Stefano Mazzocchi <st...@apache.org>.
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 loads of changes by
> itself. This asks for at least 2.5, or even 3.0.
-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 Cocoon releases if some fundamental contract like marking
interface to represent component behavior stop working.
My suggestion to the current avalon developers that share Cocoon's
concerns (not all of them do) is: think incrementally, think about
migrations paths, think about small evolutionary steps.
I know (by experience) that this is extremely hard to do (or take a huge
amount of time and energy) but Cocoon *is* a stable technology and we
want to continue it to be.
We will not change some fundamental interfaces or contracts any time
soon.
Let me repeat this for those worried guys that are reading this thread:
WE WILL NOT CHANGE FUNDAMENTAL CONTRACTS UNDER YOUR FEET
Got it? Should I repeat it again? no? great.
If a new component container doesn't allow my home-made avalon
components to run as they did before, this new component container will
not make it into Cocoon, unless an *easy* *well-documented* *simple* and
*effective* migration solution is offered to the user (and to our cocoon
developers as well).
Sure, 15:1 performance ratio is killer, but how much of that performance
improvement goes into our perceived performance when all our pipeline
components are pooled and 80% of our average pipeline time is spent into
xslt processing?
Please, don't take me wrong: I'm the biggest fan of clean and well
designed frameworks (after all, I'm the one who started Avalon,
remember?), but as Avalon 4 took 4 years to become a reality, I'm all
for waiting maybe even *years* before switching to anything new on this
side.
Yeah, I know that a new CM is not Avalon 5, but I'm fear the fact that
with metacoding (that is: xdoclet-like behavioral metadata), the
separation between the two becomes accademic (and it is, in fact,
happening).
So, Avalon 4 states clearly that component behavior is based on marking
interfaces.
Avalon 5 wants to deprecate these in favor of external metadata for a
number of (admittedly good) reasons.
The modern Avalon containers (fortress/merlin/phoenix) deprecate marking
interfaces to define behavior.
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 version of Avalon?
Answer this.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Vadim Gritsenko <va...@verizon.net>.
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 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 straight forward and doesn't need any voting I think
>>>>
>>>>
>>>>
>>>>
>>>>
>>>Yupp. +1
>>>
>>>
>>>
>
>I get also rid of the deprecated classes, so +1.
>
>
>
>>+1. Some of this work is done already, by Stefan (IIRC).
>>
>>
>
>Do you mean Stefano, or do you mean moi(Stephan)?
>
You. :)
Vadim
>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
>
>
>
>>>>2. can be done in two steps:
>>>>
>>>> a. move from Component to Service infrastructure as the
>>>>ExcaliburComponentManager supports this.
>>>>
>>>> b. use Fortress/Merlin (don't know the status of those and which one
>>>>makes more sense for Cocoon to be used, so I need some advice of
>>>>Avalonians here)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>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 written so far. But
>>>I guess that this is covered.
>>>
>>>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 loads of changes by
>>itself. This asks for at least 2.5, or even 3.0.
>>
>>
>
>Couldn't we release the damn 2.1, and remove all the deprecated classes?
>Then we will have enough room to migrate to Fortress/Merlin or whatever.
>
>Stephan.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Berin Loritsch <bl...@apache.org>.
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 to do with the fact that we are all busy and
it keeps slipping through the cracks.
>>>>2. can be done in two steps:
>>>>
>>>> a. move from Component to Service infrastructure as the
>>>>ExcaliburComponentManager supports this.
>>>>
>>>> b. use Fortress/Merlin (don't know the status of those and which one
>>>>makes more sense for Cocoon to be used, so I need some advice of
>>>>Avalonians here)
>>>>
>>>>
>>>>
>>>
>>>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 written so far. But
>>>I guess that this is covered.
>>>
>>>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 loads of changes by
>>itself. This asks for at least 2.5, or even 3.0.
>
>
> Couldn't we release the damn 2.1, and remove all the deprecated classes?
> Then we will have enough room to migrate to Fortress/Merlin or whatever.
By all means, release 2.1. Don't migrate to Fortress until there is an
official release--which I believe work is starting on it now.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Stephan Michels <st...@apache.org>.
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 be:
> >>
> >> 1. Get rid of Loggable in favor of LogEnabled
> >> 2. Get rid of Component and move to Service infrastructure
> >>
> >>1. is straight forward and doesn't need any voting I think
> >>
> >>
> >>
> >Yupp. +1
> >
I get also rid of the deprecated classes, so +1.
> +1. Some of this work is done already, by Stefan (IIRC).
Do you mean Stefano, or do you mean moi(Stephan)?
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
>
> >>2. can be done in two steps:
> >>
> >> a. move from Component to Service infrastructure as the
> >>ExcaliburComponentManager supports this.
> >>
> >> b. use Fortress/Merlin (don't know the status of those and which one
> >>makes more sense for Cocoon to be used, so I need some advice of
> >>Avalonians here)
> >>
> >>
> >>
> >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 written so far. But
> >I guess that this is covered.
> >
> >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 loads of changes by
> itself. This asks for at least 2.5, or even 3.0.
Couldn't we release the damn 2.1, and remove all the deprecated classes?
Then we will have enough room to migrate to Fortress/Merlin or whatever.
Stephan.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Vadim Gritsenko <va...@verizon.net>.
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. Get rid of Component and move to Service infrastructure
>>
>>1. is straight forward and doesn't need any voting I think
>>
>>
>>
>Yupp. +1
>
+1. Some of this work is done already, by Stefan (IIRC).
>>2. can be done in two steps:
>>
>> a. move from Component to Service infrastructure as the
>>ExcaliburComponentManager supports this.
>>
>> b. use Fortress/Merlin (don't know the status of those and which one
>>makes more sense for Cocoon to be used, so I need some advice of
>>Avalonians here)
>>
>>
>>
>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 written so far. But
>I guess that this is covered.
>
>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 loads of changes by
itself. This asks for at least 2.5, or even 3.0.
Vadim
>Carsten
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Berin Loritsch <bl...@apache.org>.
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 access. If that is
>>>the case, then MPool would be able to call it--whether there was an
>>>interface or not. I think the latter would be preferable, as it is
>>>much more flexible--I just need to make it explicit that is what is
>>>happening.
>>>
>>
>>We need a way to invoke the recycle() method in the current implementations,
>>so a support for Recyclable is required.
>
>
> This could be done with an Accessor lifecycle extension.
Yep. However, unless you include the old Pool package, the Recyclable
interface won't be accessible. It doesn't conflict in any way with
Fortress, it is just extra bulk--all for one interface.
Also, the experimental Lifecycle Extension mechanism will allow you
to do things that you probably wish you could with Cocoon, but otherwise
can't.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
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
> > the case, then MPool would be able to call it--whether there was an
> > interface or not. I think the latter would be preferable, as it is
> > much more flexible--I just need to make it explicit that is what is
> > happening.
> >
>
> We need a way to invoke the recycle() method in the current implementations,
> so a support for Recyclable is required.
This could be done with an Accessor lifecycle extension.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Berin Loritsch <bl...@apache.org>.
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 take
>>>> advantage of that when it is done. Also, Fortress has a "big jar" that
>>>> includes all the Excalibur dependencies in one JAR file.
>>>>
>>
>> IIRC (didn't follow closely Avalon for some time), this meta-info is
>> stored in a resource file near the component's class. IMHO, this will
>> certainly seem complicated to average users that simply want to add an
>> action or a generator. Also, using a doclet adds an extra step in the
>> build process that doesn't make it much less complicated.
>
>
> You are not required to have the "meta-info as separate XML documents"
> to use fortress. It is an optional feature, one that is mainly designed
> to help with component portability between Avalon containers (and a
> non-issue for actions or generators as they are cocoon-specific
> components).
>
> The meta-info issue that Cocoon will face is where to store the
> lifestyle of a sitemap component. It used to be the marker interface,
> but those are gone. Fortress currently stores that information in the
> roles file, but we don't want to require Cocoon users to add all sitemap
> component metainfo to a roles file either.
>
> I believe it will be possible to create a custom Fortress container that
> still obeys the lifestyle interfaces though.
Absolutely. Just extend the AbstractContainer like DefaultContainer
does.
>>> Argh...sorry, I don't want to question this, but I simply do not like
>>> it. What will happen if I write a "SingleThreaded" implementation and
>>> configure it as ThreadSafe...
>>>
>>
>> Same feeling : implementing a marker interface seems to me more
>> intuitive and straightforward that writing a meta-info file.
>
>
> Agreed. However I *do* find it easier to specify the lifestyle in the
> roles document for container components (I have been guilty of
> forgetting to add ThreadSafe to components and dealing with the pain of
> having it be SingleThreaded by default).
>
> As mentioned above, you won't have to deal with meta-info files for
> Cocoon. Cocoon.roles can stay with a single added parameter per
> component of what lifestyle to use.
right.
>> Last note (I know, it may be late for it now), the name of the
>> service() method of the Serviceable interface doesn't seems well
>> chosen to me. This name is more suited for a method that asks the
>> component to perform its job, like in Servlet.service() than a method
>> that gives a component the means to link itself to other components or
>> services. "compose" was good (a system is composed of services) and
>> having compose(ServiceManager) doesn't conflict with
>> compose(ComponentManager).
>
>
> Interesting suggestion :) I believe it was changed to prevent confusion
> with the old method name. I do agree that the name service() is not as
> "intuitive" to the function performed as compose() was. You aren't the
> first to bring this up since the change happened.
> -pete
Unfortunately it is not easy to change now.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Cocoon container strategy?
Posted by Stephen McConnell <mc...@apache.org>.
Marcus Crafter wrote:
>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.
>>
>>
I thought it may be a good idea to bring up some of the issues I see
concerning ECM/Cocoon migration. First of all - a disclaimer - I've only
recently signed up to the Cocoon list and I've only been using Cocoon
for a couple of months - on the other-hand, I've been looking into the
Cocoon implementation and ECM related issues and I've been thinking
about future development - in particular the deployment of Cocoon in
Merlin as a peer service amongst a bunch of other business level
components. As such, my comments may be out-of-sync with current
thinking - so please feel free to correct me if I'm heading of in a bad
direction.
Firstly - my understanding of the Cocoon/Avalon/ECM relationship. Way
back at least a couple of years ago - there were two different
approaches to component management in the Avalon community. One approach
was ECM, the other approach was Phoenix. ECM represented a dynamic
request model (passing service interface names into the lookup
operation). The Phoenix approach leveraged meta information and enabled
role names to be scoped relative to the consuming component. I
checked-out both ECM and Phoenix in relation to my own service
management requirements at that time. I never really grasped the role
management stuff in ECM and preferred the cleaner meta-model approach in
Phoenix. As a result, I build and deployed many Phoenix based components
as part of a B2B application. In doing this I ran into a number of
limitations within Phoenix that prompted the development of Merlin 1.0 -
a container focussed on running a target component (without all of the
configuration and assembly complications). Merlin 1.0 achieved this
objective and has been in production use within dynamic component
deployment scenarios for about 12 months now. However, there were
limitations within Merlin 1.0 that let to the launch of the Merlin 2.0
project (under the excalibur/assembly package).
Merlin 2.0 took the principals of automated assembly from Merlin 1.0 and
added the following features:
- a continer hierachy
- deferred activation of components (and dependent components)
until the service is requested
- full support for singleton, per-thread, pooled and transient
lifestyle policies
- logging, context and configuration management
- the ability to declare packaged deployment profiles
- a full meta info and meta data API
- addition of lifecycle extensions
- ability to programmatically add and deploy new components at runtime
- programmatic container deployment
- container based classloader management
- extensions management
But lets get back to Cocoon - what we have in the Cocoon code base is
Cocoon "the container" which is currently implemented by an extended
ECM. This is problematic because the ECM isn't really a container - it
is a complicated component manager. This brings up the migration
strategy - moving Cocoon from its current ECM based implementation to a
proper container architecture. I don't think that the right thing
"today" is to choose one container or another - in particular, while the
current Fortress and Merlin containers do similar things, they approach
the same problem in different ways - present different benefits - imply
different design decisions.
Selecting Merlin or Fortress today would slow down Fortress/Merlin
convergence and co-development activities - but more importantly - it
bypasses important questions that need to addressed with respect to the
Cocoon architecture. In both the Merlin and Fortress case (but much more
so in the Merlin scenario) your looking at a transition to meta-based
component management. This has an impact on the overall design of the
core of Cocoon - and that's much more critical.
My suggestion would be setup a separate project dealing with
"meta-based" Cocoon trial and validation. That project should be able to
establish the scope of formal container functional requirements. This
will identify the container you need - things that Merlin provides such
as dynamic component deployment are unique to Merlin - if that a
requirement then what you really want is a couple of potential solution
- putting in place such a project would allow the identification of
those requirement - and I'm confident you would end up with either (a) a
single container solution (based on a converged Merlin/Fortress), or (b)
Merlin hosting Fortress, or (c) either Merlin or Fortess both capable of
handling deployment of portable components.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
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/index.html
Fortress docs are at:
http://jakarta.apache.org/avalon/excalibur/fortress/index.html
More Fortress docs are still coming though.
> I learned by this thread that some marker interface are not
> available anymore and have to be configured somewhere for fortress.
> Is this right?
Yes.
> So which marker interfaces are concerned? C
The lifestyle interfaces, like ThreadSafe, SingleThreaded, and
Poolable.
> How much effort is it to still support those marker interfaces without
> needing the extra configuration?
Not sure there, the container authors can probably answer that one best.
IMO I think it's a good move that they are no longer part of the class
definition. Berin already mentioned the subclassing problem when
specifying component lifestyles as interfaces, and when it's part of
the configuration, it doesn't take a recompile for lifestyle changes
to take affect.
The good thing about the meta-data approach is that while it's
more complex, it offers us much more control over the quality and
stability of the system. meta-data lets us and our users define
Component, Version and Context dependencies (amongst other things)
that can all be satisfied or rejected before Cocoon even starts
processing requests.
On top of that it provides a good architecture for other
developments like blocks. :)
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Berin Loritsch <bl...@apache.org>.
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
>>> available anymore and have to be configured somewhere for fortress.
>>> Is this right?
>>> So which marker interfaces are concerned? C
>>> How much effort is it to still support those marker interfaces without
>>> needing the extra configuration?
>>
>>
>>
>> There is no way to do it in Merlin. There are other things such as
>> no real support for the ServiceSelector.
>
>
>
> Both of these points can be dealt with using a lifestyle manager. The
> current implemetation does not currently provide support for the
> Selector interface - instead selection policy is provided to the
> container and the client will receive the preferred selection based on
> the supplied policy. A second reason is that the policy of appending the
> string "Selector" to an interface as the means though which policy is
> declared to a container is inconsitent with the concept of component
> scoped role names. Finally, logical concerning selection can be far
> reaching - Merlin provides support for the dynamic creation of
> components, different component profiles, programmatically constructured
> component profiles, etc. Simply requesting all know services of a
> particular type under a component selector forces the instantiation of
> all candidate profiles - whereas supplying the selection policy enables
> the container to do the selection without actually instantiating the
> component - in fact components are not normally instantiated until the
> client actually invokes lookup on the component or service manager.
My oppologies for some of our Avalon disagreements spilling over on
to Cocoon space. The bottom line is this: if you want things to
function as similarly as they have in the past, use Fortress in its
current incarnation. As we work through the disagreements (on the
Avalon Dev group) we will make our decisions public. I designed
Fortress to ease the migration from "Selector" to not needing it.
More on that will be posted on the web page when I write the docs.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Stephen McConnell <mc...@apache.org>.
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 configured somewhere for fortress.
>> Is this right?
>> So which marker interfaces are concerned? C
>> How much effort is it to still support those marker interfaces without
>> needing the extra configuration?
>
>
> There is no way to do it in Merlin. There are other things such as
> no real support for the ServiceSelector.
Both of these points can be dealt with using a lifestyle manager. The
current implemetation does not currently provide support for the
Selector interface - instead selection policy is provided to the
container and the client will receive the preferred selection based on
the supplied policy. A second reason is that the policy of appending the
string "Selector" to an interface as the means though which policy is
declared to a container is inconsitent with the concept of component
scoped role names. Finally, logical concerning selection can be far
reaching - Merlin provides support for the dynamic creation of
components, different component profiles, programmatically constructured
component profiles, etc. Simply requesting all know services of a
particular type under a component selector forces the instantiation of
all candidate profiles - whereas supplying the selection policy enables
the container to do the selection without actually instantiating the
component - in fact components are not normally instantiated until the
client actually invokes lookup on the component or service manager.
Cheers, Steve.
>
> With Fortress, it is relatively easy: extend AbstractContainer (like
> DefaultContainer does). Change the configure() method to act like
> the current ECM version.
>
> You can get the Recyclable interface working by implementing an Accessor
> lifecycle extension.
>
> As to a complete feature list, there is none out there--perhaps that
> can be a new documentation page.
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Berin Loritsch <bl...@apache.org>.
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 this right?
>
> So which marker interfaces are concerned? C
> How much effort is it to still support those marker interfaces without
> needing the extra configuration?
There is no way to do it in Merlin. There are other things such as
no real support for the ServiceSelector.
With Fortress, it is relatively easy: extend AbstractContainer (like
DefaultContainer does). Change the configure() method to act like
the current ECM version.
You can get the Recyclable interface working by implementing an Accessor
lifecycle extension.
As to a complete feature list, there is none out there--perhaps that
can be a new documentation page.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Stephen McConnell <mc...@apache.org>.
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://jakarta.apache.org/avalon/excalibur/merlin/faq.html
>
>Is this somewhere available?
>
In addition to the above, the Merlin documentation inlcudes:
The general Merlin 2.0 documetation
http://jakarta.apache.org/avalon/excalibur/merlin/
Merlin 2.0 APIs.
http://jakarta.apache.org/avalon/excalibur/merlin/api/
Excalibur Container
http://jakarta.apache.org/avalon/excalibur/container/
(Merlin 2.0 provides full support for the lifestyle - refer
attributes page)
and lifecycle extension mechanisms
Excalibur Meta (the meta info layer)
http://jakarta.apache.org/avalon/excalibur/meta
>
>I learned by this thread that some marker interface are not
>available anymore and have to be configured somewhere for fortress.
>Is this right?
>
Yep - instead of defining these sort characteristics through a maker
interface, the Merlin 2 approach enables component authoris to declare
this information in the meta-mode for the type. For example, you can
declare a atttrtibute "avalon:lifestyle" with a value of "pool",
"transient", "thread", etc. Details on attribute values related to
lifestyle are included under the link
http://jakarta.apache.org/avalon/excalibur/container/attributes.html
(end of page).
>
>So which marker interfaces are concerned? C
>How much effort is it to still support those marker interfaces without
>needing the extra configuration?
>
>
It is possible in Merlin providing you declare a customer lifestyle
manager. The default lifestyle manager does not support the lifestyle
marker interrfaces but it wouldn't be a big thing to create a manager
that checked for marker interfaces. This could declare at the system or
container level.
Cheers, Steve.
>Carsten
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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 interfaces are concerned? C
How much effort is it to still support those marker interfaces without
needing the extra configuration?
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Peter Royal <pr...@apache.org>.
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 it is done. Also, Fortress has a "big jar"
>>> that
>>> includes all the Excalibur dependencies in one JAR file.
>>>
>
> IIRC (didn't follow closely Avalon for some time), this meta-info is
> stored in a resource file near the component's class. IMHO, this will
> certainly seem complicated to average users that simply want to add an
> action or a generator. Also, using a doclet adds an extra step in the
> build process that doesn't make it much less complicated.
You are not required to have the "meta-info as separate XML documents"
to use fortress. It is an optional feature, one that is mainly designed
to help with component portability between Avalon containers (and a
non-issue for actions or generators as they are cocoon-specific
components).
The meta-info issue that Cocoon will face is where to store the
lifestyle of a sitemap component. It used to be the marker interface,
but those are gone. Fortress currently stores that information in the
roles file, but we don't want to require Cocoon users to add all
sitemap component metainfo to a roles file either.
I believe it will be possible to create a custom Fortress container
that still obeys the lifestyle interfaces though.
>> Argh...sorry, I don't want to question this, but I simply do not like
>> it. What will happen if I write a "SingleThreaded" implementation and
>> configure it as ThreadSafe...
>>
>
> Same feeling : implementing a marker interface seems to me more
> intuitive and straightforward that writing a meta-info file.
Agreed. However I *do* find it easier to specify the lifestyle in the
roles document for container components (I have been guilty of
forgetting to add ThreadSafe to components and dealing with the pain of
having it be SingleThreaded by default).
As mentioned above, you won't have to deal with meta-info files for
Cocoon. Cocoon.roles can stay with a single added parameter per
component of what lifestyle to use.
> Last note (I know, it may be late for it now), the name of the
> service() method of the Serviceable interface doesn't seems well
> chosen to me. This name is more suited for a method that asks the
> component to perform its job, like in Servlet.service() than a method
> that gives a component the means to link itself to other components or
> services. "compose" was good (a system is composed of services) and
> having compose(ServiceManager) doesn't conflict with
> compose(ComponentManager).
Interesting suggestion :) I believe it was changed to prevent confusion
with the old method name. I do agree that the name service() is not as
"intuitive" to the function performed as compose() was. You aren't the
first to bring this up since the change happened.
-pete
--
peter royal -> proyal@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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 will recode all the components he has written so far. But
>>>I guess that this is covered.
>>>
>>>
>>Fortress has a DefaultContainer that fits the best for Cocoon. In fact,
>>Cocoon can extend the DefaultContainer and add in any missing pieces it
>>needs to get the job done.
>>
>>In its current state, any Composable component will be able to access
>>any service (i.e. generic Object) due to the wonderful dynamic proxy
>>mechanism of JDK 1.3. As long as you are using JDK 1.3+ everything will
>>work fine.
>>
>Ah, ok - so he should shift to JDK 1.3 - this would solve some other
>problems in Cocoon as well.
>
>
But will unfortunately make it more difficult to port to less featured
platforms (teasing : see the abstract of my talk at outerthought's
gettogether).
>>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 it is done. Also, Fortress has a "big jar" that
>>includes all the Excalibur dependencies in one JAR file.
>>
>>
IIRC (didn't follow closely Avalon for some time), this meta-info is
stored in a resource file near the component's class. IMHO, this will
certainly seem complicated to average users that simply want to add an
action or a generator. Also, using a doclet adds an extra step in the
build process that doesn't make it much less complicated.
>>>So the remaining question is, is fortress/merlin stable and usable?
>>>If these both points can be answered positiv, I would say: +1.
>>>
>>>
>>Fortress is useable (others have used it without problem. Development
>>is still continuing on it, however it is being done in such a way as
>>to not cause problems with existing users.
>>
>>
>>
>Great.
>
>
>
>>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, and the marker interfaces
>>SingleThreaded, ThreadSafe, and Poolable do not have any meaning any
>>more.
>>
>Argh...sorry, I don't want to question this, but I simply do not like
>it. What will happen if I write a "SingleThreaded" implementation and
>configure it as ThreadSafe...
>
>
Same feeling : implementing a marker interface seems to me more
intuitive and straightforward that writing a meta-info file.
>>Your Poolable components would have to change because Fortress uses
>>the MPool package (part of the Event package). The Poolable and
>>Resettable interfaces are not there. I do need to provide a mechanism
>>for the MPool package so that we can reset components.
>>
>>
>Do you mean Resettable or Recyclable?
>
>
>
>>One of the nice things is that Cocoon will be able to handle more
>>load using Fortress. There is a profiling testcase that compares the
>>pure lookup/release cycles for Fortress vs. ExcaliburComponentManager,
>>and Fortress comes out ahead 15:1 (or more). The higher the load,
>>the better Fortress does. That figure even includes the proxied
>>ComponentManager implementation.
>>
>>
>Wow.
>
>
>
>>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
>>the case, then MPool would be able to call it--whether there was an
>>interface or not. I think the latter would be preferable, as it is
>>much more flexible--I just need to make it explicit that is what is
>>happening.
>>
Using reflexion hides Java's strong typing and makes mechanisms using it
obscure or semi-magical. It also makes life more difficult to automated
bytecode processing tools (still the port on small platforms). All this
makes me prefer a Resettable interface.
Last note (I know, it may be late for it now), the name of the service()
method of the Serviceable interface doesn't seems well chosen to me.
This name is more suited for a method that asks the component to perform
its job, like in Servlet.service() than a method that gives a component
the means to link itself to other components or services. "compose" was
good (a system is composed of services) and having
compose(ServiceManager) doesn't conflict with compose(ComponentManager).
Sorry for not being very constructive, but the power brought by the new
container infrastructure seems to me somehow hidden by the additional
constraints or annoyances it brings to the developper.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Berin Loritsch <bl...@apache.org>.
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, and the marker interfaces
>>SingleThreaded, ThreadSafe, and Poolable do not have any meaning any
>>more.
>>
>
> Argh...sorry, I don't want to question this, but I simply do not like
> it. What will happen if I write a "SingleThreaded" implementation and
> configure it as ThreadSafe...
Then it will act as ThreadSafe. What this change does is #1 prepares
you for the shift to true meta information (as close to attribute
driven development as Java will get), and #2 prevents any conflict
as to Lifestyle.
What happens if you have an abstract implementation of a component
that implements Poolable, but a concrete implementation that implements
ThreadSafe (more true to life)? That is an error, and it will cause
any container respecting those interfaces to reject your interface.
Now you have to look down the inheritance heirarchy to figure out what
to do about it! That is just bad. At least by configuring the
lifestyle in a separate file, you are not subject to any of the Java
class inheritance rules.
>>Your Poolable components would have to change because Fortress uses
>>the MPool package (part of the Event package). The Poolable and
>>Resettable interfaces are not there. I do need to provide a mechanism
>>for the MPool package so that we can reset components.
>
> Do you mean Resettable or Recyclable?
Recyclable--I was going by memory, and I haven't used the Pool package
in a while.
>>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
>>the case, then MPool would be able to call it--whether there was an
>>interface or not. I think the latter would be preferable, as it is
>>much more flexible--I just need to make it explicit that is what is
>>happening.
>>
>
>
> 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, and then call it. I will probably get that done
within the next couple of days.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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 written so far. But
> > I guess that this is covered.
>
> Fortress has a DefaultContainer that fits the best for Cocoon. In fact,
> Cocoon can extend the DefaultContainer and add in any missing pieces it
> needs to get the job done.
>
> In its current state, any Composable component will be able to access
> any service (i.e. generic Object) due to the wonderful dynamic proxy
> mechanism of JDK 1.3. As long as you are using JDK 1.3+ everything will
> work fine.
>
Ah, ok - so he should shift to JDK 1.3 - this would solve some other
problems
in Cocoon as well.
> 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 it is done. Also, Fortress has a "big jar" that
> includes all the Excalibur dependencies in one JAR file.
>
>
> > So the remaining question is, is fortress/merlin stable and usable?
> > If these both points can be answered positiv, I would say: +1.
>
> Fortress is useable (others have used it without problem. Development
> is still continuing on it, however it is being done in such a way as
> to not cause problems with existing users.
>
Great.
> 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, and the marker interfaces
> SingleThreaded, ThreadSafe, and Poolable do not have any meaning any
> more.
>
Argh...sorry, I don't want to question this, but I simply do not like
it. What will happen if I write a "SingleThreaded" implementation and
configure it as ThreadSafe...
> Your Poolable components would have to change because Fortress uses
> the MPool package (part of the Event package). The Poolable and
> Resettable interfaces are not there. I do need to provide a mechanism
> for the MPool package so that we can reset components.
Do you mean Resettable or Recyclable?
>
> One of the nice things is that Cocoon will be able to handle more
> load using Fortress. There is a profiling testcase that compares the
> pure lookup/release cycles for Fortress vs. ExcaliburComponentManager,
> and Fortress comes out ahead 15:1 (or more). The higher the load,
> the better Fortress does. That figure even includes the proxied
> ComponentManager implementation.
Wow.
>
> 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
> the case, then MPool would be able to call it--whether there was an
> interface or not. I think the latter would be preferable, as it is
> much more flexible--I just need to make it explicit that is what is
> happening.
>
We need a way to invoke the recycle() method in the current implementations,
so a support for Recyclable is required.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Berin Loritsch <bl...@apache.org>.
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. Get rid of Component and move to Service infrastructure
>>
>>1. is straight forward and doesn't need any voting I think
>>
>
> Yupp. +1
>
>
>>2. can be done in two steps:
>>
>> a. move from Component to Service infrastructure as the
>>ExcaliburComponentManager supports this.
>>
>> b. use Fortress/Merlin (don't know the status of those and which one
>>makes more sense for Cocoon to be used, so I need some advice of
>>Avalonians here)
>>
>
> 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 written so far. But
> I guess that this is covered.
Fortress has a DefaultContainer that fits the best for Cocoon. In fact,
Cocoon can extend the DefaultContainer and add in any missing pieces it
needs to get the job done.
In its current state, any Composable component will be able to access
any service (i.e. generic Object) due to the wonderful dynamic proxy
mechanism of JDK 1.3. As long as you are using JDK 1.3+ everything will
work fine.
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 it is done. Also, Fortress has a "big jar" that
includes all the Excalibur dependencies in one JAR file.
> So the remaining question is, is fortress/merlin stable and usable?
> If these both points can be answered positiv, I would say: +1.
Fortress is useable (others have used it without problem. Development
is still continuing on it, however it is being done in such a way as
to not cause problems with existing users.
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, and the marker interfaces
SingleThreaded, ThreadSafe, and Poolable do not have any meaning any
more.
Your Poolable components would have to change because Fortress uses
the MPool package (part of the Event package). The Poolable and
Resettable interfaces are not there. I do need to provide a mechanism
for the MPool package so that we can reset components.
One of the nice things is that Cocoon will be able to handle more
load using Fortress. There is a profiling testcase that compares the
pure lookup/release cycles for Fortress vs. ExcaliburComponentManager,
and Fortress comes out ahead 15:1 (or more). The higher the load,
the better Fortress does. That figure even includes the proxied
ComponentManager implementation.
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
the case, then MPool would be able to call it--whether there was an
interface or not. I think the latter would be preferable, as it is
much more flexible--I just need to make it explicit that is what is
happening.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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 move to Service infrastructure
>
> 1. is straight forward and doesn't need any voting I think
>
Yupp. +1
> 2. can be done in two steps:
>
> a. move from Component to Service infrastructure as the
> ExcaliburComponentManager supports this.
>
> b. use Fortress/Merlin (don't know the status of those and which one
> makes more sense for Cocoon to be used, so I need some advice of
> Avalonians here)
>
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 written so far. But
I guess that this is covered.
So the remaining question is, is fortress/merlin stable and usable?
If these both points can be answered positiv, I would say: +1.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Berin Loritsch <bl...@apache.org>.
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 has not been any -1). This can be done while
> we stay with ECM for now and have still backward compatability for all
> custom Components somebody has around for his private projects.
>
> But I have some questions about this move. We have classes named after
> the deprecated Interfaces (ie. CocoonComponentManger, ComposerAction). I'd
> like to hear your suggestion how we should deal with those:
>
> 1. don't change the names
> 2. rename them to appropriate names like CocoonServiceManager
> 3. create new one and deprecate the old ones
>
> What is your oppinion?
The CocoonComponentManager et. al. are internal classes that are used in
the core. They can be altered safely without breaking client code. The
ComposerAction OTOH is something that a client may have extended to
write their own Actions. In that case you *have* to do the deprecation
and new version.
My suggestion is to determine whether the class is really meant to be
used by users of Cocoon. That would include the abstract classes to
implement new pipeline components. If it is an internal component,
then you can easily change it without repurcussion.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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 least
>>>> until a
>>>> 2.1 release is out, right?
>>>>
>>>>
>>>
>>> Yupp.
>>>
>>>
>>>
>>>> I've allready commited the step 1 (Loggable -> LogEnabled).
>>>>
>>>>
>>>
>>> Nice work!
>>>
>>
>>
>> Thanks.
>>
>>
>>
>>>> Now I'm on step 2 (as there has not been any -1). This can be done
>>>> while
>>>> we stay with ECM for now and have still backward compatability for all
>>>> custom Components somebody has around for his private projects.
>>>>
>>>> But I have some questions about this move. We have classes named after
>>>> the deprecated Interfaces (ie. CocoonComponentManger,
>>>> ComposerAction). I'd
>>>> like to hear your suggestion how we should deal with those:
>>>>
>>>> 1. don't change the names
>>>> 2. rename them to appropriate names like CocoonServiceManager
>>>> 3. create new one and deprecate the old ones
>>>>
>>>> What is your oppinion?
>>>>
>>>>
>>>
>>> A definit -1 for 2, because people writing custom components use
>>> ComposerAction etc.
>>> as a base class, so we can't remove them.
>>> I think 3 is the way to go: deprecate the old ones and only create
>>> new ones
>>> where appropriate.
>>>
>>
>>
>> Ok, so your suggestions are what I'd thought of doing :).
>>
>> 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 = manager;
>> }
>>
>> public void recompose( ComponentManager manager )
>> {
>> this.manager = manager;
>> }
>>
>> Which was for the sake of the guideline from the Component packge and
>> can
>> be replace by a single service method.
>>
>> In other places I've seen code like this:
>>
>> public void compose( ComponentManager manager )
>> {
>> this.mainManager = manager;
>> this.manager = manager;
>> }
>>
>> public void recompose( ComponentManager manager )
>> {
>> this.manager = manager;
>> }
>>
>> which can be ported to:
>>
>> public void service( ServiceManager manager )
>> {
>> if( this.mainManager == null )
>> {
>> this.mainManager = manager;
>> }
>> this.manager = manager;
>> }
>>
>>
>
> This is the correct approach.
>
> When preparing the service package I excluded the Recomposable notion
> on the grounds that (a) it was insufficiently documented and
> insufficiently understood at the time, and (b) in terms of an
> interface - you can do exactly what you propose above - i.e. re-apply
> an invocation of service( manager ).
This should work well. However, recompose() is defined to be allowed to
happen at anytime after the component has been initialized or started,
whereas compose() is called only once during the component lifecycle. Is
calling "service()" several time allowed by the Serviceable contract ?
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
<snip/>
>>
>> which can be ported to:
>>
>> public void service( ServiceManager manager )
>> {
>> if( this.mainManager == null )
>> {
>> this.mainManager = manager;
>> }
>> this.manager = manager;
>> }
>>
>>
>
> This is the correct approach.
>
> When preparing the service package I excluded the Recomposable notion on
> the grounds that (a) it was insufficiently documented and insufficiently
> understood at the time, and (b) in terms of an interface - you can do
> exactly what you propose above - i.e. re-apply an invocation of service(
> manager ).
>
That is a distinct break from the Composable contracts. One of the main
reasons that the Recomposable interface was originally introduced (i.e.
back in the A3.0 days) was because you needed a different contract.
Composable was purely a creation-time contract. Recomposable was a
run/use-time contract. I think it is fundamentally wrong to mix the
two.
It is true, though--Recomposable was not very well thought out as far
as implications go. Essentially, we would need to proxy *every*
component looked up to ensure none of the re*** interfaces were exposed.
It imposes a security risk where a peer component can look up your
one component, and reassign the ComponentManager at will. That is
*bad*.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Stephen McConnell <mc...@apache.org>.
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?
>>>
>>>
>>>
>>Yupp.
>>
>>
>>
>>>I've allready commited the step 1 (Loggable -> LogEnabled).
>>>
>>>
>>>
>>Nice work!
>>
>>
>
>Thanks.
>
>
>
>>>Now I'm on step 2 (as there has not been any -1). This can be done while
>>>we stay with ECM for now and have still backward compatability for all
>>>custom Components somebody has around for his private projects.
>>>
>>>But I have some questions about this move. We have classes named after
>>>the deprecated Interfaces (ie. CocoonComponentManger, ComposerAction). I'd
>>>like to hear your suggestion how we should deal with those:
>>>
>>>1. don't change the names
>>>2. rename them to appropriate names like CocoonServiceManager
>>>3. create new one and deprecate the old ones
>>>
>>>What is your oppinion?
>>>
>>>
>>>
>>A definit -1 for 2, because people writing custom components use
>>ComposerAction etc.
>>as a base class, so we can't remove them.
>>I think 3 is the way to go: deprecate the old ones and only create new ones
>>where appropriate.
>>
>>
>
>Ok, so your suggestions are what I'd thought of doing :).
>
>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 = manager;
> }
>
> public void recompose( ComponentManager manager )
> {
> this.manager = manager;
> }
>
>Which was for the sake of the guideline from the Component packge and can
>be replace by a single service method.
>
>In other places I've seen code like this:
>
> public void compose( ComponentManager manager )
> {
> this.mainManager = manager;
> this.manager = manager;
> }
>
> public void recompose( ComponentManager manager )
> {
> this.manager = manager;
> }
>
>which can be ported to:
>
> public void service( ServiceManager manager )
> {
> if( this.mainManager == null )
> {
> this.mainManager = manager;
> }
> this.manager = manager;
> }
>
>
This is the correct approach.
When preparing the service package I excluded the Recomposable notion on
the grounds that (a) it was insufficiently documented and insufficiently
understood at the time, and (b) in terms of an interface - you can do
exactly what you propose above - i.e. re-apply an invocation of service(
manager ).
Cheers, Steve.
>Do I have your +1 for that?
>
>Giacomo
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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 = manager;
> }
>
> public void recompose( ComponentManager manager )
> {
> this.manager = manager;
> }
>
> Which was for the sake of the guideline from the Component packge and can
> be replace by a single service method.
>
> In other places I've seen code like this:
>
> public void compose( ComponentManager manager )
> {
> this.mainManager = manager;
> this.manager = manager;
> }
>
> public void recompose( ComponentManager manager )
> {
> this.manager = manager;
> }
>
> which can be ported to:
>
> public void service( ServiceManager manager )
> {
> if( this.mainManager == null )
> {
> this.mainManager = manager;
> }
> this.manager = manager;
> }
>
> Do I have your +1 for that?
>
Yes, this should work: +1
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Giacomo Pati <gi...@apache.org>.
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 commited the step 1 (Loggable -> LogEnabled).
> >
> Nice work!
Thanks.
> > Now I'm on step 2 (as there has not been any -1). This can be done while
> > we stay with ECM for now and have still backward compatability for all
> > custom Components somebody has around for his private projects.
> >
> > But I have some questions about this move. We have classes named after
> > the deprecated Interfaces (ie. CocoonComponentManger, ComposerAction). I'd
> > like to hear your suggestion how we should deal with those:
> >
> > 1. don't change the names
> > 2. rename them to appropriate names like CocoonServiceManager
> > 3. create new one and deprecate the old ones
> >
> > What is your oppinion?
> >
> A definit -1 for 2, because people writing custom components use
> ComposerAction etc.
> as a base class, so we can't remove them.
> I think 3 is the way to go: deprecate the old ones and only create new ones
> where appropriate.
Ok, so your suggestions are what I'd thought of doing :).
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 = manager;
}
public void recompose( ComponentManager manager )
{
this.manager = manager;
}
Which was for the sake of the guideline from the Component packge and can
be replace by a single service method.
In other places I've seen code like this:
public void compose( ComponentManager manager )
{
this.mainManager = manager;
this.manager = manager;
}
public void recompose( ComponentManager manager )
{
this.manager = manager;
}
which can be ported to:
public void service( ServiceManager manager )
{
if( this.mainManager == null )
{
this.mainManager = manager;
}
this.manager = manager;
}
Do I have your +1 for that?
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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 on step 2 (as there has not been any -1). This can be done while
> we stay with ECM for now and have still backward compatability for all
> custom Components somebody has around for his private projects.
>
> But I have some questions about this move. We have classes named after
> the deprecated Interfaces (ie. CocoonComponentManger, ComposerAction). I'd
> like to hear your suggestion how we should deal with those:
>
> 1. don't change the names
> 2. rename them to appropriate names like CocoonServiceManager
> 3. create new one and deprecate the old ones
>
> What is your oppinion?
>
A definit -1 for 2, because people writing custom components use
ComposerAction etc.
as a base class, so we can't remove them.
I think 3 is the way to go: deprecate the old ones and only create new ones
where appropriate.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Getting rid of deprecated Interfaces/Classes/Methods
Posted by Giacomo Pati <gi...@apache.org>.
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 be done while
we stay with ECM for now and have still backward compatability for all
custom Components somebody has around for his private projects.
But I have some questions about this move. We have classes named after
the deprecated Interfaces (ie. CocoonComponentManger, ComposerAction). I'd
like to hear your suggestion how we should deal with those:
1. don't change the names
2. rename them to appropriate names like CocoonServiceManager
3. create new one and deprecate the old ones
What is your oppinion?
Giacomo
On Mon, 23 Sep 2002, 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 move to Service infrastructure
>
> 1. is straight forward and doesn't need any voting I think
>
> 2. can be done in two steps:
>
> a. move from Component to Service infrastructure as the
> ExcaliburComponentManager supports this.
>
> b. use Fortress/Merlin (don't know the status of those and which one
> makes more sense for Cocoon to be used, so I need some advice of
> Avalonians here)
>
> Ok, can those of you more familiar with Fortress/Merlin (Berin?) give some
> status about those ServiceManagers and also a suggestion to move the b.
> step or to postpone it for later because of the status of hose
> ServiceManagers?
>
> I know using one of these ServiceManagers means rewriting the
> configuration files and/or use additional tools like phoenix-xdoclet
>
> NB: why is that tool so phoenix specific? Should be a avalon-doclet more
> appropriate or have I missed some discussion on Avalonland?
>
> What are the drawbacks I will face?
>
> What do I have missed in my reflections?
>
> Giacomo
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org