[
https://issues.apache.org/jira/browse/OPENJPA-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618892#action_12618892
]
Kevin Sutter commented on OPENJPA-646:
--------------------------------------
I accidentally opened a new Issue for this same problem (OPENJPA-672). Just to
get this Issue up to date, here are some of the details from that new Issue:
>From working with the JDK team, the problem is surfacing because the
>ClassLoader (AppClassLoader) that is used to load the Enum type when the
>alt.persistence.OneToMany is loaded is not the same ClassLoader
>(TemporaryClassLoader) when the Enum type is loaded by our enhancement
>processing. Thus, the AnnotationTypeMismatchExceptionProxy from the JDK.
One way to workaround the problem is to add a test for Enum types in the
TemporaryClassLoader and use the AppClassLoader in this case (much like we do
for Annotation types):
if (isAnnotation(classBytes) || isEnum(classBytes))
return Class.forName(name, resolve, getClass().getClassLoader());
The JDK team suggested removing the check for isAnnotation (and isEnum)
altogether since that resolved the simple testcase that I had put together for
their benefit. Unfortunately, that doesn't work for our enhancement processing
for a couple of reasons. The _strats structure in PersistentMetaDataDefaults
depended on the org.apache.openjpa.persistence.PersistentCollection class. By
removing the conditional above, then we had a mismatch in classloaders for this
data structure, much like the jdk problem.
I tried changing the key for this _strats structure to use the class name
string instead of the actual class instance. This got us around our immediate
concern, but eventually I hit another JDK issue with mismatched classloaders
when processing the annotations in AnnotationPersistentMetaDataParser:
parsePersistentCollection(fmd, (PersistentCollection)
el.getAnnotation(PersistentCollection.class));
The loading of this PersistentCollection.class used the AppClassLoader, so the
lookup via getAnnotation didn't find anything since the original annotation was
loaded by the TemporaryClassLoader. Trying to get around this situation was
creating some pretty ugly code.
So, I am leaning towards the original workaround as a "solution" with proper
commenting. By allowing the AppClassLoader to load enum types (vs the
TemporaryClassLoader), we would "pollute" the AppClassLoader with left over
enum classes. This would seem to be a minor drawback. Of course, if we ever
need to allow for the enhancement of enum classes, then we're up a creek...
Enough detail for now. Comments and suggestions are welcome.
> JDK problems with defineClass and enum class types
> --------------------------------------------------
>
> Key: OPENJPA-646
> URL: https://issues.apache.org/jira/browse/OPENJPA-646
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 1.2.0
> Reporter: Kevin Sutter
> Assignee: Kevin Sutter
> Fix For: 1.2.1, 1.3.0
>
> Attachments: openjpa-646.patch, pmr.zip
>
>
> This Issue was first presented on our dev mailing list:
> http://www.nabble.com/Sun-JDK-problem-with-duplicate-annotations-td18101863.html
> I have also shared some additional experiences with Abe to get his views, but
> haven't heard anything back yet. So, I will create this JIRA Issue and work
> it from there.
> The original problem was limited to the Sun JDK. But, in a
> soon-to-be-available update to the IBM JDK, the same problem surfaces. At
> least the same exception is presented. The actual call stack is different
> due to the different Sun and IBM packages, but it's a similar problem.
> Basically, we are having a problem with our TempClassLoader attempting to use
> the defineClass() method on the CascadeType enum class. Our
> javax.persistence.CascadeType version doesn't experience this problem because
> we use Class.forName() to load the javax classes. In this scenario, I have
> an alt.persistence.CascadeType that falls into our normal class definition
> processing and attempts to use defineClass(). This method invocation
> completes okay. But, later when our code attempts to access the metadata
> associated with this type, we get the ArrayStoreException from the JDK.
> I will post both a simple project that reproduces the problem as well as a
> "hack" patch that gets us around the problem. I also have a PMR opened
> against the IBM JDK to see if they can help resolve it.
> Kevin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
