Daniel Fagerstrom wrote: > Carsten have started to convert some of our components (FileGenerator, > DOMParser, SAXParser and EntityManager) from Avalon managed to Spring > managed components. And I'd like to join the work and try to make in the > first step the pipeline layer and maybe some important blocks Spring > managed. Great!
I added wrappers for the "old" excalibur interfaces to be compatible, so for example the excalibur DOMParser implementation uses the pojo DOMParser etc. > > The main reasons for this is that it makes our components reusable and > that it makes it much easier to understand, maintain and develop Cocoon. > > An important question here is if we consider the (Avalon) component > configuration files and the role files as part of our public contract > and if there should be a deprecation cycle for them. > > IMO we shouldn't consider them part of the public contract as: > * the configurations have never been formally specified (e.g. with a > scheme). And we have never said that it is a fixed contract. > * For the vast majority of users the configuration files have been an > unwelcome hurdle to maintain and they have only changed a few properties > and they will prefer to use the property mechanism for this instead of > editing a vast central configuration file. > * It would be much work for us to maintain both Avalon and Spring > configurability for our components. > > Neither the less I think that the issue has to be discussed before we > start to POJOfy and Springify the components. Yes, I was just in the process to write an email with a similar topic as I noted a problem while reading Ralphs last post in the "Re: Configuration handling in 2.2 (properties etc.)" thread. First of all, 2.2 should be as compatible to 2.1.x as possible. I guess we all agree to this. The important question is of course what "as compatible as possible" means :) We should provide the same set of components as 2.1.x registered with the same roles. This will ensure that existing applications should work without any code changes. As you outlined above, I think we should not strive for requiring that even the configuration of these components is the same as in 2.1.x. I see no real sense for this. We broke this contract from one 2.1.x to the next release already. 2.2 has superior configuration mechanisms and features so we should enable them. Now, there is one problem though (and I didn't realize this until I read Ralphs mail :( ): sitemap components. Today, user have sitemaps with component configurations for sitemap components; these should imho work without changes, but this requires that we can't change the sitemap components from avalon to pojos as I already did with the FileGenerator... So, I fear we should have a compatibility set of Avalon components and add additional pojo replacements for them one by one. If we add a pojo alternative we deprecate the avalon component. Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
