cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <g...@tuffmail.com>
Subject Abstract classes for Spring-based components (was: Logging of AbstractSAXTransformer)
Date Fri, 02 Nov 2007 11:19:05 GMT
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?

>> 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.

>> 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.

> 
> 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?

-- 
Grzegorz Kossakowski

Mime
View raw message