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
