[
https://issues.apache.org/jira/browse/OPENJPA-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797348#action_12797348
]
Mark Struberg commented on OPENJPA-1454:
----------------------------------------
Oki, the whole story:
I used openjpa-all-2.0.0-M3 on tomcat-6.0.20 (+Mojarra-2.0.1 + OpenWebBeans)
and my application crashed (It worked on jetty-6 which surprises me a bit).
I cannot remember seeing any 'Agent failed' or something while using the
openjpa-all. But I got funny ClassNotFoundException and NoClassDefFoundErrors.
Since our production system is tomcat, I needed to evaluate what's going on.
So I jumped over and built OpenJPA-2 from trunk and used the single jars. With
this setup, both tomcat and jetty crashed ;)
I then discovered the ClassLoading issue I posted to the list yesterday
(ObjectValue#newInstance - will create a Jira). After fixing that part it runs
on jetty again.
Today I digged deeper. Tomcats WebappClassLoader first tries to load the class
from the SystemClassLoader to prevent applications from overwriting SE classes,
and only if it gets a ClassNotFoundException it uses the war classpath. I then
found out that the SystemClassLoader has a few classes of the openjpa-kernel
registered (I remember the openjpa.util.Exceptions class). And caused by
mechanism in the WebappClassLoader, it tries to use the SystemClassLoader to
initialise the whole class tree. Here it epically fails while trying to load
classes which are e.g. in openjpa-lib or any other dependency which is not
available within the jar which got used to inject the Instrumentation. I
remember the J2DoHelper and with openjpa-all I think it was parts of the
validator-spec which crashed.
Since the Instrumentation happens in parallel, it was a huge pita to find out,
because the classes which have not been found changed from one server start to
the other ;)
I suspect that the app works with jetty because it doesn't do the SE classes
check...
> InstrumentationFactory crashes the tomcat WebappClassLoader by injecting
> org.apache.openjpa classes into the SystemClassLoader
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-1454
> URL: https://issues.apache.org/jira/browse/OPENJPA-1454
> Project: OpenJPA
> Issue Type: Bug
> Components: UnenhancedClasses
> Affects Versions: 2.0.0-M3
> Reporter: Mark Struberg
>
> The InstrumentationFactory tries to find the jar containing the manifest with
> the pre-main and attaches this jar to the VM.
> This has the side effect that all classes which get loaded via the
> Instrumentation are added to the 'classes' Vector of the SystemClassLoader.
> And this causes a problem when running OpenJPA in a WebApplication - because
> the SystemClassLoader only contains a few of those class definitions, and
> e.g. executing
> public void setBrokerFactory(BrokerFactory factory) {
> _factory = new DelegatingBrokerFactory(factory,
> PersistenceExceptions.TRANSLATOR);
> }
> crashes the WebApp because org.apache.openjpa.util.Exceptions is available in
> the SystemClassLoader but the dependent J2DoPrivHelper is not.
> This is even more problematic when using openjpa-lib, openjpa-kernel, etc as
> single jars (instead of openjpa-all), because in this case only
> openjpa-kernel gets injected into the VMs system classpath - causing the
> agent to subsequently crash because all the classes from openjpa-lib
> obviously cannot be found.
> This might also be an explanation to a few other open JIRAs I've read through
> the last few days.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
