You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Christofer Dutz <ma...@c-ware.de> on 2008/12/31 13:52:52 UTC
Problems with JavaFlow
Hi,
I am currently writing a documentation of how to setup an Environment to
build Cocoon 2.2 application using Cocoon 2.2, JavaFlow and CForms.
Unfortunately there seems to be a problem with the current JavaFlow
implementation. I thought this was my problem, so I did a completely clean
build of cocoon and, step by step did everything again. The result was the
same:
Whenever I call a pipeline to generate a Form this form is correctly
displayed, but in the background my Eclipse console (and the cocoon log)
tell me "Pipeline has already been processed for this request". When doing a
little debugging I found out that this is caused by the sendPageAndWait
method. This instantaneously returns and doesn't block. When debugging into
the JavaFlow code, it seems that usually (when debugging older versions of
the JavaFlow in Cocoon 2.1) 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.
For the moment I seem to be stuck here . any help is greatly appreciated.
For the moment I am completely suck here L
Chris
AW: Problems with JavaFlow
Posted by Christofer Dutz <ma...@c-ware.de>.
Hi,
At first I decided to completely abandon BCEL Instrumentation, since if it's
deprecated now, I can't see the sense of artificially keeping it alive :-)
I finally managed to solve some of the major problems I was having:
1. as soon as I have my "cocoon-javaflow-maven-plugin" and the
"cocoon-maven-plugin" in my pom, the default cocoon-plugin freezes up.
2. I had to dynamically add the current "target/classes" to the plug-ins
classpath, in order to make the ASM stuff work.
3. Implement the pattern-matching to control which classes to instrument
(currently all are instrumented)
I am not really satisfied with my solution of (1) ... since it involved
simply inserting my new plugin in the "generate-test-sources" phase, which
is not very pretty. I'm not quite sure, why the cocoon plug-in freezes ...
maybe someone on this list has an idea.
I solved number 2 by creating a URLClassLoader and inserting it.
As soon as I have issue 3 finished, I'll zip the project up and send it to
you.
Chris
-----Ursprüngliche Nachricht-----
Von: Christofer Dutz [mailto:mailinglists@c-ware.de]
Gesendet: Montag, 5. Januar 2009 10:48
An: dev@cocoon.apache.org
Betreff: AW: Problems with JavaFlow
Hi Torsten,
I am currently not @home, so I don't want wo piss off my customer by working
on private stuff ;-)
I'll try to sort out some small Issues with having both the javaflow and the
cocoon plugin active at the same time and will send you a zip with the
complete package. Switching to ASM sounds great. As I mentioned the javaflow
guys switched to ASM as default a few months ago (unfortunately this is the
time where JavaFlow stopped working for me.
Chris
-----Ursprüngliche Nachricht-----
Von: tcurdt@vafer.org [mailto:tcurdt@vafer.org] Im Auftrag von Torsten Curdt
Gesendet: Montag, 5. Januar 2009 09:47
An: dev@cocoon.apache.org
Betreff: Re: Problems with JavaFlow
Hey Chris
> I have finished a working prototype of the Javaflow Maven plug-in.
Where is it? 8-)
> Still there has to be some beautifying to be done. One thing I noticed
while
> working on it was that BCEL seems to have been completely deprecated.
Yeah, I would like to get rid of it - frankly speaking :)
> Therefore I tried switching to ASM, but the switch to ASM doesn't seem
to be
> a easy as implied by the Ant-Task code. I'll have to manually add the
Flow
> classes to the classpath available to the plug-in. I guess it's just a
> little more Maven-Learning for me to do first ... :-)
Let me have a look.
> Unfortunately even with an instrumented Invoker and all JavaFlow classes
> instrumented, I still get the same error message.
Thanks for your work. This is motivating.
I'll clean up javaflow trunk and build a testcase of what is needed in
Cocoon. And then we can take it from there.
cheers
--
Torsten
AW: Problems with JavaFlow
Posted by Christofer Dutz <ma...@c-ware.de>.
Hi Torsten,
I am currently not @home, so I don't want wo piss off my customer by working
on private stuff ;-)
I'll try to sort out some small Issues with having both the javaflow and the
cocoon plugin active at the same time and will send you a zip with the
complete package. Switching to ASM sounds great. As I mentioned the javaflow
guys switched to ASM as default a few months ago (unfortunately this is the
time where JavaFlow stopped working for me.
Chris
-----Ursprüngliche Nachricht-----
Von: tcurdt@vafer.org [mailto:tcurdt@vafer.org] Im Auftrag von Torsten Curdt
Gesendet: Montag, 5. Januar 2009 09:47
An: dev@cocoon.apache.org
Betreff: Re: Problems with JavaFlow
Hey Chris
> I have finished a working prototype of the Javaflow Maven plug-in.
Where is it? 8-)
> Still there has to be some beautifying to be done. One thing I noticed
while
> working on it was that BCEL seems to have been completely deprecated.
Yeah, I would like to get rid of it - frankly speaking :)
> Therefore I tried switching to ASM, but the switch to ASM doesn't seem
to be
> a easy as implied by the Ant-Task code. I'll have to manually add the
Flow
> classes to the classpath available to the plug-in. I guess it's just a
> little more Maven-Learning for me to do first ... :-)
Let me have a look.
> Unfortunately even with an instrumented Invoker and all JavaFlow classes
> instrumented, I still get the same error message.
Thanks for your work. This is motivating.
I'll clean up javaflow trunk and build a testcase of what is needed in
Cocoon. And then we can take it from there.
cheers
--
Torsten
Re: Problems with JavaFlow
Posted by Torsten Curdt <tc...@apache.org>.
Hey Chris
> I have finished a working prototype of the Javaflow Maven plug-in.
Where is it? 8-)
> Still there has to be some beautifying to be done. One thing I noticed while
> working on it was that BCEL seems to have been completely deprecated.
Yeah, I would like to get rid of it - frankly speaking :)
> Therefore I tried switching to ASM, but the switch to ASM doesn't seem to be
> a easy as implied by the Ant-Task code. I'll have to manually add the Flow
> classes to the classpath available to the plug-in. I guess it's just a
> little more Maven-Learning for me to do first ... :-)
Let me have a look.
> Unfortunately even with an instrumented Invoker and all JavaFlow classes
> instrumented, I still get the same error message.
Thanks for your work. This is motivating.
I'll clean up javaflow trunk and build a testcase of what is needed in
Cocoon. And then we can take it from there.
cheers
--
Torsten
AW: Problems with JavaFlow
Posted by Christofer Dutz <ma...@c-ware.de>.
Hi Torsten,
I have finished a working prototype of the Javaflow Maven plug-in.
Still there has to be some beautifying to be done. One thing I noticed while
working on it was that BCEL seems to have been completely deprecated.
Therefore I tried switching to ASM, but the switch to ASM doesn't seem to be
a easy as implied by the Ant-Task code. I'll have to manually add the Flow
classes to the classpath available to the plug-in. I guess it's just a
little more Maven-Learning for me to do first ... :-)
Unfortunately even with an instrumented Invoker and all JavaFlow classes
instrumented, I still get the same error message.
Chris
-----Ursprüngliche Nachricht-----
Von: tcurdt@vafer.org [mailto:tcurdt@vafer.org] Im Auftrag von Torsten Curdt
Gesendet: Mittwoch, 31. Dezember 2008 17:51
An: dev@cocoon.apache.org
Betreff: Re: Problems with JavaFlow
> Hi Torsten (Sorry for the "h" ... I simply know too much Thorstens) ;-)
No worries
> 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.
Hmmmm ... that needs some debugging then. Maybe next year ;)
cheers
--
Torsten
Re: Problems with JavaFlow
Posted by Torsten Curdt <tc...@apache.org>.
> Hi Torsten (Sorry for the "h" ... I simply know too much Thorstens) ;-)
No worries
> 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.
Hmmmm ... that needs some debugging then. Maybe next year ;)
cheers
--
Torsten
AW: Problems with JavaFlow
Posted by Christofer Dutz <ma...@c-ware.de>.
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.
Chris
-----Ursprüngliche Nachricht-----
Von: Torsten Curdt [mailto:tcurdt@vafer.org]
Gesendet: Mittwoch, 31. Dezember 2008 16:09
An: dev@cocoon.apache.org
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 org.apache.cocoon.components.flow.java.Invoker
> 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="org.apache.cocoon.components.flow.java.JavaflowResourceStore" />
> </class-dir>
> <class-dir src="file://E:/Projekte/3rd
>
Party/cocoon-2.2.0-svn/blocks/cocoon-javaflow/cocoon-javaflow-impl/target/cl
> asses">
> <store
> class="org.apache.cocoon.components.flow.java.JavaflowResourceStore" />
> </class-dir>
> <include-classes
> pattern="org.apache.cocoon.forms.flow.java.FormInstance" />
> <include-classes pattern="org.apache.cocoon.samples.flow.java.**" />
> <include-classes
> pattern="org.apache.cocoon.components.flow.java.AbstractContinuable" />
> </map:classloader>
>
> I have tried the configuration of the javaflow without the "file://"
prefix,
> 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?
Exactly
> 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?
Exactly
> 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
would
> 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.
http://commons.apache.org/jci/apidocs/org/apache/commons/jci/stores/Resource
Store.html
http://commons.apache.org/sandbox/javaflow/apidocs/org/apache/commons/javafl
ow/stores/JavaflowResourceStore.html
> Regards and I hope you all start the new year really great :-)
Likewise!
cheers
--
Torsten
Re: Problems with JavaFlow
Posted by Torsten Curdt <tc...@vafer.org>.
> 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 org.apache.cocoon.components.flow.java.Invoker
> 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="org.apache.cocoon.components.flow.java.JavaflowResourceStore" />
> </class-dir>
> <class-dir src="file://E:/Projekte/3rd
> Party/cocoon-2.2.0-svn/blocks/cocoon-javaflow/cocoon-javaflow-impl/target/cl
> asses">
> <store
> class="org.apache.cocoon.components.flow.java.JavaflowResourceStore" />
> </class-dir>
> <include-classes
> pattern="org.apache.cocoon.forms.flow.java.FormInstance" />
> <include-classes pattern="org.apache.cocoon.samples.flow.java.**" />
> <include-classes
> pattern="org.apache.cocoon.components.flow.java.AbstractContinuable" />
> </map:classloader>
>
> I have tried the configuration of the javaflow without the "file://" prefix,
> 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?
Exactly
> 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?
Exactly
> 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 would
> 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.
http://commons.apache.org/jci/apidocs/org/apache/commons/jci/stores/ResourceStore.html
http://commons.apache.org/sandbox/javaflow/apidocs/org/apache/commons/javaflow/stores/JavaflowResourceStore.html
> Regards and I hope you all start the new year really great :-)
Likewise!
cheers
--
Torsten
AW: Problems with JavaFlow
Posted by Christofer Dutz <ma...@c-ware.de>.
Hi Thorsten,
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 ;-)
It seems in my first version the Flow classes werent instrumented because of
my wrong configuration of the classloader. After fixing this I am getting
errors in my cocoon log telling me, that there is an error instrumenting the
Flow classes because of an error ... i guess the system then falls back to
normal class loading and therefore I get the same error again.
Hwere is the error I am getting:
2008-12-31 15:01:24,709 btpool0-1 ERROR 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?
at
org.apache.commons.javaflow.bytecode.StackRecorder.execute(StackRecorder.jav
a:103)
at
org.apache.commons.javaflow.Continuation.continueWith(Continuation.java:171)
at
org.apache.commons.javaflow.Continuation.startWith(Continuation.java:130)
at
org.apache.cocoon.components.flow.java.JavaInterpreter.callFunction(JavaInte
rpreter.java:154)
at
org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(C
allFunctionNode.java:109)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:55)
at
org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNod
e.java:87)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:78)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(Pipel
ineNode.java:143)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:78)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(Pipe
linesNode.java:81)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(Con
creteTreeProcessor.java:241)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(Con
creteTreeProcessor.java:173)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
or.java:247)
at
org.apache.cocoon.servlet.RequestProcessor.process(RequestProcessor.java:347
)
at
org.apache.cocoon.servlet.RequestProcessor.service(RequestProcessor.java:169
)
at
org.apache.cocoon.sitemap.SitemapServlet.service(SitemapServlet.java:82)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopU
tils.java:310)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint
(ReflectiveMethodInvocation.java:182)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Reflect
iveMethodInvocation.java:149)
at
org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(
MethodInvocationProceedingJoinPoint.java:77)
at
org.apache.cocoon.jnet.URLHandlerFactoryCollector.installURLHandlers(URLHand
lerFactoryCollector.java:37)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWith
GivenArgs(AbstractAspectJAdvice.java:627)
at
org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(Abs
tractAspectJAdvice.java:616)
at
org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvi
ce.java:64)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Reflect
iveMethodInvocation.java:171)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(Expos
eInvocationInterceptor.java:89)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Reflect
iveMethodInvocation.java:171)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopPro
xy.java:204)
at $Proxy3.service(Unknown Source)
at
org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forwar
d(ServletServiceContext.java:481)
at
org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forwar
d(ServletServiceContext.java:455)
at
org.apache.cocoon.servletservice.spring.ServletFactoryBean$ServiceIntercepto
r.invoke(ServletFactoryBean.java:245)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Reflect
iveMethodInvocation.java:171)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopPro
xy.java:204)
at $Proxy6.service(Unknown Source)
at
org.apache.cocoon.servletservice.DispatcherServlet.service(DispatcherServlet
.java:106)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingServlet.service(Reloadi
ngServlet.java:91)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler
.java:1093)
at
org.apache.cocoon.servlet.multipart.MultipartFilter.doFilter(MultipartFilter
.java:131)
at
org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingServletFilter.doFilter(
ReloadingServletFilter.java:51)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler
.java:1084)
at
org.apache.cocoon.servlet.DebugFilter.doFilter(DebugFilter.java:167)
at
org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingServletFilter.doFilter(
ReloadingServletFilter.java:51)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler
.java:1084)
at
org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingSpringFilter.doFilter(R
eloadingSpringFilter.java:67)
at
org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingServletFilter.doFilter(
ReloadingServletFilter.java:51)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler
.java:1084)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:722)
at
org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:404)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:324)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnectio
n.java:828)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:4
50)
Unfortunaltely I couldn't really get more information from this ... maybe it
helps you give me a hint ... as I am using a copy of the Flow java class
from the example (with stripped out editForm2 method to avoid problems) I
doubt, that there is something really wrong with the code. ;-)
Here is my classloader configuration. It seems the problem is that the
javaflow classes themselves arent instrumented correctly
<map:classloader
factory-role="org.apache.cocoon.classloader.ClassLoaderFactory/reloading">
<class-dir src="../../../target/classes">
<store
class="org.apache.cocoon.components.flow.java.JavaflowResourceStore" />
</class-dir>
<class-dir src="file://E:/Projekte/3rd
Party/cocoon-2.2.0-svn/blocks/cocoon-javaflow/cocoon-javaflow-impl/target/cl
asses">
<store
class="org.apache.cocoon.components.flow.java.JavaflowResourceStore" />
</class-dir>
<include-classes
pattern="org.apache.cocoon.forms.flow.java.FormInstance" />
<include-classes pattern="org.apache.cocoon.samples.flow.java.**" />
<include-classes
pattern="org.apache.cocoon.components.flow.java.AbstractContinuable" />
</map:classloader>
I have tried the configuration of the javaflow without the "file://" prefix,
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. 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 :-)
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 would
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.
Regards and I hope you all start the new year really great :-)
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
Re: Problems with JavaFlow
Posted by Torsten Curdt <tc...@apache.org>.
> 1. since Cocoon is Maven, based I sort of dislike the option of falling back
> to ant.
Can't say I'd like it ...but it would get the job done quickly.
> 2. Wouldn't this ad a dependency to JavaFlow to cocoon itself?
No - only to JCI. And that's already there.
But as it looks all that is required is already supported with the
RCL. At least from the configuration options it looks like.
> 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"
Yepp! :)
> ... I guess I would need more detailed information about JavaFlow for
> this
No you really don't! You need some maven knowledge on how to write a mojo.
Check out the ant task. All it does is
foreach class in classes {
if (matches(class)) {
oldClassFile = input.read()
newClassFile = transformer.transform(oldClassFile)
output.write(newClassFile)
} else {
IOUtils.copy(input, output)
}
}
You could probably even leave out the matching for now.
> ... maybe you're going to drop by near Frankfurt someday ;-)
I am in Frankfurt until mid Jan.
> 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 ...
As said: The development/deployment approach worked very well for me
with eclipse.
> 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.
Indeed it is a little more complex. But the maven jci plugin would
support all sorts of compilers.
> 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:
Actually I think all is needed is such a maven instrumentation plugin.
> 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.
Actually that's something that could be added to the class transformer
itself. If there already is a dependency to the javaflow runtime
classes it's not instrumented again. That would make the whole think
quite fool proof. Easy to implement as well.
> This would make development a lot easier and boost the default
> performance of production builds.
Here you lost me again :)
> 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 ;-)
:-)
cheers
--
Torsten
AW: Problems with JavaFlow
Posted by Christofer Dutz <ma...@c-ware.de>.
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
Re: Problems with JavaFlow
Posted by Torsten Curdt <tc...@apache.org>.
> 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