cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christofer Dutz" <>
Subject AW: Problems with JavaFlow
Date Wed, 31 Dec 2008 16:31:14 GMT
Hi Torsten (Sorry for the "h" ... I simply know too much Thorstens) ;-)

I built myself a instrumented version of the Invocer. I could see that the
class-file was now about two thirds larger and repackaged it. Unfortunately
I am still getting the same error. Seems as if this wasn't the issue here.


-----Urspr√ľngliche Nachricht-----
Von: Torsten Curdt [] 
Gesendet: Mittwoch, 31. Dezember 2008 16:09
Betreff: Re: Problems with JavaFlow

> Hi Thorsten,

s/h// ;)

> I did a little more research on this.
> At first i noticed that I didn't adapt the class-loader part when copying
> stuff from the demo-application.
> After stting these to absolute paths, I got a little further. Lets say the
> error messages are a little more verbous now ;-)


> 2008-12-31 15:01:24,709 btpool0-1 ERROR bytecode.StackRecorder - stack
> corruption. Is class
> instrumented for javaflow?

I vaguely remember that the "Invoker" class also needs to be instrumented.
This needs to be added to the cocoon build - but I guess it never was.

For a first try you could unzip the jar, instrument it, and zip it up again.
If that works we only need to get it into the build.

> Here is my classloader configuration. It seems the problem is that the
> javaflow classes themselves aren't instrumented correctly
>    <map:classloader
> factory-role="org.apache.cocoon.classloader.ClassLoaderFactory/reloading">
>      <class-dir src="../../../target/classes">
>        <store
> class="" />
>      </class-dir>
>      <class-dir src="file://E:/Projekte/3rd
> asses">
>        <store
> class="" />
>      </class-dir>
>      <include-classes
> pattern="" />
>      <include-classes pattern="**" />
>      <include-classes
> pattern="" />
>    </map:classloader>
> I have tried the configuration of the javaflow without the "file://"
> but the result was the same.
> Is it really necessary to have an exploded class directory of the javaflow
> implementation available? This seems sort of inconvenient.

No - as said: this should only be required for development mode. In
deployment you would jar everything up and rewrite it during build
time. Another option would be add jar loading support to jci.

> How about
> instrumenting them before building the jar file? Shouldn't this remove the
> need to explicitly instrument them at runtime?


> While digging into the code of the JavaflowResourceStore I could read a
> comment about some need to do things because of BCEL otherwise you could
> just delegate to TransfromingResourceStore ... in the log of the
> commons-javaflow block I could read that they switched to from BCEL to ASM
> as default bytecode manipulation engine a few months ago ... maybe this
> could clean up this area a little. Just as a hint :-)

Indeed but that is just an implementation detail. The store is only
getting start/stop information on the transaction and IIRC delaying
the write to the stop.

> Do I correctly understand the sample? We configure some packages to be
> accessed using a JavaFlowResourceStore which will deal with the
> modifications needed to make JavaFlow work?


> If yes, I'd suggest a small
> block of comments in the example here because I could only start to
> understand what's going on here by looking at the code. For my taste I
> have sort of turned around the configuration ... you put in a path into a
> store instead of putting a store into a path ... sort of is a little
> unintuitive.

There you lost me.

> Regards and I hope you all start the new year really great :-)



View raw message