RE: [VOTE] Migrate from the aging ECM
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
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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
RE: [VOTE] Migrate from the aging ECM
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
CommandManager again (was RE: [VOTE] Migrate from the aging ECM)
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 [EMAIL PROTECTED] [EMAIL PROTECTED]
RE: CommandManager again (was RE: [VOTE] Migrate from the aging ECM)
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
Re: CommandManager again (was RE: [VOTE] Migrate from the aging ECM)
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)
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: [VOTE] Migrate from the aging ECM
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: [VOTE] Migrate from the aging ECM
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
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
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
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
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
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
From: Reinhard Poetz [mailto:[EMAIL PROTECTED] 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
On Tue, 2 Sep 2003, Reinhard Poetz wrote: From: Reinhard Poetz [mailto:[EMAIL PROTECTED] 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
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
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
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
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
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 [EMAIL PROTECTED] fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: [VOTE] Migrate from the aging ECM
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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [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. +1 I will be happy to do the work. +1 - great! -Bertrand
RE: [VOTE] Migrate from the aging ECM
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
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
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
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
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.
Re: [VOTE] Migrate from the aging ECM
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
+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
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
