You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Saskia Heesen <sa...@gmx.de> on 2008/04/16 12:18:43 UTC
javaflow / URL of jar
Hello everybody!
I would like to use javaflow from Cocoon 2.2 since javaflow offers more ways to test the code than flowscript. When I run the example I get the error message:
2008-04-16 11:18:13,839 ERROR http-8080-Processor25 org.apache.commons.javaflow.bytecode.StackRecorder - stack corruption. Is class org.apache.cocoon.components.flow.java.Invoker instrumented for javaflow?
java.lang.IllegalStateException: stack corruption. Is class org.apache.cocoon.components.flow.java.Invoker instrumented for javaflow?
I think the main difference between Cocoon 2.1 and Cocoon 2.2 regarding javaflow is that javaflow is now based on commons.javaflow. commons.javaflow needs an enhancement of these classes, that are part of the continuation. So, we can't use the default system class loader. However, commons.javaflow provides an appropriate ContinuationClassLoader.
JavaInterpreter.java as part of cocoon-javaflow-impl still uses the default system class loader:
final Class clazz = Thread.currentThread().getContextClassLoader().loadClass(clazzName);
My idea is to replace it by ContinuationClassLoader
ClassLoader cl = new ContinuationClassLoader(
new URL[]{new URL("latter.jar")},
JavaInterpreter.class.getClassLoader());
"latter.jar" is not the correct jar file. I only know the classname:
2008-04-16 11:18:08,706 DEBUG http-8080-Processor25 org.apache.cocoon.components.flow.java.JavaInterpreter - loading org.apache.cocoon.samples.flow.java.CalculatorFlow
I don't know how to get the concerning URL of the jar-archive (path and name). Do you know an easy way to get the URL of the archive? The URL depends on the webcontainer, too.
Kind regards
Saskia
--
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx
Re: javaflow / URL of jar
Posted by Torsten Curdt <tc...@apache.org>.
> Hey Torsten!
Hey Gabriel
> I have been watching the mailinglist for the last year or so to see
> changes in javaflow in 2.2 which I would love to use.
There weren't many ;)
> It seems that you are the only one with the "complete" knowledge to
> finish javaflow in 2.2... I am sure there are others around which
> would like to help to get the job done. but my feeling so far is
> that it would be only minimum effort for you compared to all the
> others who have given up so far on this job...
Indeed as one of the main authors of javaflow and being a cocoon old
timer ...that could be right :)
> another option would be if you could lay out your plan for
> implementation and some other interested comitters could do it?
I surely can try.
> WDYT?
> I would love to use javaflow and i would love to help too if i can...
What needs to be done can be split into 3 parts
1. The Cocoon side of things
1.1 Last time I checked the continuation management infrastructure in
Cocoon needs an overhaul. While the recent thread on javaflow
scalability was 2.1 I am sure this still holds true for 2.2. I has
been a few years so please bear with my memory ...but I think the
following problems need to be addressed:
1.1.1 WebContinuation is a class but should be an interface. Javaflow
and flowscript would be a possible implentation.
1.1.2 Just like sessions there needs to be a hard limit for the number
of continuations that is enforced on continuation creation time
1.2 IIRC there currently is only one script allowed per sitemap. There
is no real good reason for that.
1.3 Support for flows in sub pipelines. This is more a special case
that mainly needs to addressed in javaflow - not i Cocoon land. But
it's a special case that has come up only in Cocoon. Javaflow
currently uses thread locals to store information. Maybe it would be
better to store that information in a context ...another option to
look into would be to use a stack. I'd prefer the context approach
though.
2. Javaflow over in commons
2.1 Javaflow currently has two implementations. The original one is
BCEL. The new one is ASM. It would be great to switch to ASM for
various reasons. But it seems the ASM implementation is even less
robust than the current BCEL one. Still I think is essential to focus
on just the one. And surely ASM is the way to go. That would also make
the current weird testcase approach simpler in javaflow.
2.2 There are a couple of byte code level things that need to be
fixed. This surely is the trickiest part.
o fix unintialized objects for method/constructor calls
o inner classes
o try/catch/finally
o synchronized(obj)
o accessing .class
o new Object() without assignment
see http://svn.apache.org/viewvc/commons/sandbox/javaflow/trunk/TODO?revision=560660&view=markup
There was some discussion in joining forces with Geer from RIFE. The
RIFE continuations work a little bit differently though and impose
some restrictions onto how you need to write the flow. Plus it's
LGPL ....but Geer sounded flexible about that when we talked. We also
tried to start a JSR for continuation support in the JVM - but that
was shut down. (Even Apache - whoever was responsible for it - voted
for "no")
2.3 Continuation branching should be re-evaluated. Cloning?
Serialization?
3. Build integration
3.1 Writing a maven plugin to instrument the resulting artifact should
probably just a few hours job. The initial goal was to replace the
maven compiler plugin with a maven jci plugin but... can't hurt to be
a bit more pragmatic on that one. I don't see maven really adopting
JCI for that anytime soon.
...that's how I remember it at least :)
Of course documentation is needed. And I also expect that the examples
need some love. I bet there is more :)
Unfortunately I don't really have the time and enthusiasm working on
this at the moment. Would be great to get this finished up and
released though. If someone else has the time and motivation - I am
certainly happy to give comments/advice.
cheers
--
Torsten
Re: javaflow / URL of jar
Posted by Gabriel Gruber <Ga...@workflow.at>.
Hey Torsten!
I have been watching the mailinglist for the last year or so to see
changes in javaflow in 2.2 which I would love to use.
It seems that you are the only one with the "complete" knowledge to finish
javaflow in 2.2... I am sure there are others around which would like to
help to get the job done. but my feeling so far is that it would be only
minimum effort for you compared to all the others who have given up so far
on this job... another option would be if you could lay out your plan for
implementation and some other interested comitters could do it?
WDYT?
I would love to use javaflow and i would love to help too if i can...
thanx
gabriel
______________________
Mag. Gabriel Gruber
Senior Consultant
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Workflow EDV GmbH, Dannebergplatz 6/23, A-1030 Wien
Torsten Curdt <tc...@apache.org>
16.04.2008 14:28
Please respond to
dev@cocoon.apache.org
To
dev@cocoon.apache.org
cc
Subject
Re: javaflow / URL of jar
On Apr 16, 2008, at 12:18, Saskia Heesen wrote:
> Hello everybody!
>
> I would like to use javaflow from Cocoon 2.2 since javaflow offers
> more ways to test the code than flowscript. When I run the example I
> get the error message:
>
> 2008-04-16 11:18:13,839 ERROR http-8080-Processor25
> org.apache.commons.javaflow.bytecode.StackRecorder - stack
> corruption. Is class org.apache.cocoon.components.flow.java.Invoker
> instrumented for javaflow?
> java.lang.IllegalStateException: stack corruption. Is class
> org.apache.cocoon.components.flow.java.Invoker instrumented for
> javaflow?
>
> I think the main difference between Cocoon 2.1 and Cocoon 2.2
> regarding javaflow is that javaflow is now based on
> commons.javaflow. commons.javaflow needs an enhancement of these
> classes, that are part of the continuation. So, we can't use the
> default system class loader. However, commons.javaflow provides an
> appropriate ContinuationClassLoader.
>
> JavaInterpreter.java as part of cocoon-javaflow-impl still uses the
> default system class loader:
>
> final Class clazz =
> Thread.currentThread().getContextClassLoader().loadClass(clazzName);
>
> My idea is to replace it by ContinuationClassLoader
That's not a really good idea. In 2.2 javaflow basically works hand in
hand with the RCL from JCI.
The idea is that you can basically point cocoon to your eclipse
environment and JCI will pickup the class file changes whenever you
change a class through eclipse ...and it will instrument it. This is
for development.
For deployment the idea is that you should include the instrumentation
phase into your build process. Unfortunately there is still only an
ant task for it. The idea was to write a maven jci compiler plugin
that would essentially replace the original maven one. Being more
flexible and supporting things like instrumentations on compile time.
But as I don't see that happen in the near future it might be easier
to just turn the ant task into a very simple maven javaflow
plugin ...or call the ant task from maven.
Important thing to note is that in 2.2 the instrument/don't
instrumentation is handled via class separation - not a marker
interface. So essentially you have one jar with your custom classes
and one jar with your flow that should have been instrumented.
HTH
cheers
--
Torsten
Re: javaflow / URL of jar
Posted by Torsten Curdt <tc...@apache.org>.
On Apr 16, 2008, at 12:18, Saskia Heesen wrote:
> Hello everybody!
>
> I would like to use javaflow from Cocoon 2.2 since javaflow offers
> more ways to test the code than flowscript. When I run the example I
> get the error message:
>
> 2008-04-16 11:18:13,839 ERROR http-8080-Processor25
> org.apache.commons.javaflow.bytecode.StackRecorder - stack
> corruption. Is class org.apache.cocoon.components.flow.java.Invoker
> instrumented for javaflow?
> java.lang.IllegalStateException: stack corruption. Is class
> org.apache.cocoon.components.flow.java.Invoker instrumented for
> javaflow?
>
> I think the main difference between Cocoon 2.1 and Cocoon 2.2
> regarding javaflow is that javaflow is now based on
> commons.javaflow. commons.javaflow needs an enhancement of these
> classes, that are part of the continuation. So, we can't use the
> default system class loader. However, commons.javaflow provides an
> appropriate ContinuationClassLoader.
>
> JavaInterpreter.java as part of cocoon-javaflow-impl still uses the
> default system class loader:
>
> final Class clazz =
> Thread.currentThread().getContextClassLoader().loadClass(clazzName);
>
> My idea is to replace it by ContinuationClassLoader
That's not a really good idea. In 2.2 javaflow basically works hand in
hand with the RCL from JCI.
The idea is that you can basically point cocoon to your eclipse
environment and JCI will pickup the class file changes whenever you
change a class through eclipse ...and it will instrument it. This is
for development.
For deployment the idea is that you should include the instrumentation
phase into your build process. Unfortunately there is still only an
ant task for it. The idea was to write a maven jci compiler plugin
that would essentially replace the original maven one. Being more
flexible and supporting things like instrumentations on compile time.
But as I don't see that happen in the near future it might be easier
to just turn the ant task into a very simple maven javaflow
plugin ...or call the ant task from maven.
Important thing to note is that in 2.2 the instrument/don't
instrumentation is handled via class separation - not a marker
interface. So essentially you have one jar with your custom classes
and one jar with your flow that should have been instrumented.
HTH
cheers
--
Torsten