Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (athena.apache.org: domain of
 thorsten.scherler.ext@juntadeandalucia.es designates 217.12.18.114 as
 permitted sender)
Subject: Re: Logging of AbstractSAXTransformer
From: Thorsten Scherler <thorsten.scherler.ext@juntadeandalucia.es>
To: dev@cocoon.apache.org
In-Reply-To: <4728ADE3.80401@apache.org>
References: <1193744600.6865.34.camel@localhost>
	 <1193761470.6865.70.camel@localhost>  <47276985.1040909@apache.org>
	 <1193771782.32165.16.camel@cartman>  <4727C95E.3080507@apache.org>
	 <1193820047.6865.98.camel@localhost>  <4728ADE3.80401@apache.org>
Content-Type: text/plain
Date: Fri, 02 Nov 2007 08:50:21 +0100
Message-Id: <1193989821.5867.34.camel@localhost>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

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 2.2.0-RC3-SNAPSHOT
> >> 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 internally)
> 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 artifacts.
> 
> 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 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"/>


> 
> 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 classes
> that will not depend on Avalon by any means and deprecate old classes.

+1

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

salu2

> 
-- 
Thorsten Scherler                                 thorsten.at.apache.org
Open Source Java                      consulting, training and solutions