Gianugo Rabellino wrote: > > Carsten Ziegeler wrote: > > > as you all know, some time ago we decided to move some of the general > > components to Avalon Excalibur. > > The first components now finished (hopefully) in avalon are the parser > > abstraction and a new source handling. > > > > The question is now, how to reintegrate these new components? > > The interface have - of course - changed. First, there are new package > > names and second some methods were changed, added etc. > > > Are the changes backward compatible or will they break existing code > (apart from readjusting imports)? Can you summarize them here so that > everyone of us might check its code and see if and how it works? >
The changes do not break any code. That's the good news! Now on to the bad one: Cocoon has parser abstraction which works very well for us. The new parser abstraction from Avalon is even better (as it is theoretically possible to make the parser thread safe), but with the disadvantage of having a different interface. So the only compatible solution here, is to have both roles (the cocoon parser and the avalon parser) at the same time. All "old" components looking up the cocoon parser still work. All new code should not look up the cocoon parser, but the new avalon parser, so we have to change some code - but again in a compatible way as we only change implementation but no interfaces. But this all ends up in having two parser roles in the cocoon.xconf which can (and in some environments must) be configured. So one solution is to say: a) If the user has a special environment and has components using the "old" parser role, he has to configure both roles or b) We change the "old" parser role so that this parser itself uses the new parser. So only one role, the new avalon parser, has to be configured. But all components using the old parser role will decrease in performance. > > The first step would always be the same: > > > Declaring a new role "xml-parser" which is implemented by the avalon > > version and change every use in cocoon from "parser" to "xml-parser". > > > > and then: > > a) Leaving the "parser" role as it is for compatibility and > deprecating it. > > > b) Changing the implementation for parser, so that it actually uses the > > "xml-parser". This would result in the same interface but of > course in > > the lookup of two components if a parser is required. > > > The advantage of b) is, that each component using the old "parser" role > > automatically gets the new "xml-parser" (wrapped by the old one). > > > This might work only if the API didn't change (I undersand this might be > the case for the parser stuff, but what about the others?), otherwise > the result might be even worse. I'd go for a) (+1) but I would try to > change at least the core classes so that they use the new Avalon > implementation. > Yes, all classes should be changed and as stated above: this doesn't break compatibility. Well, at least, as long as we only speak about the parser. The situation is much worse with the new source abstraction developed in avalon. But I think this can be introduced as well without breaking anything! I will have a look at that next week. Carsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
