cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Torsten Curdt" <>
Subject Re: cocoon-javaflow in cocoon 2.2
Date Fri, 11 Aug 2006 01:56:51 GMT

> In fact, if we replace the "method.invoke(o)" with "o.method()" (no reflection involved)
it works correctly.

1. what version of javaflow?
2. what version of jci?
3. the reflection is need as we are dealing with multiple classloaders

> IIUC the core of the instrumentation is done into the rewrite method, that parses the
bytecode operations and decides what to do; adding a
> block that identifies the invoke operation and adds a method call would work; we tried
unluckily to implement it, maybe someone could help us to understand how to do it.

I would ...but I didn't understand the above paragraph :)

Actually there is a testcase in javaflow for exactly this invoker setup.

> As I said, we arrived to this error by scaling down our target, our first test was to
enhance a simple Java class, out of cocoon environment, using the FilesystemAlterationMonitor,
that monitors a certain folder (in this case the folder containing the class file of the Javaflow)
and enhance it, if it has been changed. We found a ClassFormatException ( java.lang.ClassFormatError:
Incompatible magic value -272646673 in class file jci/Simple ) trying to read the original
bytecode of the class; debugging the code we discovered that the ReloadingListener is using
a FileReader to read the bytecode of the class; the FileReader parses the byte stream depending
on a certain char encoding. so the bytecode is not recognized by the classloader. Using a
FileInputStream it works (ReloadingClassLoaderTestCase confirms; with the original FileReader
implementation it fails).

Oh! Good finding! Strange I never came across that before ...anyway

> Then we tried to integrate the FilesystemAlterationMonitor with the cocoon classloader
configuration, in order to automatically reload and enhance the Javaflows when changed, but
we faced with some problems.
> - The FilesystemAlterationMonitor always notifies the changes of those classes that are
enhanced; the check is based on file.getLastModified() value, but every time the value is
lower then the last one, so the change notification is triggered. We didn't investigate more.

The FAM should notify about all classes once after the startup
...after that it should work fine. A few problems under Windows have
been reported though. (including suggestions on how to fix it)

What OS are you testing on?

> - The FileResourceStore fails trying to get the file by the filesystem:
> private File getFile(final String pResourceName) {
>   final String fileName = pResourceName.replace('/',File.separatorChar);
>   return new File(root, fileName);
> }
> where pResourceName = ""; changing the
return statement to :
> return new File(root,
>   fileName.replace('.',File.separatorChar).concat(".class"));
> it seems to work correctly.

Oh, yes ...jci has changed the contract in that respect to make it
more consistent.

all input to the stores are now "org/my/Some.class". So the resource
name should be changed from
"" to

> Before send some patches we'd like to know if we're investigating in the right direction
or not.
> We can also provide our temporary changes to the javaflow poms in order to enhance the
JavaInterpreter and the javaflow classes at build time, using the RewriteAntTask provided
by commons-javaflow and some fix to the cocoon-javaflow-sample block.

Wait a sec don't want to instrument the JavaInterpreter! But
enhancing classes at build time is a nice addition.

PS: Guys, really feel free to contact me ...not worth having you guys
spend time on what I might be able to answer via a quick ping over IM
or email.

Great you are looking into that!


View raw message