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:29:44 GMT
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 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. 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



Mime
View raw message