<snip/>
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 = "org.apache.cocoon.samples.flow.java.SimpleFlow";
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
"org.apache.cocoon.samples.flow.java.SimpleFlow" to
"org/apache/cocoon/samples/flow/java/SimpleFlow.class"
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 ....you 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!
cheers
--
Torsten
