Hi there, my environment is: JBoss 7.2+ (actually 6.1.1.GA) or Wildfly 8.0 Final Tapestry5 5.3.7
I'm developing a little ear, which has the following structure myear.ear | core-1.1.jar | webclient-1.1.war | lib/ | plastic-5.3.7.jar | tapestry5-annotations-5.3.7.jar | tapestry-core-5.3.7.jar | tapestry-func-5.3.7.jar | tapestry-ioc-5.3.7.jar | tapestry-json-5.3.7.jar | tapestry-upload-5.3.7.jar | ... omissis ... the core-1.1.jar module contains few EJBs, the webclient-1.1.war module contains my t5 app (pages, components and so on) I routinely use and appreciate t5 IOC, so I used it also in the core module; at this point I need to have the t5 jars available to the core AND to the webclient, so I put them in the shared "lib" folder of the EAR. So far, so good: the app worked and I had no problem. Today I was needing to place an object (a simple bean with 3 strings attributes and their getters and setters) and serialize/deserialize it into a file. The bean is needed only in the webclient (I need to place it in session), so I placed it in the webclient.war. Now my webapp crashed when I try to instantiate a page that refers to the bean. Looking at the problem, it seems to be caused by plastic that tries to reach the class by using the jboss classloader. This is the relevant part of the stack: --- org.apache.tapestry5.internal.plastic.asm.ClassWriter.getCommonSuperClass(ClassWriter.java:1588) org.apache.tapestry5.internal.plastic.asm.ClassWriter.getMergedType(ClassWriter.java:1559) org.apache.tapestry5.internal.plastic.asm.Frame.merge(Frame.java:1406) org.apache.tapestry5.internal.plastic.asm.Frame.merge(Frame.java:1308) org.apache.tapestry5.internal.plastic.asm.MethodWriter.visitMaxs(MethodWriter.java:1353) org.apache.tapestry5.internal.plastic.asm.tree.MethodNode.accept(MethodNode.java:635) org.apache.tapestry5.internal.plastic.asm.tree.MethodNode.accept(MethodNode.java:557) org.apache.tapestry5.internal.plastic.asm.tree.ClassNode.accept(ClassNode.java:361) org.apache.tapestry5.internal.plastic.PlasticClassPool.toBytecode(PlasticClassPool.java:187) org.apache.tapestry5.internal.plastic.PlasticClassPool.realize(PlasticClassPool.java:140) org.apache.tapestry5.internal.plastic.PlasticClassPool.realizeTransformedClass(PlasticClassPool.java:122) org.apache.tapestry5.internal.plastic.PlasticClassImpl.createInstantiator(PlasticClassImpl.java:358) org.apache.tapestry5.internal.plastic.PlasticClassPool.loadAndTransformClass(PlasticClassPool.java:350) org.apache.tapestry5.internal.plastic.PlasticClassLoader.loadClass(PlasticClassLoader.java:38) java.lang.ClassLoader.loadClass(ClassLoader.java:358) java.lang.Class.getDeclaredFields0(Native Method) java.lang.Class.privateGetDeclaredFields(Class.java:2509) java.lang.Class.getDeclaredField(Class.java:1959) --- In the JEE spec it is written that the war classloader must be isolated from the EAR classloader. In my understanding this means that t5 plastic (which lives in the EAR classloader) cannot reach the classes that are in the war (separate classloader). I could place the jars in the war/lib folder, but at this point the core module cannot see them. The only viable solution that I found is to place the bean classes in the shared lib folder, by extracting them from the war, but this is only a temporary patch. In the past I developed another ear and I had a similar issue trying to instantiate a page from another page. I solved it by avoiding the link between the two pages; but now I'm starting to think that it was another "face" of the same problem. Now, since these issues are becoming too frequent to work around them, and I'm wandering if there is a real solution or there's a real compatibility issue between T5 and JEE specs. Is there anyone that can help me? Thanks, larzeni --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
