You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2007/10/30 18:27:33 UTC
Logging of AbstractSAXTransformer
Thorsten Scherler wrote:
> On Tue, 2007-10-30 at 12:43 +0100, Thorsten Scherler wrote:
>> Hi all,
>>
>> I am trying to get started with cocoon 2.2 development and need to write
>> my own custom transformer.
>>
>> Since I will start from scratch I directly want to start using Spring
>> instead of Avalon.
>>
>> Is there a documentation and/or an example for components that are based
>> directly on spring instead of avalon that I can use to get familiar?
>>
>
> I found
> http://www.mail-archive.com/users@cocoon.apache.org/msg39766.html
>
> So I defined my transformer in the spring context.
> <bean id="dispatcher"
> name="org.apache.cocoon.transformation.Transformer/dispatcher"
> class="org.apache.forrest.dispatcher.transformation.DispatcherTransformer"/>
>
> which is a simple test transformer:
>
> package org.apache.forrest.dispatcher.transformation;
>
> import org.apache.cocoon.transformation.AbstractSAXTransformer;
> import org.xml.sax.SAXException;
>
> public class DispatcherTransformer extends AbstractSAXTransformer {
> private StringBuffer xmlBuffer;
> /**
> * Receive notification of the beginning of a document.
> */
> public void startDocument() throws SAXException {
> xmlBuffer = new StringBuffer();
> xmlBuffer.append("<?xml version='1.0' encoding='UTF-8'?>\r\n");
> xmlBuffer.append("<test/>");
> }
>
> public void endDocument() throws SAXException{
> super.contentHandler.characters(xmlBuffer.toString().toCharArray(), 0,
> xmlBuffer.length());
> }
>
> }
>
> After "mvn install" I run "mvn jetty:run" and receive an exception in
> the AbstractSAXTransformer:
> Caused by: java.lang.NullPointerException
> at
> org.apache.cocoon.transformation.AbstractSAXTransformer.setup(AbstractSAXTransformer.java:274)
> at
> org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:354)
>
> When I debug in Eclipse I can see the following cause:
> LINE:274 = if (getLogger().isDebugEnabled()) {
>
> where getLogger() returns when inspecting:
> "Method "getLogger" with signature "()Lorg/apache/commons/logging/Log;"
> is not applicable on this object"
>
> I reckon I need to configure the logging differently but sadly there
> seems to very little documentation yet (or at least I could not find it
> yet).
>
> Any idea what I am doing wrong?
The problem is that the AbstractSAXTransformer still uses Logkit logging and if
it is initialized by Spring, the logger isn't set.
Fhis has been fixed in trunk by Vadim recently and will be part of the next release.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: Abstract classes for Spring-based components
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Thorsten Scherler pisze:
> Which is a perfect valid question. Actually I still need Avalon ATM for
> a port of the dispatcher.
> http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.internal.dispatcher/
I see. So the general should be that if you develop Spring-based component and need a ServiceManager
you should obtain it by using DI as for any other component. That's important note that should be
included in a page describing how to develop Spring-based components.
> 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.
I see. It's perfectly valid approach.
>> 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).
I would see 2.3 as release introducing all Avalon-free abstract classes for components and
deprecating Avalon-based ones. Then in 3.0 we could remove them from the core as well as move
support for Avalon to separate module or even drop completely.
> 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
> org.apache.avalon.framework.parameters.Parameters.
Ah, yes. Nevertheless, it's not a problem to replace Paramters by something else, this class is
quite straightforward.
> 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.
Great, thanks for discussing these things!
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: Abstract classes for Spring-based components (was: Logging of
AbstractSAXTransformer)
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
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.
http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.internal.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
org.apache.avalon.framework.parameters.Parameters.
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.
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Abstract classes for Spring-based components (was: Logging of AbstractSAXTransformer)
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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
Re: Logging of AbstractSAXTransformer
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
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
Re: Logging of AbstractSAXTransformer
Posted by Grzegorz Kossakowski <gk...@apache.org>.
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.
> 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.
Ok, this is bit tedious and hacky because you really need to examine *all* implementation details of
*all* super classes. 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.
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?
> 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 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.
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: Logging of AbstractSAXTransformer
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Wed, 2007-10-31 at 01:16 +0100, Grzegorz Kossakowski wrote:
> Thorsten Scherler pisze:
> > On Tue, 2007-10-30 at 18:27 +0100, Reinhard Poetz wrote:
> >> Thorsten Scherler wrote:
> > ...
> >> The problem is that the AbstractSAXTransformer still uses Logkit logging and if
> >> it is initialized by Spring, the logger isn't set.
> >>
> >> Fhis has been fixed in trunk by Vadim recently and will be part of the next release.
> >
> > I must admit that maven and me are not the best mates, but I am using
> > latest trunk and still have this problem.
>
> Don't worry, after some practising you should get enough expertise in use of Maven to work
> effectively with Cocoon's trunk.
>
jeje, yeah, I hope so. ;)
> > I reckon it is a maven issue with artifacts et al. but how can I do aka
> > ant a "ant clean build" from my current trunk and maven is actually
> > using the trunk?
>
> 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.
You can find the new version in reviewing the different components.
e.g. ./core/cocoon-servlet-service/cocoon-servlet-service-components/pom.xml will tell you
...
<version>1.0.0-RC2-SNAPSHOT</version>
So you need to change the tutorial pom to:
<dependency>
<groupId>org.apache.cocoon</groupId>
<artifactId>cocoon-servlet-service-components</artifactId>
<version>1.0.0-RC2-SNAPSHOT</version>
</dependency>
You need to repeat this steps for all dependencies.
A small pipe to fasten the task:
find . -name $ARTIFACTId|awk '{print "cat "$1"/pom.xml|grep version"}'|
sh
Where you need to replace the $ARTIFACTId with the name (e.g.
cocoon-servlet-service-components).
Then do
mvn clean install jetty:run
and cross your fingers.
>
> > Further I am really missing some documentation about components using
> > the new spring stuff only. I mean I know how to write avalon components
> > from 2.1 but since I am trying to jump on the 2.2 train I want to
> > develop avalon less components (I reckon that is the reason to use 2.2
> > after all). I will try to add some as soon I get my custom transformer
> > running.
>
> Because of latest Vadim's effort you don't need to do that much. Just write spring bean, put
> configuration in src/main/resources/META-INF/cocoon/spring directory and it should work as long as
> you are using Cocoon's trunk that includes all recent fixes.
>
> If you want to examine existing Cocoon's components based on Spring just search for configuration
> files in src/main/resources/META-INF/cocoon/spring of all modules.
>
Well, till now I just found transformers/generators that are extending
e.g. AbstractSAXTransformer which is an "old" component using avalon as
usual.
> When it comes to documentation, I think that document explaining how to develop Spring-based Cocoon
> component wouldn't be complicated or very long.
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?
e.g. http://cocoon.apache.org/2.2/core-modules/core/2.2/688_1_1.html is
avalon and not spring.
> The effort should consist of searching mail archives
> for all problems people had with developing Spring-based components up to date and collecting all
> the hints in one place in a consistent way.
Yeah and maybe some "master" examples such as an
al-AbstractSAXTransformer and al-AbstractGenerator.
> 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.
Thanks again.
salu2
>
> > Thanks for all your efforts.
>
> You welcome!
>
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Re: Logging of AbstractSAXTransformer
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Thorsten Scherler pisze:
> On Tue, 2007-10-30 at 18:27 +0100, Reinhard Poetz wrote:
>> Thorsten Scherler wrote:
> ...
>> The problem is that the AbstractSAXTransformer still uses Logkit logging and if
>> it is initialized by Spring, the logger isn't set.
>>
>> Fhis has been fixed in trunk by Vadim recently and will be part of the next release.
>
> I must admit that maven and me are not the best mates, but I am using
> latest trunk and still have this problem.
Don't worry, after some practising you should get enough expertise in use of Maven to work
effectively with Cocoon's trunk.
> I reckon it is a maven issue with artifacts et al. but how can I do aka
> ant a "ant clean build" from my current trunk and maven is actually
> using the trunk?
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.
> Further I am really missing some documentation about components using
> the new spring stuff only. I mean I know how to write avalon components
> from 2.1 but since I am trying to jump on the 2.2 train I want to
> develop avalon less components (I reckon that is the reason to use 2.2
> after all). I will try to add some as soon I get my custom transformer
> running.
Because of latest Vadim's effort you don't need to do that much. Just write spring bean, put
configuration in src/main/resources/META-INF/cocoon/spring directory and it should work as long as
you are using Cocoon's trunk that includes all recent fixes.
If you want to examine existing Cocoon's components based on Spring just search for configuration
files in src/main/resources/META-INF/cocoon/spring of all modules.
When it comes to documentation, I think that document explaining how to develop Spring-based Cocoon
component wouldn't be complicated or very long. The effort should consist of searching mail archives
for all problems people had with developing Spring-based components up to date and collecting all
the hints in one place in a consistent way.
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. ;-)
> Thanks for all your efforts.
You welcome!
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: Logging of AbstractSAXTransformer
Posted by Thorsten Scherler <th...@apache.org>.
On Tue, 2007-10-30 at 18:27 +0100, Reinhard Poetz wrote:
> Thorsten Scherler wrote:
...
> > I reckon I need to configure the logging differently but sadly there
> > seems to very little documentation yet (or at least I could not find it
> > yet).
> >
> > Any idea what I am doing wrong?
>
> The problem is that the AbstractSAXTransformer still uses Logkit logging and if
> it is initialized by Spring, the logger isn't set.
>
> Fhis has been fixed in trunk by Vadim recently and will be part of the next release.
I must admit that maven and me are not the best mates, but I am using
latest trunk and still have this problem.
I reckon it is a maven issue with artifacts et al. but how can I do aka
ant a "ant clean build" from my current trunk and maven is actually
using the trunk?
Further I am really missing some documentation about components using
the new spring stuff only. I mean I know how to write avalon components
from 2.1 but since I am trying to jump on the 2.2 train I want to
develop avalon less components (I reckon that is the reason to use 2.2
after all). I will try to add some as soon I get my custom transformer
running.
Thanks for all your efforts.
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions