cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: New Components From Avalon Scratchpad
Date Fri, 11 Jan 2002 09:54:59 GMT

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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message