cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: Abstract classes for Spring-based components (was: Logging of AbstractSAXTransformer)
Date Mon, 05 Nov 2007 08:06:52 GMT
On Fri, 2007-11-02 at 12:19 +0100, Grzegorz Kossakowski wrote:
> Thorsten Scherler pisze:
> >> AbstractSAXTransformer is not a component but just an abstract class assuming
its descendants will
> >> be Avalon-components. If you are extending such a class you must be careful
because you must check
> >> if your super class can work ok without assumption that Avalon-contracts are
respected as they won't
> >> be if your component is a Spring bean.
> >>
> >> For example, when extending AbstractSAXTransformer you may want to check why
it implements
> >> Serviceable interface. As you can see:
> >>     public void service(ServiceManager aManager) throws ServiceException {
> >>         this.manager = aManager;
> >>     }
> >>
> >> It only stores a manager so you need to check if it is used somewhere. After
bit of research you
> >> figure out that manager is not used in AbstractSAXTransformer so this class
can live without
> >> ServiceManager at all. The same goes for other contracts.
> > 
> > Actually this is a very good example of some short comes in our current
> > wrappers. The serviceable components are not initialized correctly. My
> > custom transformer is using service(...) and had thrown a NPE. After
> > debugging I found out that service(...) never got called. 
> > 
> > The solution is to implement:
> > public void setManager(ServiceManager manager) throws ServiceException {
> >   super.service(manager);
> >   this.manager=manager;
> > }
> > 
> > and add to your spring config:
> > <property name="manager"
> > ref="org.apache.avalon.framework.service.ServiceManager"/>
> Yes, this is a valid solution but the question is: if you develop Spring 
> bean why do you need a service manager at all?

Which is a perfect valid question. Actually I still need Avalon ATM for
a port of the dispatcher.

The dispatcher is till now a forrest plugin, but for my current customer
project I need the plugin as cocoon 2.2 block. 

Till now I just need a proof of concept port without totally dropping
all avalon code. To make it work quickly I am using the service manager
till I find out which replacement classes/methods we can use for e.g.
source resolving etc.

> >> Ok, this is bit tedious and hacky because you really need to examine *all* implementation
details of
> >> *all* super classes. 
> > 
> > I am lucky that I have lots of experience with cocoon < 2.2 so the
> > interfaces and super classes are familiar to me but which strikes me
> > awkward is that they do not work as they did in "before 2.2". 
> Only if you try to use them as super classes for Spring beans. If you 
> try to develop an Avalon component everything will work fine.

Yes if you do 100% old school avalon, not as I did mixing the two
(spring configuration and old avalon code). Anyway I am looking forward
to develop clean avalon less code.

> >> This process started to begin (see org.apache.cocoon.util.AbstractLogEnabled
class for example) but
> >> there is a work left. I would like to hear other's opinion on this.
> >> Are we going to reimplement all of our abstract classes?
> > 
> > IMO we should otherwise avalon will be around forever and personally I
> > do not see the need for 2 different IoC container.
> Yes, I agree. This is a really good task for 2.3 that should appear 
> shortly IMO.

Ah, ok 2.3 is for the complete move. Makes me thing whether 3.0 would
not be the better name (since avalon would not be supported anymore).

> > 
> > Yeah, can do it, but then we need to define IMO as well a new interface
> > for our components. I guess we still do 
> > a) generate SAX
> > b) transform SAX
> > ...
> > 
> > meaning all components (except serializer and readers) are producing SAX
> > events, right?
> I can't follow this. What dod you want to explain here?

I mean 

public interface Generator extends XMLProducer, SitemapModelComponent {

    String ROLE = Generator.class.getName();

     * Generate the XML and stream it into the pipeline
    void generate()
    throws IOException, SAXException, ProcessingException;

Where the void generate() will produce SAX events, right? The interface
we need to change for sure is SitemapModelComponent since it uses

Bottom line for me is that it would be very helpful to see some abstract
classes one can extend for new components that are 100% spring. I agree
that it is easy and I hopefully will find time to submit some examples
in the near future.

Thorsten Scherler                       
Open Source Java                      consulting, training and solutions

View raw message