You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/08/29 17:25:47 UTC
[VOTE] Migrate from the aging ECM
The new Cocoon should be able to use the new Fortress container. This should
have little to no impact on component writers. It boasts faster startup, and
it provides easier component definition. I will be happy to do the work.
+1 from me.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: [VOTE] Migrate from the aging ECM
Posted by Jeff Turner <je...@apache.org>.
On Sat, Aug 30, 2003 at 08:59:42AM -0400, Geoff Howard wrote:
> Berin Loritsch wrote:
> >>>The new Cocoon should be able to use the new Fortress container.
> >>>This should have little to no impact on component writers. It
> >>>boasts faster startup, and it provides easier component definition.
> >>>I will be happy to do the work.
...
> Wouldn't it be better not to do this change on the 2.1.x line? I am
> assuming that this change would break back-compatibility in some points
> at least of custom components, etc. and that should be avoided on a
> released version.
+1 for doing it in 2.2.
--Jeff
> Could someone (Berin?) give an estimate of what the "damage" would be
> even if we agree it's a good move?
>
> Geoff
>
RE: [VOTE] Migrate from the aging ECM
Posted by Reinhard Poetz <re...@apache.org>.
> From: Berin Loritsch
> > If we to start migration to Fortress in 2.2..... I don't
> see a need in
> > avoiding this reformatting. If we do it in 2.1.2, then yes,
> we should
> > support old config syntax.
> >
>
> Well, when and where can I get started on 2.2?
I hope soon when we have finished the discussion about a new 2.2
repository.
Cheers,
Reinhard
Re: [VOTE] Migrate from the aging ECM
Posted by Berin Loritsch <bl...@apache.org>.
Vadim Gritsenko wrote:
>
> If we to start migration to Fortress in 2.2..... I don't see a need in
> avoiding this reformatting. If we do it in 2.1.2, then yes, we should
> support old config syntax.
>
Well, when and where can I get started on 2.2?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: [VOTE] Migrate from the aging ECM
Posted by Vadim Gritsenko <va...@verizon.net>.
<beware of snips/>
Berin Loritsch wrote:
> The above in Fortress would be redone as:
>
> <jdbc-datasource id="foo"/>
> <j2ee-datasource id="bar"/>
...
> In Fortress, you can do things the old ECM way, or you can incorporate
> the ID
> to get whichever component you want and bypass the selector completely
> like
> this:
>
> manager.lookup(DataSourceComponent.ROLE + "/foo");
...
> Lastly, a component that just wants whatever the default
> implementation for a
> component is only has to lookup the component it wants:
>
> manager.lookup(DataSourceComponent.ROLE);
>
> The default component is always the first one listed in the
> configuration file,
> unless that behavior is overridden. You can override the behavior by
> adding a
> default="true" attribute to a component. In the above example, the
> lookup for
> a DataSourceComponent.ROLE would return the "foo" variation. If the
> "bar"
> variation was altered like this:
>
> <j2ee-datasource id="bar" default="true"/>
Either I'm having a serious deja-vu here, or this is really similar to
whatever we had ages ago in avalon 3.0a3 (see NamedComponentManager)!
Which is good, I still have someone running on avalon 3.0 - it will make
migration easier...
> The way I propose working around it for the short term--to avoid the
> configuration reformatting
If we to start migration to Fortress in 2.2..... I don't see a need in
avoiding this reformatting. If we do it in 2.1.2, then yes, we should
support old config syntax.
Vadim
Re: [VOTE] Migrate from the aging ECM
Posted by Berin Loritsch <bl...@apache.org>.
Geoff Howard wrote:
>
> Great - I think we're all looking forward to this. I'm trying to get a
> handle on upgrade path for current users. Sounds like we could acheive
> drop-in support for the old cocoon.xconf format complete with my.roles
> etc. but could switch the default cocoon.xconf (or whatever it would be
> then called) to the newer format?
>
essentially.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: [VOTE] Migrate from the aging ECM
Posted by Geoff Howard <co...@leverageweb.com>.
Berin Loritsch wrote:
> Geoff Howard wrote:
>
>> Berin Loritsch wrote:
>>>
>>> In Cocoon/ECM we have the following constructs:
>>>
>>> <regular-component>
>>> <stuff/>
>>> </regular-component>
>>>
>>> <database-selector>
>>> <jdbc name="foo"/>
>>> <j2ee name="bar"/>
>>> <informix name="baz"/>
>>> </database-selector>
>>
>> Without a .roles file would we even have declarations that look like
>> this?
>
> :) That IS with the ECM roles file.
Sorry, snipped the wrong part - the examples which followed were what I
was looking at.
> However, with Fortress, you may be able to use a ROLEs file--but it
> won't be
> necessary. The meta info is part of the class, so there is only one
> place you
> need to manage it (with the component implementation class). The meta-info
> collection process will allow Fortress to automatically collect info
> from other
> JARs for the available components--which means there won't need to be
> any cludgy
> "user-roles" attributes any more. Things just work.
Great - I think we're all looking forward to this. I'm trying to get a
handle on upgrade path for current users. Sounds like we could acheive
drop-in support for the old cocoon.xconf format complete with my.roles
etc. but could switch the default cocoon.xconf (or whatever it would be
then called) to the newer format?
Geoff
Re: [VOTE] Migrate from the aging ECM
Posted by Berin Loritsch <bl...@apache.org>.
Geoff Howard wrote:
> Berin Loritsch wrote:
>
>>
>> In Cocoon/ECM we have the following constructs:
>>
>> <regular-component>
>> <stuff/>
>> </regular-component>
>>
>> <database-selector>
>> <jdbc name="foo"/>
>> <j2ee name="bar"/>
>> <informix name="baz"/>
>> </database-selector>
>
>
> Without a .roles file would we even have declarations that look like this?
:) That IS with the ECM roles file.
However, with Fortress, you may be able to use a ROLEs file--but it won't be
necessary. The meta info is part of the class, so there is only one place you
need to manage it (with the component implementation class). The meta-info
collection process will allow Fortress to automatically collect info from other
JARs for the available components--which means there won't need to be any cludgy
"user-roles" attributes any more. Things just work.
>
> Geoff
>
> (thanks for the patient summary and work by the way)
My pleasure.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: [VOTE] Migrate from the aging ECM
Posted by Geoff Howard <co...@leverageweb.com>.
Berin Loritsch wrote:
> Carsten Ziegeler wrote:
>>
>> I think we should do this switch asap. *If* we can solve the
>> commandmanager
>> issue discussed in the other thread, I will make a 2.1.1 release this
>> week.
>> Immediately after that work can start on the migration.
>>
>> Berin, you mention above in 3) that the configuration format changes
>> slightly.
>> Can you give a short explaination please?
>
>
> In Cocoon/ECM we have the following constructs:
>
> <regular-component>
> <stuff/>
> </regular-component>
>
> <database-selector>
> <jdbc name="foo"/>
> <j2ee name="bar"/>
> <informix name="baz"/>
> </database-selector>
Without a .roles file would we even have declarations that look like this?
Geoff
(thanks for the patient summary and work by the way)
RE: [VOTE] Migrate from the aging ECM
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Berin Loritsch wrote:
>
> <SNIP GOOD EXPLAINS/>
Thanks Berin for the info, so with Fortress we can finally forget
the double lookups when selectors were used.
Carsten
Re: [VOTE] Migrate from the aging ECM
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
>
> I think we should do this switch asap. *If* we can solve the commandmanager
> issue discussed in the other thread, I will make a 2.1.1 release this week.
> Immediately after that work can start on the migration.
>
> Berin, you mention above in 3) that the configuration format changes
> slightly.
> Can you give a short explaination please?
In Cocoon/ECM we have the following constructs:
<regular-component>
<stuff/>
</regular-component>
<database-selector>
<jdbc name="foo"/>
<j2ee name="bar"/>
<informix name="baz"/>
</database-selector>
Notice that the regular component has no name/id, and the database-selector
is a "component" that defines a set of components with a name.
In Fortress, things are simplified a bit--esp. since the only time a Selector
is returned is when you append "Selector" to the role name--you don't need them
at all if you don't want. The above in Fortress would be redone as:
<regular-component id="regular">
<stuff/>
</regular-component>
<jdbc-datasource id="foo"/>
<j2ee-datasource id="bar"/>
<informix-datasource id="baz"/>
(the actual configuration name is set up in the meta data).
In ECM, the only way to get the "regular-component" is to do a direct lookup:
manager.lookup(RegularComponent.ROLE);
and the only way to get the particular database connection you want is to do
a lookup on the selector and then select the correct connection:
ServiceSelector selector =
(ServiceSelector) manager.lookup(DataSourceComponent.ROLE + "Selector");
selector.select("foo");
selector.select("bar");
selector.select("baz");
In Fortress, you can do things the old ECM way, or you can incorporate the ID
to get whichever component you want and bypass the selector completely like
this:
manager.lookup(RegularComponent.ROLE + "/regular");
manager.lookup(DataSourceComponent.ROLE + "/foo");
manager.lookup(DataSourceComponent.ROLE + "/bar");
manager.lookup(DataSourceComponent.ROLE + "/baz");
Lastly, a component that just wants whatever the default implementation for a
component is only has to lookup the component it wants:
manager.lookup(RegularComponent.ROLE);
manager.lookup(DataSourceComponent.ROLE);
The default component is always the first one listed in the configuration file,
unless that behavior is overridden. You can override the behavior by adding a
default="true" attribute to a component. In the above example, the lookup for
a DataSourceComponent.ROLE would return the "foo" variation. If the "bar"
variation was altered like this:
<j2ee-datasource id="bar" default="true"/>
then any call to lookup DataSourceComponent.ROLE would return that variation.
As you can see, we can get away from the whole selector concept and do direct
lookups--but Fortress will still work with the old way of doing things. This
allows you to mix components that expect only one implementation of a component
type with components that require you to select the component.
It would simplify all the database actions, etc. that we have.
The way I propose working around it for the short term--to avoid the
configuration reformatting is to accept the old style configuration (things
with "selector" in the name would be treated as the old style selectors),
and if there is no "name" attribute, the name would match the short config name.
So <regular-component/> would have the id "regular-component".
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
RE: CommandManager again (was RE: [VOTE] Migrate from the aging ECM)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Berin Loritsch wrote:
>
> Carsten Ziegeler wrote:
>
> >
> >>m_threadPool.waitWhenBlocked();
> >>
> >>to
> >>
> >>m_threadPool.discardWhenBlocked();
> >>
> >>functionally, this shouldn't change anything (I think), and it will
> >>avoid the problem in PooledExecutor completely. If you have some time
> >>available to try this out, that would be great.
> >>
> >
> > Yes, I just tried it - and it works. Great!
> >
> > So, how do we proceed? We can distribute our own patched
> version of event
> > or we can ask that this will be changed in excalibur.
>
> You (all cocoon developers) have access to excalibur components. Why not
> go ahead and fix it?
>
Yes, I now this - I just wanted first to hear your opinion on this.
So, I will apply the change asap.
> Just ask for a new release, and all will be happy.
>
Can we have a new release, please? :)
Carsten
Re: CommandManager again (was RE: [VOTE] Migrate from the aging ECM)
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
>
>>m_threadPool.waitWhenBlocked();
>>
>>to
>>
>>m_threadPool.discardWhenBlocked();
>>
>>functionally, this shouldn't change anything (I think), and it will
>>avoid the problem in PooledExecutor completely. If you have some time
>>available to try this out, that would be great.
>>
>
> Yes, I just tried it - and it works. Great!
>
> So, how do we proceed? We can distribute our own patched version of event
> or we can ask that this will be changed in excalibur.
You (all cocoon developers) have access to excalibur components. Why not
go ahead and fix it?
Just ask for a new release, and all will be happy.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
RE: CommandManager again (was RE: [VOTE] Migrate from the aging
ECM)
Posted by Bruno Dumon <br...@outerthought.org>.
On Wed, 2003-09-03 at 11:05, Carsten Ziegeler wrote:
> Bruno Dumon wrote:
> >
> > On Wed, 2003-09-03 at 10:23, Carsten Ziegeler wrote:
> > <snip/>
> > > I think we should do this switch asap. *If* we can solve the
> > commandmanager
> > > issue discussed in the other thread, I will make a 2.1.1
> > release this week.
> >
> > The issue can in fact be fixed immediately by changing the way we use
> > the PooledExecutor class. In the TPCThreadManager class (in
> > excalibur-event), change the line:
> >
> > m_threadPool.waitWhenBlocked();
> >
> > to
> >
> > m_threadPool.discardWhenBlocked();
> >
> > functionally, this shouldn't change anything (I think), and it will
> > avoid the problem in PooledExecutor completely.
Before I forget: another solution is to use a keepalive time of -1:
m_threadPool.setKeepAliveTime(-1);
together with m_threadPool.waitWhenBlocked();
In that case threads will never expire (so the thread pool will have a
fixed size once it reached its maximum) which also avoids the problem.
I think using dicardWhenBlocked() is better though.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
RE: CommandManager again (was RE: [VOTE] Migrate from the aging
ECM)
Posted by Bruno Dumon <br...@outerthought.org>.
On Wed, 2003-09-03 at 11:05, Carsten Ziegeler wrote:
> Bruno Dumon wrote:
> >
> > On Wed, 2003-09-03 at 10:23, Carsten Ziegeler wrote:
> > <snip/>
> > > I think we should do this switch asap. *If* we can solve the
> > commandmanager
> > > issue discussed in the other thread, I will make a 2.1.1
> > release this week.
> >
> > The issue can in fact be fixed immediately by changing the way we use
> > the PooledExecutor class. In the TPCThreadManager class (in
> > excalibur-event), change the line:
> >
> > m_threadPool.waitWhenBlocked();
> >
> > to
> >
> > m_threadPool.discardWhenBlocked();
> >
> > functionally, this shouldn't change anything (I think), and it will
> > avoid the problem in PooledExecutor completely. If you have some time
> > available to try this out, that would be great.
> >
> Yes, I just tried it - and it works. Great!
>
> So, how do we proceed?
I'd wait till tomorrow -- I should have a definitive answer from Doug
Lea by then.
> We can distribute our own patched version of event
> or we can ask that this will be changed in excalibur.
and then it can as well be patched in excalibur itself.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
RE: CommandManager again (was RE: [VOTE] Migrate from the aging
ECM)
Posted by Bruno Dumon <br...@outerthought.org>.
On Wed, 2003-09-03 at 11:05, Carsten Ziegeler wrote:
> Bruno Dumon wrote:
> >
> > On Wed, 2003-09-03 at 10:23, Carsten Ziegeler wrote:
> > <snip/>
> > > I think we should do this switch asap. *If* we can solve the
> > commandmanager
> > > issue discussed in the other thread, I will make a 2.1.1
> > release this week.
> >
> > The issue can in fact be fixed immediately by changing the way we use
> > the PooledExecutor class. In the TPCThreadManager class (in
> > excalibur-event), change the line:
> >
> > m_threadPool.waitWhenBlocked();
> >
> > to
> >
> > m_threadPool.discardWhenBlocked();
> >
> > functionally, this shouldn't change anything (I think), and it will
> > avoid the problem in PooledExecutor completely. If you have some time
> > available to try this out, that would be great.
> >
> Yes, I just tried it - and it works. Great!
After thinking some more about this I fixed it in a different way.
I've already updated the excalibur-event package in our CVS.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
RE: CommandManager again (was RE: [VOTE] Migrate from the aging ECM)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Bruno Dumon wrote:
>
> On Wed, 2003-09-03 at 10:23, Carsten Ziegeler wrote:
> <snip/>
> > I think we should do this switch asap. *If* we can solve the
> commandmanager
> > issue discussed in the other thread, I will make a 2.1.1
> release this week.
>
> The issue can in fact be fixed immediately by changing the way we use
> the PooledExecutor class. In the TPCThreadManager class (in
> excalibur-event), change the line:
>
> m_threadPool.waitWhenBlocked();
>
> to
>
> m_threadPool.discardWhenBlocked();
>
> functionally, this shouldn't change anything (I think), and it will
> avoid the problem in PooledExecutor completely. If you have some time
> available to try this out, that would be great.
>
Yes, I just tried it - and it works. Great!
So, how do we proceed? We can distribute our own patched version of event
or we can ask that this will be changed in excalibur.
Carsten
CommandManager again (was RE: [VOTE] Migrate from the aging ECM)
Posted by Bruno Dumon <br...@outerthought.org>.
On Wed, 2003-09-03 at 10:23, Carsten Ziegeler wrote:
<snip/>
> I think we should do this switch asap. *If* we can solve the commandmanager
> issue discussed in the other thread, I will make a 2.1.1 release this week.
The issue can in fact be fixed immediately by changing the way we use
the PooledExecutor class. In the TPCThreadManager class (in
excalibur-event), change the line:
m_threadPool.waitWhenBlocked();
to
m_threadPool.discardWhenBlocked();
functionally, this shouldn't change anything (I think), and it will
avoid the problem in PooledExecutor completely. If you have some time
available to try this out, that would be great.
Of course, this doesn't fix the original problem we had in
PooledExecutor, but I'm starting to doubt if this can be fixed at all.
Anyhow, I'm communicating with Doug Lea about that.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
RE: [VOTE] Migrate from the aging ECM
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Nicola Ken Barozzi wrote:
>
> Berin Loritsch wrote, On 02/09/2003 19.11:
>
> > Geoff Howard wrote:
> ...
> >> Could someone (Berin?) give an estimate of what the "damage" would be
> >> even if we agree it's a good move?
> >
> >
> > Risk Assessment and Mitigation Strategy:
> >
> > 1) Legacy Components. All legacy components are handled as
> expected with
> > Fortress as long as the components do not expect ECM itself.
> In 99% of
> > the cases this is what happens.
> >
> > 2) LogKitManageable. We can create a Lifecycle extension to
> handle this
> > one,
> > but for future reference, this is best handled via a ServiceManager
> > lookup.
> > Fortress natively uses the LoggerManager, so we get the
> migration from
> > forced LogKit integration for free.
> >
> > 3) Configuration file format is slightly different. We can create an
> > adaptor
> > to handle the transition (extending the DefaultContainer
> from Fortress).
> >
> > 4) Components/special selectors that extend ECM directly.
> There is no real
> > work around for this. Those components have to be altered. To my
> > knowledge,
> > this includes the GeneratorSelector and the SiteMapSelector, and
> > possibly the
> > SiteMap implementation as well as the central Cocoon object. As to
> > third
> > party components, the old ECM libraries would have to be
> included in a
> > compatibility JAR set.
> >
> > There is nothing (too my knowlege) that cannot be worked around to
> > provide a
> > seemless integration. What do you all think?
>
> I think that this will bring Cocoon one step ahead by removing some
> wrong dependencies it has with the implementation (ECM) and changing
> them with new more standard and future-compatible contracts.
>
> The "change" is not insignificant, but the "damage" seems very slight
> for non-core Cocoon developers.
>
> +1 for 2.2 switching to Fortress
>
I think we should do this switch asap. *If* we can solve the commandmanager
issue discussed in the other thread, I will make a 2.1.1 release this week.
Immediately after that work can start on the migration.
Berin, you mention above in 3) that the configuration format changes
slightly.
Can you give a short explaination please?
Thanks
Carsten
Re: [VOTE] Migrate from the aging ECM
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote, On 02/09/2003 19.11:
> Geoff Howard wrote:
...
>> Could someone (Berin?) give an estimate of what the "damage" would be
>> even if we agree it's a good move?
>
>
> Risk Assessment and Mitigation Strategy:
>
> 1) Legacy Components. All legacy components are handled as expected with
> Fortress as long as the components do not expect ECM itself. In 99% of
> the cases this is what happens.
>
> 2) LogKitManageable. We can create a Lifecycle extension to handle this
> one,
> but for future reference, this is best handled via a ServiceManager
> lookup.
> Fortress natively uses the LoggerManager, so we get the migration from
> forced LogKit integration for free.
>
> 3) Configuration file format is slightly different. We can create an
> adaptor
> to handle the transition (extending the DefaultContainer from Fortress).
>
> 4) Components/special selectors that extend ECM directly. There is no real
> work around for this. Those components have to be altered. To my
> knowledge,
> this includes the GeneratorSelector and the SiteMapSelector, and
> possibly the
> SiteMap implementation as well as the central Cocoon object. As to
> third
> party components, the old ECM libraries would have to be included in a
> compatibility JAR set.
>
> There is nothing (too my knowlege) that cannot be worked around to
> provide a
> seemless integration. What do you all think?
I think that this will bring Cocoon one step ahead by removing some
wrong dependencies it has with the implementation (ECM) and changing
them with new more standard and future-compatible contracts.
The "change" is not insignificant, but the "damage" seems very slight
for non-core Cocoon developers.
+1 for 2.2 switching to Fortress
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [VOTE] Migrate from the aging ECM
Posted by Berin Loritsch <bl...@apache.org>.
Geoff Howard wrote:
>
> Ok, then I'll be +1. But this raises a point which is for some reason
> contentious on the list the last few days:
>
> Wouldn't it be better not to do this change on the 2.1.x line? I am
> assuming that this change would break back-compatibility in some points
> at least of custom components, etc. and that should be avoided on a
> released version.
>
> Could someone (Berin?) give an estimate of what the "damage" would be
> even if we agree it's a good move?
Risk Assessment and Mitigation Strategy:
1) Legacy Components. All legacy components are handled as expected with
Fortress as long as the components do not expect ECM itself. In 99% of
the cases this is what happens.
2) LogKitManageable. We can create a Lifecycle extension to handle this one,
but for future reference, this is best handled via a ServiceManager lookup.
Fortress natively uses the LoggerManager, so we get the migration from
forced LogKit integration for free.
3) Configuration file format is slightly different. We can create an adaptor
to handle the transition (extending the DefaultContainer from Fortress).
4) Components/special selectors that extend ECM directly. There is no real
work around for this. Those components have to be altered. To my knowledge,
this includes the GeneratorSelector and the SiteMapSelector, and possibly the
SiteMap implementation as well as the central Cocoon object. As to third
party components, the old ECM libraries would have to be included in a
compatibility JAR set.
There is nothing (too my knowlege) that cannot be worked around to provide a
seemless integration. What do you all think?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: [VOTE] Migrate from the aging ECM
Posted by Geoff Howard <co...@leverageweb.com>.
Berin Loritsch wrote:
> Vadim Gritsenko wrote:
>
>> Berin Loritsch wrote:
>>
>>> The new Cocoon should be able to use the new Fortress container.
>>> This should
>>> have little to no impact on component writers. It boasts faster
>>> startup, and
>>> it provides easier component definition. I will be happy to do the
>>> work.
>>>
>>> +1 from me.
>>
>> +1, but I (still) would like to hear quick comment on Fortress vs
>> Merlin. I heard on avalon-dev that merlin is gonna be that new craze.
>
> Consider Fortress a stepping stone from ECM to Merlin. Once Cocoon has
> done
> all the work to move to Fortress, it becomes trivial to host in Merlin.
> The main things here are:
>
> 1) Merlin does not support ServiceSelector.
> 2) Fortress provides mechanisms to make the ServiceSelector unecessary, but
> seamlessly supports components that still hold on to it.
> 3) Merlin does not support the ThreadSafe, SingleThreaded, Poolable
> interfaces.
> 4) Fortress still supports them for legacy components--but it encourages
> the
> new meta-data enabled way.
>
> These are the key areas where Cocoon *needs* Fortress for the immediate
> shift.
> I would much rather work toward the immediate need, because we can still
> work
> with Cocoon while we are doing the other migrations.
>
> It is important to note that Merlin has a number of features that Fortress
> does not have--but Fortress provides a number of features that ECM doesn't
> have. When Merlin is officially released, it will be 100% Fortress
> compatible.
Ok, then I'll be +1. But this raises a point which is for some reason
contentious on the list the last few days:
Wouldn't it be better not to do this change on the 2.1.x line? I am
assuming that this change would break back-compatibility in some points
at least of custom components, etc. and that should be avoided on a
released version.
Could someone (Berin?) give an estimate of what the "damage" would be
even if we agree it's a good move?
Geoff
Re: [VOTE] Migrate from the aging ECM
Posted by Berin Loritsch <bl...@apache.org>.
Vadim Gritsenko wrote:
> Berin Loritsch wrote:
>
>> The new Cocoon should be able to use the new Fortress container. This
>> should
>> have little to no impact on component writers. It boasts faster
>> startup, and
>> it provides easier component definition. I will be happy to do the work.
>>
>> +1 from me.
>
>
>
> +1, but I (still) would like to hear quick comment on Fortress vs
> Merlin. I heard on avalon-dev that merlin is gonna be that new craze.
Consider Fortress a stepping stone from ECM to Merlin. Once Cocoon has done
all the work to move to Fortress, it becomes trivial to host in Merlin.
The main things here are:
1) Merlin does not support ServiceSelector.
2) Fortress provides mechanisms to make the ServiceSelector unecessary, but
seamlessly supports components that still hold on to it.
3) Merlin does not support the ThreadSafe, SingleThreaded, Poolable interfaces.
4) Fortress still supports them for legacy components--but it encourages the
new meta-data enabled way.
These are the key areas where Cocoon *needs* Fortress for the immediate shift.
I would much rather work toward the immediate need, because we can still work
with Cocoon while we are doing the other migrations.
It is important to note that Merlin has a number of features that Fortress
does not have--but Fortress provides a number of features that ECM doesn't
have. When Merlin is officially released, it will be 100% Fortress compatible.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: [VOTE] Migrate from the aging ECM
Posted by Vadim Gritsenko <va...@verizon.net>.
Berin Loritsch wrote:
> The new Cocoon should be able to use the new Fortress container. This
> should
> have little to no impact on component writers. It boasts faster
> startup, and
> it provides easier component definition. I will be happy to do the work.
>
> +1 from me.
+1, but I (still) would like to hear quick comment on Fortress vs
Merlin. I heard on avalon-dev that merlin is gonna be that new craze.
Vadim
Re: [VOTE] Migrate from the aging ECM
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote, On 29/08/2003 17.25:
> The new Cocoon should be able to use the new Fortress container. This
> should
> have little to no impact on component writers. It boasts faster
> startup, and
> it provides easier component definition. I will be happy to do the work.
+1 :-D
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [VOTE] Migrate from the aging ECM
Posted by Giacomo Pati <gi...@apache.org>.
On Fri, 29 Aug 2003, Berin Loritsch wrote:
> The new Cocoon should be able to use the new Fortress container. This should
> have little to no impact on component writers. It boasts faster startup, and
> it provides easier component definition. I will be happy to do the work.
>
> +1 from me.
+1
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
Re: [VOTE] Migrate from the aging ECM
Posted by Ugo Cei <ug...@apache.org>.
Berin Loritsch wrote:
> The new Cocoon should be able to use the new Fortress container. This
> should
> have little to no impact on component writers. It boasts faster
> startup, and
> it provides easier component definition. I will be happy to do the work.
>
> +1 from me.
>
+1.
Ugo
Re: [VOTE] Migrate from the aging ECM
Posted by Boon Hian Tek <bt...@pdxbtek.dyndns.org>.
Berin Loritsch wrote:
> The new Cocoon should be able to use the new Fortress container. This
> should
> have little to no impact on component writers. It boasts faster
> startup, and
> it provides easier component definition. I will be happy to do the work.
>
> +1 from me.
>
+1 for you.
Re: [VOTE] Migrate from the aging ECM
Posted by Christian Haul <ha...@informatik.tu-darmstadt.de>.
Berin Loritsch wrote:
> The new Cocoon should be able to use the new Fortress container. This
> should
> have little to no impact on component writers. It boasts faster
> startup, and
> it provides easier component definition. I will be happy to do the work.
>
> +1 from me.
+1 for this change in either 2.1.2 (together with change of logging) or
in 2.2
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: [VOTE] Migrate from the aging ECM
Posted by Gianugo Rabellino <gi...@apache.org>.
Berin Loritsch wrote:
> The new Cocoon should be able to use the new Fortress container. This
> should
> have little to no impact on component writers. It boasts faster
> startup, and
> it provides easier component definition. I will be happy to do the work.
>
> +1 from me.
>
I'm scared but I trust you. :-) +1 from me too.
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
RE: [VOTE] Migrate from the aging ECM
Posted by Reinhard Poetz <re...@apache.org>.
From: Carsten Ziegeler
> Giacomo Pati wrote:
> > >
> > > What do you think of the Sept, 15th releasing 2.1.1?
> >
> > Good for me.
> >
> Then someone else than me has to do the release. I can either
> do it this week til friday or then three weeks later when I'm
> back from vacation.
>
> Currently I prefer this week, but if anyone wants to do it on
> the 15th (or any other date), I'm fine as well.
I'm fine with this Friday too if Continuations are invalidated
correctly.
Has somebody had a look at the problems with http proxies?
Cheers,
Reinhard
RE: [VOTE] Migrate from the aging ECM
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Giacomo Pati wrote:
> >
> > What do you think of the Sept, 15th releasing 2.1.1?
>
> Good for me.
>
Then someone else than me has to do the release. I can either
do it this week til friday or then three weeks later when I'm
back from vacation.
Currently I prefer this week, but if anyone wants to do it on
the 15th (or any other date), I'm fine as well.
Carsten
RE: [VOTE] Migrate from the aging ECM
Posted by Giacomo Pati <gi...@apache.org>.
On Tue, 2 Sep 2003, Reinhard Poetz wrote:
>
> From: Reinhard Poetz [mailto:reinhard@apache.org]
>
> >
> > From: Berin Loritsch
> >
> > >
> > > The new Cocoon should be able to use the new Fortress
> > > container. This should have little to no impact on component
> > > writers. It boasts faster startup, and it provides easier
> > > component definition. I will be happy to do the work.
> > >
> > > +1 from me.
> >
> > +1 from me
>
> Please wait until Cocoon 2.1.1 (with working scheduler for continuation
> invalidation) is shipped. I would have a better feeling if we could test
> the new container some time before it is released. Otherwise we would
> have a good reason to delay 2.1.1 for a (too) long time and IMO we
> shouldn't wait to long with a new minor release.
>
> What do you think of the Sept, 15th releasing 2.1.1?
Good for me.
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
RE: [VOTE] Migrate from the aging ECM
Posted by Reinhard Poetz <re...@apache.org>.
From: Reinhard Poetz [mailto:reinhard@apache.org]
>
> From: Berin Loritsch
>
> >
> > The new Cocoon should be able to use the new Fortress
> > container. This should have little to no impact on component
> > writers. It boasts faster startup, and it provides easier
> > component definition. I will be happy to do the work.
> >
> > +1 from me.
>
> +1 from me
Please wait until Cocoon 2.1.1 (with working scheduler for continuation
invalidation) is shipped. I would have a better feeling if we could test
the new container some time before it is released. Otherwise we would
have a good reason to delay 2.1.1 for a (too) long time and IMO we
shouldn't wait to long with a new minor release.
What do you think of the Sept, 15th releasing 2.1.1?
Cheers,
Reinhard
RE: [VOTE] Migrate from the aging ECM
Posted by Reinhard Poetz <re...@apache.org>.
From: Berin Loritsch
>
> The new Cocoon should be able to use the new Fortress
> container. This should have little to no impact on component
> writers. It boasts faster startup, and it provides easier
> component definition. I will be happy to do the work.
>
> +1 from me.
+1 from me
Re: [VOTE] Migrate from the aging ECM
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
> The new Cocoon should be able to use the new Fortress container. This
> should
> have little to no impact on component writers. It boasts faster
> startup, and
> it provides easier component definition.
+1
> I will be happy to do the work.
+1 - great!
-Bertrand
RE: [VOTE] Migrate from the aging ECM
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
+1
Carsten
Berin Loritsch wrote:
>
> The new Cocoon should be able to use the new Fortress container.
> This should
> have little to no impact on component writers. It boasts faster
> startup, and
> it provides easier component definition. I will be happy to do the work.
>
> +1 from me.
>
RE: [VOTE] Migrate from the aging ECM
Posted by John Morrison <jo...@ntlworld.com>.
> From: Berin Loritsch
>
> The new Cocoon should be able to use the new Fortress container.
> This should
> have little to no impact on component writers. It boasts faster
> startup, and
> it provides easier component definition. I will be happy to do the work.
>
> +1 from me.
+1 from me too :)
J.