cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: Logging of AbstractSAXTransformer
Date Fri, 02 Nov 2007 07:50:21 GMT
On Wed, 2007-10-31 at 17:31 +0100, Grzegorz Kossakowski wrote:
> Thorsten Scherler pisze:
> >> Just go to the Cocoon's root directory and type:
> >> mvn clean install (or some variant of this command like with -P allblocks, etc)
> >>
> >> This will install all Cocoon's snapshot artifacts made from Cocoon's trunk to
your local Maven
> >> repository. Then, when developing your application you just need to change version
of Cocoon's
> >> dependencies to snapshosts, e.g. dependency on cocoon-core artifact should have
> >> version.
> > 
> > That means (for other newbies) you need to edit your pom.xml and update
> > all dependencies versions. If you have followed the tutorial on
> > generating you own block you will need to change at least three
> > dependencies. 
> Yep, and keep in mind that we increase version numbers of modules after releasing (first
> our modules so in order to keep using trunk you will have to increase this numbers in
your pom file too.
> If you want to make sure that you are really using dependencies built from latest trunk
you would
> follow these steps:
> 1. go to Cocoon's trunk directory and hit this command:
> mvn dependency:purge-local-repository -DresolutionFuzziness=groupId
> (this will remove all Cocoon artifacts from your local repository)
> 2. Then:
> mvn clean install
> (this will install only latest snapshots of Cocoon artifacts to your local repository)
> 3. go to your application directory and type:
> mvn clean install -o
> (build in offline mode)
> If build ends with success it means that you are using latest versions of all Cocoon
> NOTE: You may need to add declaration of depedency plug-in to pom.xml before using it.

Nice. Thanks for this instructions.

> > Well, till now I just found transformers/generators that are extending
> > e.g. AbstractSAXTransformer which is an "old" component using avalon as
> > usual. 
> AbstractSAXTransformer is not a component but just an abstract class assuming its descendants
> 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
> figure out that manager is not used in AbstractSAXTransformer so this class can live
> 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 {

and add to your spring config:
<property name="manager"

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

> This brings us to the point:
> For developing pure Spring beans we need to create new versions of all existing abstract
> that will not depend on Avalon by any means and deprecate old classes.


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

> > Is there a replacement of the AbstractSAXTransformer as avalon-less (al)
> > class? If I write a al-tranformer do I have to implement an interface
> > with my transformer?
> That's the safest method but you may use abstract classes if you are sure what are you
> Another method is to reimplement abstract class in Avalon-free way and contribute it
as a patch to
> us. This may start as soon as we come up with clean rules on how this classes should
look like.

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?

> > 
> > Yeah and maybe some "master" examples such as an
> > al-AbstractSAXTransformer and al-AbstractGenerator.
> Yep.
> >> Since I'm going to have some break from studying at my university in upcoming
days I would do this
> >> work since such document is urgently needed.
> >>
> >> Thorsten, I would be grateful if you could help me with this by reviewing what
I write or even
> >> gathering all e-mails related to this topic from archives. Yes, this would be
very helpful because
> >> it would generate more pressure on me. ;-)
> > 
> > Yeah, will try to give you and the team a helping hand while advancing.
> > We may want to open an issue to gather all links.
> I agree, feel free to create such issue.

will do so.


Thorsten Scherler                       
Open Source Java                      consulting, training and solutions

View raw message