Re: springification of core
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Fagerstrom wrote: Leszek Gawron skrev: Giacomo Pati wrote: Daniel Fagerstrom wrote: Leszek Gawron skrev: ... I don't know if we have discussed any policy for how to Springify the beans, but you will find many examples in the core. What I would propose is that for sitemap components, we keep and depricate the Avalon configurability and life cycle interfaces even if we Springify them. I was a little bit too fast and removed Avalon lifecycle from cocoon template. Should I get it back? I don't know. When I Springified sitemap components I just assumed that it would be a good idea to keep the Avalon configurability so that people doesn't need to change their sitemaps. But I'm not sure that it is worthwhile. Maybe it is better to provide some kind of update guide. I would guess that most 2.1.x users has an enourmous amount of standard configured sitemap components in their main sitemap that is taken from the sample webapp. These configurations could just be removed in 2.2, the configurations included in the blocks will do the job. What is more complicated are the sitemap components where users has customized configurations in sub sitemaps, here we need to provide migration instructions. So the question is: should we keep the configurations basck compatible or should we ask users to update their configurations? WDYT? 1. Vadmin mentioned that if you have a springified component you have to move it to spring context anyway because otherwise it won't work. Is that correct? No idea. I think it worked in Avalon mode when I updated some components, but I haven't checked since then. 2. Do we really need to keep Disposable, REcyclable if they have no equivalent in prototype beans? If we want to keep them working with the Avalon configurations that is necessary as the Avalon configurations doesn't include any information about that they should be prototypes. 3. The only reason to keep LogEnabled is to allow user to set logging category. And because some of the abstract base classes used for many of the sitemap components are based on AbstractLogEnabled. Which AbstractLogEnabled are we talking about? org.apache.cocoon.util.AbstractLogEnabled or org.apache.avalon.framework.logger.AbstractLogEnabled The cocoon one uses CL and is meant as a migration helper avay from Avalon's one. /Daniel - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHDImzLNdJvZjjVZARAia2AJ4pVO4EI/2zxat1BKASzlMZKwTuvwCfTVQO j28H9DoDWmQiIVvrI00wI8A= =rnER -END PGP SIGNATURE-
Re: springification of core
Reinhard Poetz skrev: Daniel Fagerstrom wrote: Leszek Gawron skrev: There is a lot of .xconf files in core. I would like to start converting them into spring beans Great! but question is: do we want that for 2.2? Yes. It is a huge job to convert everything, so the only realistic option is to do it incrementally, a couple of components at the time, when people have time and feel like it. If we try to syncronize it with releases we will never get it done. Right. As long as the shortname doesn't change most users won't be affected. I don't know if we have discussed any policy for how to Springify the beans, but you will find many examples in the core. What I would propose is that for sitemap components, we keep and depricate the Avalon configurability and life cycle interfaces even if we Springify them. You'll find a number of examples on how this can be done in cocoon-pipeline-components. As users probably have tons of sitemap component configurations in their sitemaps, I think it is reasonable to give them some time to change. Can you give a concrete example? E.g. the DirectoryGenerator which has already been springfied only exisits as a Spring bean, at least AFAICS. The DirectoryGenerator is still an Avalon component besides being a Spring bean. Take a look in its super classes and you'll see that it still implements LogEnabled, Recyclable, Poolable, Servicable and Disposable. Then you might take a look at the ResourceReader for an example of handling of a Configurable component. /Daniel
Re: springification of core
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Fagerstrom wrote: Leszek Gawron skrev: There is a lot of .xconf files in core. I would like to start converting them into spring beans Great! but question is: do we want that for 2.2? Yes. It is a huge job to convert everything, so the only realistic option is to do it incrementally, a couple of components at the time, when people have time and feel like it. If we try to syncronize it with releases we will never get it done. My experience with the sprinigication of CForms was straight forward and mostly mechanically as: 1. move and migrate a component config snippet from the xconf file to the spring xml file 2. remove all imports of org.apache.avalon on the class under migration 3. fix the errors caused by 2. 4. migrate the configure method to setters (and adapt the spring xml accordingly) 5. migrate the service method to setters (and adapt the spring xml accordingly) 6. migrate the ServiceManager usage to setters (and adapt the spring xml accordingly) 6a. if 6. is too dynamic to be replaced by setters use BeanFactoryAware interface 7. check if an ev. dispose/init method is still needed 7a. if those are needed use InitializingBean/DisposableBean (only singletons can be disposed) 8. restart at 2.for ev. base/abstract classes it extends HTH I don't know if we have discussed any policy for how to Springify the beans, but you will find many examples in the core. What I would propose is that for sitemap components, we keep and depricate the Avalon configurability and life cycle interfaces even if we Springify them. You'll find a number of examples on how this can be done in cocoon-pipeline-components. As users probably have tons of sitemap component configurations in their sitemaps, I think it is reasonable to give them some time to change. For non-sitemap components we have just removed the Avalon stuff. /Daniel - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHCympLNdJvZjjVZARAlJzAKDw5gIv1V7YWMhz2MKZmgyZvWnkRwCghIXo 28asL2r1zx1G546+sCNnX4U= =2u3f -END PGP SIGNATURE-
Re: springification of core
Daniel Fagerstrom wrote:
Reinhard Poetz skrev:
Can you give a concrete example? E.g. the DirectoryGenerator which has
already been springfied only exisits as a Spring bean, at least AFAICS.
The DirectoryGenerator is still an Avalon component besides being a
Spring bean. Take a look in its super classes and you'll see that it
still implements LogEnabled, Recyclable, Poolable, Servicable and
Disposable.
I see. Thanks.
Then you might take a look at the ResourceReader for an example of
handling of a Configurable component.
ok. Wouldn't it be a good idea to set dependencies this way too because in the
FileGenerator I found following code:
try {
// Lookup parser in Avalon contexts
if (null == this.parser)
this.parser = (SAXParser) this.manager.lookup(SAXParser.class.getName());
} catch (ServiceException e) {
throw new ProcessingException(Exception when getting parser., e);
}
Instead of this we could set the parser in the service() method, right?
- o -
This also makes me think if we shouldn't do the Springification in a different
way:
1. create an Avalon free POJO that works using Spring and put it into a
namespace that will also work for OSGi
2. make the old component extending the new POJO and deprecate it
3. implement all the necessary interfaces (LogEnabled, Configureable, etc.)
4. move all the Daisy documentation which is part of the Javadocs into
the new component
Would this work?
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: springification of core
Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Fagerstrom wrote: Leszek Gawron skrev: There is a lot of .xconf files in core. I would like to start converting them into spring beans Great! but question is: do we want that for 2.2? Yes. It is a huge job to convert everything, so the only realistic option is to do it incrementally, a couple of components at the time, when people have time and feel like it. If we try to syncronize it with releases we will never get it done. My experience with the sprinigication of CForms was straight forward and mostly mechanically as: Grzegorz, here's the guide you requested :) : 1. move and migrate a component config snippet from the xconf file to the spring xml file 2. remove all imports of org.apache.avalon on the class under migration 3. fix the errors caused by 2. 4. migrate the configure method to setters (and adapt the spring xml accordingly) 5. migrate the service method to setters (and adapt the spring xml accordingly) 6. migrate the ServiceManager usage to setters (and adapt the spring xml accordingly) 6a. if 6. is too dynamic to be replaced by setters use BeanFactoryAware interface or use configurator:bean-map 7. check if an ev. dispose/init method is still needed 7a. if those are needed use InitializingBean/DisposableBean (only singletons can be disposed) or use @init-method=initialize and @destroy-method=destroy, which approach do we prefer? I tend to use the attribute approach - one less dependency on component framework. 8. restart at 2.for ev. base/abstract classes it extends You're right: springifying components is in most cases dead easy. I see some problems in other area: springifying test cases for those components. We need a fresh new SitemapTestCase for that. I don't know if we have discussed any policy for how to Springify the beans, but you will find many examples in the core. What I would propose is that for sitemap components, we keep and depricate the Avalon configurability and life cycle interfaces even if we Springify them. I was a little bit too fast and removed Avalon lifecycle from cocoon template. Should I get it back? 1. Vadmin mentioned that if you have a springified component you have to move it to spring context anyway because otherwise it won't work. Is that correct? 2. Do we really need to keep Disposable, REcyclable if they have no equivalent in prototype beans? 3. The only reason to keep LogEnabled is to allow user to set logging category. 4. The only interface that brings actual functionality is Configurable. We should keep that as long as 1) works. You'll find a number of examples on how this can be done in cocoon-pipeline-components. As users probably have tons of sitemap component configurations in their sitemaps, I think it is reasonable to give them some time to change. For non-sitemap components we have just removed the Avalon stuff. I'm starting with my favourite: continuations manager -- Leszek Gawron http://www.mobilebox.pl/krs.html CTO at MobileBox Ltd.
Re: springification of core
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Leszek Gawron wrote: Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Fagerstrom wrote: Leszek Gawron skrev: There is a lot of .xconf files in core. I would like to start converting them into spring beans Great! but question is: do we want that for 2.2? Yes. It is a huge job to convert everything, so the only realistic option is to do it incrementally, a couple of components at the time, when people have time and feel like it. If we try to syncronize it with releases we will never get it done. My experience with the sprinigication of CForms was straight forward and mostly mechanically as: Grzegorz, here's the guide you requested :) : 1. move and migrate a component config snippet from the xconf file to the spring xml file 2. remove all imports of org.apache.avalon on the class under migration 3. fix the errors caused by 2. 4. migrate the configure method to setters (and adapt the spring xml accordingly) 5. migrate the service method to setters (and adapt the spring xml accordingly) 6. migrate the ServiceManager usage to setters (and adapt the spring xml accordingly) 6a. if 6. is too dynamic to be replaced by setters use BeanFactoryAware interface or use configurator:bean-map This only works as a ServiceSelectors replacements not for regular beans 7. check if an ev. dispose/init method is still needed 7a. if those are needed use InitializingBean/DisposableBean (only singletons can be disposed) or use @init-method=initialize and @destroy-method=destroy, which approach do we prefer? I tend to use the attribute approach - one less dependency on component framework. Ok 8. restart at 2.for ev. base/abstract classes it extends You're right: springifying components is in most cases dead easy. I see some problems in other area: springifying test cases for those components. We need a fresh new SitemapTestCase for that. What is that SitemapTestCase good for? I don't know if we have discussed any policy for how to Springify the beans, but you will find many examples in the core. What I would propose is that for sitemap components, we keep and depricate the Avalon configurability and life cycle interfaces even if we Springify them. I was a little bit too fast and removed Avalon lifecycle from cocoon template. Should I get it back? What you mean by removed Avalon lifecycle? 1. Vadmin mentioned that if you have a springified component you have to move it to spring context anyway because otherwise it won't work. Is that correct? 2. Do we really need to keep Disposable, REcyclable if they have no equivalent in prototype beans? They are Avalon interfaces so removing it would be the way to go. 3. The only reason to keep LogEnabled is to allow user to set logging category. I don't care about setting category. We once decided to move to Commons Logging, that should be enough. 4. The only interface that brings actual functionality is Configurable. We should keep that as long as 1) works. I've replaced that with setter in the CForm springification. Works fine (or did I missunderstud?). You'll find a number of examples on how this can be done in cocoon-pipeline-components. As users probably have tons of sitemap component configurations in their sitemaps, I think it is reasonable to give them some time to change. For non-sitemap components we have just removed the Avalon stuff. I'm starting with my favourite: continuations manager - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHC0/HLNdJvZjjVZARAiywAJwI6FeLXDsdq86cMNjmzbwLM0/MLwCgxpic gdFAQ5xks/mXpx7dThY4NNE= =MpEk -END PGP SIGNATURE-
Re: springification of core
Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Leszek Gawron wrote: Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Fagerstrom wrote: Leszek Gawron skrev: There is a lot of .xconf files in core. I would like to start converting them into spring beans Great! but question is: do we want that for 2.2? Yes. It is a huge job to convert everything, so the only realistic option is to do it incrementally, a couple of components at the time, when people have time and feel like it. If we try to syncronize it with releases we will never get it done. My experience with the sprinigication of CForms was straight forward and mostly mechanically as: Grzegorz, here's the guide you requested :) : 1. move and migrate a component config snippet from the xconf file to the spring xml file 2. remove all imports of org.apache.avalon on the class under migration 3. fix the errors caused by 2. 4. migrate the configure method to setters (and adapt the spring xml accordingly) 5. migrate the service method to setters (and adapt the spring xml accordingly) 6. migrate the ServiceManager usage to setters (and adapt the spring xml accordingly) 6a. if 6. is too dynamic to be replaced by setters use BeanFactoryAware interface or use configurator:bean-map This only works as a ServiceSelectors replacements not for regular beans 7. check if an ev. dispose/init method is still needed 7a. if those are needed use InitializingBean/DisposableBean (only singletons can be disposed) or use @init-method=initialize and @destroy-method=destroy, which approach do we prefer? I tend to use the attribute approach - one less dependency on component framework. Ok 8. restart at 2.for ev. base/abstract classes it extends You're right: springifying components is in most cases dead easy. I see some problems in other area: springifying test cases for those components. We need a fresh new SitemapTestCase for that. What is that SitemapTestCase good for? Creating and testing cocoon components without instantiating Avalon (so no need for .xtest files). We could probably use standard cocoon applicationContext.xml: beans xmlns=http://www.springframework.org/schema/beans; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:util=http://www.springframework.org/schema/util; xmlns:configurator=http://cocoon.apache.org/schema/configurator; xmlns:avalon=http://cocoon.apache.org/schema/avalon; xsi:schemaLocation=http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.0.xsd http://cocoon.apache.org/schema/configurator http://cocoon.apache.org/schema/configurator/cocoon-configurator-1.0.1.xsd http://cocoon.apache.org/schema/avalon http://cocoon.apache.org/schema/avalon/cocoon-avalon-1.0.xsd; !-- Activate Cocoon Spring Configurator -- configurator:settings/ !-- Activate Avalon Bridge -- avalon:bridge/ /beans It should instantiate only the block components and the components it depends on. After some work there should be no need to use avalon:bridge/ either. I don't know if we have discussed any policy for how to Springify the beans, but you will find many examples in the core. What I would propose is that for sitemap components, we keep and depricate the Avalon configurability and life cycle interfaces even if we Springify them. I was a little bit too fast and removed Avalon lifecycle from cocoon template. Should I get it back? What you mean by removed Avalon lifecycle? I removed Avalon interfaces. 1. Vadmin mentioned that if you have a springified component you have to move it to spring context anyway because otherwise it won't work. Is that correct? 2. Do we really need to keep Disposable, REcyclable if they have no equivalent in prototype beans? They are Avalon interfaces so removing it would be the way to go. 3. The only reason to keep LogEnabled is to allow user to set logging category. I don't care about setting category. We once decided to move to Commons Logging, that should be enough. same for me here. 4. The only interface that brings actual functionality is Configurable. We should keep that as long as 1) works. I've replaced that with setter in the CForm springification. Works fine (or did I missunderstud?). Daniel indicated Configurable should be left untouched so people can configure the component from sitemap. I think it simply won't work as the springified components needs dependencies injected - it won't get those at the sitemap level. -- Leszek Gawron http://www.mobilebox.pl/krs.html CTO at MobileBox Ltd.
Re: springification of core
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Reinhard Poetz skrev:
Can you give a concrete example? E.g. the DirectoryGenerator which
has already been springfied only exisits as a Spring bean, at least
AFAICS.
The DirectoryGenerator is still an Avalon component besides being a
Spring bean. Take a look in its super classes and you'll see that it
still implements LogEnabled, Recyclable, Poolable, Servicable and
Disposable.
I see. Thanks.
Then you might take a look at the ResourceReader for an example of
handling of a Configurable component.
ok. Wouldn't it be a good idea to set dependencies this way too because
in the FileGenerator I found following code:
try {
// Lookup parser in Avalon contexts
if (null == this.parser)
this.parser = (SAXParser)
this.manager.lookup(SAXParser.class.getName());
} catch (ServiceException e) {
throw new ProcessingException(Exception when getting parser., e);
}
Instead of this we could set the parser in the service() method, right?
- o -
This also makes me think if we shouldn't do the Springification in a
different way:
1. create an Avalon free POJO that works using Spring and put it into a
namespace that will also work for OSGi
2. make the old component extending the new POJO and deprecate it
3. implement all the necessary interfaces (LogEnabled, Configureable,
etc.)
4. move all the Daisy documentation which is part of the Javadocs into
the new component
Would this work?
You would like the old component look up the dependencies for POJO, so
the old component can be used directly from sitemap right?
Apart from being tedious to implement it will work. What about the names
though? If we leave the old component named JXTemplateGenerator how do
we name the POJO one?
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.
Re: springification of core
Leszek Gawron wrote:
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Reinhard Poetz skrev:
Can you give a concrete example? E.g. the DirectoryGenerator which
has already been springfied only exisits as a Spring bean, at least
AFAICS.
The DirectoryGenerator is still an Avalon component besides being a
Spring bean. Take a look in its super classes and you'll see that it
still implements LogEnabled, Recyclable, Poolable, Servicable and
Disposable.
I see. Thanks.
Then you might take a look at the ResourceReader for an example of
handling of a Configurable component.
ok. Wouldn't it be a good idea to set dependencies this way too
because in the FileGenerator I found following code:
try {
// Lookup parser in Avalon contexts
if (null == this.parser)
this.parser = (SAXParser)
this.manager.lookup(SAXParser.class.getName());
} catch (ServiceException e) {
throw new ProcessingException(Exception when getting parser., e);
}
Instead of this we could set the parser in the service() method, right?
- o -
This also makes me think if we shouldn't do the Springification in a
different way:
1. create an Avalon free POJO that works using Spring and put it into a
namespace that will also work for OSGi
2. make the old component extending the new POJO and deprecate it
3. implement all the necessary interfaces (LogEnabled, Configureable,
etc.)
4. move all the Daisy documentation which is part of the Javadocs into
the new component
Would this work?
You would like the old component look up the dependencies for POJO, so
the old component can be used directly from sitemap right?
yes
Apart from being tedious to implement it will work. What about the names
though? If we leave the old component named JXTemplateGenerator how do
we name the POJO one?
Sitemap components that are currently in our core are e.g. in o.a.c.generation
which isn't the best package name anyway when they should become useable with
OSGi. For them it shouldn't be too hard to find a better package where they fit
into.
But you're right, it's more difficult with components which are already at the
right place. For the template block and the forms block we solved this by
branching: 1.0 = Avalon - 1.1 Spring
I think that other blocks should follow this example.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: springification of core
Reinhard Poetz wrote:
Leszek Gawron wrote:
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Reinhard Poetz skrev:
Can you give a concrete example? E.g. the DirectoryGenerator which
has already been springfied only exisits as a Spring bean, at least
AFAICS.
The DirectoryGenerator is still an Avalon component besides being a
Spring bean. Take a look in its super classes and you'll see that it
still implements LogEnabled, Recyclable, Poolable, Servicable and
Disposable.
I see. Thanks.
Then you might take a look at the ResourceReader for an example of
handling of a Configurable component.
ok. Wouldn't it be a good idea to set dependencies this way too
because in the FileGenerator I found following code:
try {
// Lookup parser in Avalon contexts
if (null == this.parser)
this.parser = (SAXParser)
this.manager.lookup(SAXParser.class.getName());
} catch (ServiceException e) {
throw new ProcessingException(Exception when getting parser., e);
}
Instead of this we could set the parser in the service() method, right?
- o -
This also makes me think if we shouldn't do the Springification in a
different way:
1. create an Avalon free POJO that works using Spring and put it into a
namespace that will also work for OSGi
2. make the old component extending the new POJO and deprecate it
3. implement all the necessary interfaces (LogEnabled,
Configureable, etc.)
4. move all the Daisy documentation which is part of the Javadocs into
the new component
Would this work?
You would like the old component look up the dependencies for POJO, so
the old component can be used directly from sitemap right?
yes
Apart from being tedious to implement it will work. What about the
names though? If we leave the old component named JXTemplateGenerator
how do we name the POJO one?
Sitemap components that are currently in our core are e.g. in
o.a.c.generation which isn't the best package name anyway when they
should become useable with OSGi. For them it shouldn't be too hard to
find a better package where they fit into.
But you're right, it's more difficult with components which are already
at the right place. For the template block and the forms block we solved
this by branching: 1.0 = Avalon - 1.1 Spring
I think that other blocks should follow this example.
You're right but from what I understand both CForms and CTemplate cannot
be currently used from sitemap level (surely CTemplate because I broke
it myself:) )
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.
Re: springification of core
Reinhard Poetz skrev:
Daniel Fagerstrom wrote:
Reinhard Poetz skrev:
Can you give a concrete example? E.g. the DirectoryGenerator which
has already been springfied only exisits as a Spring bean, at least
AFAICS.
The DirectoryGenerator is still an Avalon component besides being a
Spring bean. Take a look in its super classes and you'll see that it
still implements LogEnabled, Recyclable, Poolable, Servicable and
Disposable.
I see. Thanks.
Then you might take a look at the ResourceReader for an example of
handling of a Configurable component.
ok. Wouldn't it be a good idea to set dependencies this way too because
in the FileGenerator I found following code:
try {
// Lookup parser in Avalon contexts
if (null == this.parser)
this.parser = (SAXParser)
this.manager.lookup(SAXParser.class.getName());
} catch (ServiceException e) {
throw new ProcessingException(Exception when getting parser., e);
}
Instead of this we could set the parser in the service() method, right?
That seem like a better solution, no idea of why I wrote the above code ;)
- o -
This also makes me think if we shouldn't do the Springification in a
different way:
1. create an Avalon free POJO that works using Spring and put it into a
namespace that will also work for OSGi
2. make the old component extending the new POJO and deprecate it
3. implement all the necessary interfaces (LogEnabled, Configureable,
etc.)
4. move all the Daisy documentation which is part of the Javadocs into
the new component
Would this work?
I think it will work. But if we start to create new components and
deprecates the current I would like to go further:
* get rid of SitemapModelComponent - we could inject everything if we
implement the sitemap scope.
* get rid of or simplify XMLProducer and XMLConsumer following some of
the ideas in Carsten's whiteboard experiment:
http://svn.apache.org/repos/asf/cocoon/whiteboard/processor/
But that require some design discussions. I would leave that until after
the release.
/Daniel
Re: springification of core
Leszek Gawron skrev: Giacomo Pati wrote: Daniel Fagerstrom wrote: Leszek Gawron skrev: ... I don't know if we have discussed any policy for how to Springify the beans, but you will find many examples in the core. What I would propose is that for sitemap components, we keep and depricate the Avalon configurability and life cycle interfaces even if we Springify them. I was a little bit too fast and removed Avalon lifecycle from cocoon template. Should I get it back? I don't know. When I Springified sitemap components I just assumed that it would be a good idea to keep the Avalon configurability so that people doesn't need to change their sitemaps. But I'm not sure that it is worthwhile. Maybe it is better to provide some kind of update guide. I would guess that most 2.1.x users has an enourmous amount of standard configured sitemap components in their main sitemap that is taken from the sample webapp. These configurations could just be removed in 2.2, the configurations included in the blocks will do the job. What is more complicated are the sitemap components where users has customized configurations in sub sitemaps, here we need to provide migration instructions. So the question is: should we keep the configurations basck compatible or should we ask users to update their configurations? WDYT? 1. Vadmin mentioned that if you have a springified component you have to move it to spring context anyway because otherwise it won't work. Is that correct? No idea. I think it worked in Avalon mode when I updated some components, but I haven't checked since then. 2. Do we really need to keep Disposable, REcyclable if they have no equivalent in prototype beans? If we want to keep them working with the Avalon configurations that is necessary as the Avalon configurations doesn't include any information about that they should be prototypes. 3. The only reason to keep LogEnabled is to allow user to set logging category. And because some of the abstract base classes used for many of the sitemap components are based on AbstractLogEnabled. /Daniel
springification of core
There is a lot of .xconf files in core. I would like to start converting them into spring beans but question is: do we want that for 2.2? -- Leszek Gawron http://www.mobilebox.pl/krs.html CTO at MobileBox Ltd.
Re: springification of core
Leszek Gawron skrev: There is a lot of .xconf files in core. I would like to start converting them into spring beans Great! but question is: do we want that for 2.2? Yes. It is a huge job to convert everything, so the only realistic option is to do it incrementally, a couple of components at the time, when people have time and feel like it. If we try to syncronize it with releases we will never get it done. I don't know if we have discussed any policy for how to Springify the beans, but you will find many examples in the core. What I would propose is that for sitemap components, we keep and depricate the Avalon configurability and life cycle interfaces even if we Springify them. You'll find a number of examples on how this can be done in cocoon-pipeline-components. As users probably have tons of sitemap component configurations in their sitemaps, I think it is reasonable to give them some time to change. For non-sitemap components we have just removed the Avalon stuff. /Daniel
Re: springification of core
Daniel Fagerstrom pisze: Leszek Gawron skrev: There is a lot of .xconf files in core. I would like to start converting them into spring beans Great! Count me in for applause! BTW, Leszek I asked you to write a little guide for people willing to convert their own components from Avalon to Spring. Are you working on it? I'm asking because I think it's crucial to provide such document and if you are not going to write it I will try to find some spare time and do it myself. but question is: do we want that for 2.2? Yes. It is a huge job to convert everything, so the only realistic option is to do it incrementally, a couple of components at the time, when people have time and feel like it. If we try to syncronize it with releases we will never get it done. I have mixed feeling about this a little bit especially in this concrete moment. I really believe we are just about releasing final of 2.2. I'm not sure if it's realistic to assume that such major change as conversion from Avalon to Spring will not break anything. I don't know if we have discussed any policy for how to Springify the beans, but you will find many examples in the core. What I would propose is that for sitemap components, we keep and depricate the Avalon configurability and life cycle interfaces even if we Springify them. You'll find a number of examples on how this can be done in cocoon-pipeline-components. As users probably have tons of sitemap component configurations in their sitemaps, I think it is reasonable to give them some time to change. Yep. For non-sitemap components we have just removed the Avalon stuff. I don't parse this sentence. Does it describe what we have _already_ done or what we should aim for? -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: springification of core
Grzegorz Kossakowski skrev: Daniel Fagerstrom pisze: Leszek Gawron skrev: ... but question is: do we want that for 2.2? Yes. It is a huge job to convert everything, so the only realistic option is to do it incrementally, a couple of components at the time, when people have time and feel like it. If we try to syncronize it with releases we will never get it done. I have mixed feeling about this a little bit especially in this concrete moment. I really believe we are just about releasing final of 2.2. I'm not sure if it's realistic to assume that such major change as conversion from Avalon to Spring will not break anything. For most components I don't think it is a major change to convert them to Spring. There are some cases, e.g. Springifying the tree processor ;) that are more complicated. But I would assume that Leszek or anyone else working on Springifying Cocoon would discuss on the list if they are uncertain. ... For non-sitemap components we have just removed the Avalon stuff. I don't parse this sentence. Does it describe what we have _already_ done or what we should aim for? Both. /Daniel
Re: springification of core
Daniel Fagerstrom wrote:
Leszek Gawron skrev:
There is a lot of .xconf files in core. I would like to start
converting them into spring beans
Great!
but question is: do we want that for 2.2?
Yes.
It is a huge job to convert everything, so the only realistic option is
to do it incrementally, a couple of components at the time, when people
have time and feel like it. If we try to syncronize it with releases we
will never get it done.
Right. As long as the shortname doesn't change most users won't be affected.
I don't know if we have discussed any policy for how to Springify the
beans, but you will find many examples in the core. What I would propose
is that for sitemap components, we keep and depricate the Avalon
configurability and life cycle interfaces even if we Springify them.
You'll find a number of examples on how this can be done in
cocoon-pipeline-components. As users probably have tons of sitemap
component configurations in their sitemaps, I think it is reasonable to
give them some time to change.
Can you give a concrete example? E.g. the DirectoryGenerator which has already
been springfied only exisits as a Spring bean, at least AFAICS.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
