[
https://issues.apache.org/jira/browse/OPENJPA-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Sutter updated OPENJPA-646:
---------------------------------
Attachment: openjpa-646.patch
This hack of a patch just modifies our TempClassLoader implementation to treat
enum class types like annotation class types and use the Class.forName()
mechanism to load the class instead of the defineClass() mechanism. Until I
get educated on what exactly is wrong with our current processing, I don't want
to commit this change. But, in case someone runs into this situation, this is
a potential workaround.
> 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.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.
