https://translate.google.com/translate?sl=fr&tl=en&js=y&prev=_t&hl=fr&ie=UTF-8&u=http%3A%2F%2Fjavaetmoi.com%2F2013%2F01%2Fisoler-classloader-ear-jboss%2F&edit-text=&act=url
Le 12/12/2015 15:08, Luca Arzeni a écrit :
Hi Jens,
core module contains some EJBs: I'm using JPA for the persistence and SLSB as
facade to achieve a transactional demarcation strategy. So I could roughly say
that the core module contains the persistence layer and the business logic,
which is used by different client application, few of them are webapps, while
other are desktop apps.
I use this strategy in the web app and in a desktop GUI app:
- the web apps use the SLSB approach, looking up the beans in the webapp
module, and allowing them to be injected the pages ad T5 services;
- the desktop and command line apps use directly the IOC of T5 to inject
services when I need them
So, an EAR usually contains three or more war module and a EJB module, while
desktop and command line apps are usually a GUI around some services.
As you can undestand, the real app is more complex than the simple project that
I used for test, and replicating EJB and T5 jars every where could make my EAR
to explode for size and complexity.
Anyway the testcase, that I used to pinpoint the problem, should be simple
enough to demonstrate the issue.
I often see that people is deploy t5 as war inside tomcat or jetty.
I'm wondering if there is someone around that is usually deploying EARs with
jboss and glassfish that has found similar issues...
Thanks,
Luca
Sent: Saturday, December 12, 2015 at 2:02 PM
From: "mailingl...@j-b-s.de" <mailingl...@j-b-s.de>
To: "Tapestry users" <users@tapestry.apache.org>
Subject: Re: Is tapestry plastic incompatible with JEE specs?
What is in your core Module? Services using T5 IOC? Why is the core Module not
part of the war?
To me it looks more like a structural / serup problem than a real Tapestry
issue, to be honest. But I can be entirely wrong because I do not know the
requirements of your project and why it is structured this way.
If you need these libs in different classloaders not belonging to same hiererchy, you
can't share them. The same class loaded from different classloaders will cause trouble
anyway, too. Maybe you only need it on compile time and "maven provided" on
your war pom.xml is the solution?
Jens
Von meinem iPhone gesendet
Am 11.12.2015 um 22:20 schrieb Luca Arzeni <l.arz...@iname.com>:
Hi Jens,
the point is that I need them in the lib since I use them also in the core
module.
I can place them in the lib AND in the war, but I cannot place them ONLY in the
war.
Also, I ask about compatibility because if I have properly spotted the issue,
some kind of problem could arise also in the core (read: ejb.jar) module.
The real showstopper is the pervasive usage that I'm doing of tapestry IOC.
I like it, but if these problems cannot be solved, it may be better for me to
migrate to Guice or Spring.
Thanks,
larzeni
Sent: Friday, December 11, 2015 at 8:00 PM
From: "mailingl...@j-b-s.de" <mailingl...@j-b-s.de>
To: "Tapestry users" <users@tapestry.apache.org>
Subject: Re: Is tapestry plastic incompatible with JEE specs?
Hi!
IWhy not having all T5 related jars in your war? Any particular reason why they
are located in your ear?
Jens
Von meinem iPhone gesendet
Am 11.12.2015 um 19:05 schrieb Luca Arzeni <l.arz...@iname.com>:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
