cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: POI Serialization code committed
Date Fri, 08 Mar 2002 09:24:15 GMT
giacomo wrote:

>As always when Sylvain gets engadged he has very good arguments which
>convinced me to support moving thoes classes out of Cocoon and only
>leave the serializer and Avalon component glue code in Cocoon's CVS.
Thanks, Giacomo. I value your judgment as you are one of the Cocoon 
"wise men".

>We have to see where the other code will best fit into other project (if
>the POI team cannot be convinced to hold it in their CVS).
We should do our best to convince them that XML support in POI is a good 
thing for the project (I've given a lot of reasons for that).

One of their objectives seems to keep the library as small as possible. 
To achieve this, they could package the XML stuff in a separate jar 
(poi-xml.jar) so that people can use only poi.jar if they don't care 
about XML.

>On Thu, 7 Mar 2002, Sylvain Wallez wrote:
>>acoliver wrote:

>>>The package names were cross referenced with the location in the previous
>>>CVS.  The only thing that has changed was the Avalonization of the
>>>serializers which Stefano and others proposed.
>>I checked the Avalonization : one implementation of Component and 4
>>classes using getLogger().
Having thought deeper about the componentization of the serialization 
stuff, I think that it doesn't really need to be a Component : 
HSSFElementProcessorFactory doesn't use any of Avalon lifecycle 
interfaces, and the only class using it is HSSFSerializer, which, as its 
name implies, is obviously tied to this particular implementation of the 
ElementProcessorFactory interface.

As all serializers, HSSFSerializer *is* a component and declared as such 
in the sitemap. But just as we don't have a "FOPProcessor" component 
used solely by the FOPSerializer, we don't need a new component used 
solely by HSSFSerializer.

Not every class needs to be a component, and adding too many entries in 
cocoon.xconf will be confusing for users. So what about the 
"de-Avalonization" of the ElementProcessor (which means remove a useless 
Component implementation and an entry in cocoon.xconf) ? Or did I miss 
something that really requires it to be a component ?

<snip what="long discussion"/>


Sylvain Wallez
  Anyware Technologies                  Apache Cocoon 

To unsubscribe, e-mail:
For additional commands, email:

View raw message