cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christofer Dutz" <mailingli...@c-ware.de>
Subject AW: Problems with JavaFlow
Date Wed, 31 Dec 2008 14:54:18 GMT
Hi Thorsten,

to comment your options mentioned below:
1. since Cocoon is Maven, based I sort of dislike the option of falling back
to ant.
2. Wouldn't this ad a dependency to JavaFlow to cocoon itself? It seems not
a lot of people seem to be using JavaFlow. Otherwise I would read a lot more
questions here and in the user list, so I think this is no real option. But
on the "upside", it would make integration with Eclipse a lot easier. I have
no real knowledge about the RCL, but if it were extendable with plug-ins
registering for certain classpath sections ... this should be a cool
approach.
3. At the moment I think I would like this option a lot ... even if my
gut-feeling tells me in your next mail you're going to say "cool ... write
it" ... I guess I would need more detailed information about JavaFlow for
this ... maybe you're going to drop by near Frankfurt someday ;-)
One thing I like about this, is that I would get pre-instrumented JavaFlow
classes form my flows. The downside is that It might need some kind of
Eclipse plug-in to accompany it since Eclipse would replace the instrumented
class with a non instrumented one as soon as someone changes it ... 
4. Ok ... this one sounds a little more complex. In some projects I am
currently working on, we are using the eclipse compiler instead of the
ordinary maven-one since the default Jdk compiler seems to have some
problems dealing with some Java 1.6 features (strange thing that suns
compiler seems to have problems with suns features) ... this would rob me of
this option. 

I would propose that a solution of 2 + 3 sounds safest from my point of
view. Writing a plug-in for the RCL (assuming there is something like that).
In addition creating a Maven plug-in doing the instrumentation would be
great. Both could work together:
The Maven could set some kind of mark in the instrumented classes to
indicate the RCL-plug-in that this class was already instrumented. In this
case the RCL simply relays the class. If the flag is not set it instruments
the class. This would make development a lot easier and boost the default
performance of production builds.

Every time I say, that I would gladly contribute, Murphy comes along and
steals all my free time, so let me say, that if the information I need sort
of pops up in my Mail-Folder, and Murphy left over some time, I will gladly
try to do something with this information ... even if it is only printing it
and throwing paper balls at Murphy ;-)


Chris





-----Urspr√ľngliche Nachricht-----
Von: tcurdt@vafer.org [mailto:tcurdt@vafer.org] Im Auftrag von Torsten Curdt
Gesendet: Mittwoch, 31. Dezember 2008 14:52
An: dev@cocoon.apache.org
Betreff: Re: Problems with JavaFlow

> the "Continuation.suspend()" call would freeze
> until the page is submitted - not anymore. I have noticed that there seems
> to have been a change in the Apache-Javaflow project, since I needed to
> manually build and install this to be able to build the cocoon-javaflow
> block. This build no longer requires tweaking of Testcases to build, so I
> guess they have changed something. After having a look at the svn-log I
> could read that they seem to have changed the default Byte-Code
manipulation
> engine from BCEL to ASM ¬Ö but I really doubt, this should be causing the
> fundamental Continuation.suspend() call to fail, unless there has to be
some
> more setting up to do now. I think I have to dig into this a little more,
> but at the moment I would suggest that the bytecode manipulataion needed
for
> JavaFlow is simply not executed.

Sounds like it - yes.

The question is: how/when is the instrumentation done? (remember:
there no longer is a marker interface and no classloader doing the
instrumentation!)

When I was demoing the javaflow and jci integration in Amsterdam
(years ago) that was with 2.2 IIRC. Let me describe how that worked:

In the sitemap I pointed jci to the eclipse output folder. Whenever a
class changed the reloading classloader reloaded the class AND
instrumented the class! So the RCL was not just for class reloading
but also for javaflow reloading and instrumentation!
For the final deployment you would use the ant task to build a jar and
instrument it during the build

http://svn.apache.org/repos/asf/commons/sandbox/javaflow/trunk/src/java/org/
apache/commons/javaflow/ant/AntRewriteTask.java

So there are a couple of options:

1. use the existing ant task within the build with the maven ant task plugin
2. configure/change/fix the cocoon reloading to also support
instrumentation (or does it already?)
3. write a quick maven plugin to do the instrumentation after compilation
4. finish the final goal of to replace the maven compiler plugin with
a maven jci plugin (that also supports compile time instrumentation)

That is also in the reverse order of complexity/time to spend.

HTH

cheers
--
Torsten



Mime
View raw message