openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter (JIRA)" <>
Subject [jira] Commented: (OPENJPA-377) RuntimeUnenhancedClasses support can go into a "half baked" state
Date Wed, 19 Sep 2007 21:16:12 GMT


Kevin Sutter commented on OPENJPA-377:

>  However, in an appserver environment, why aren't you just doing deploy-time postprocessing
via the JPA contract APIs for contributing a ClassTransformer?

:-)  We are trying...  In one of our environments on iSeries, we hit a problem with the JVM
where the results of the ClassTransformer weren't always getting processed correctly.  Thus,
once in a while, the classes dropped into this RuntimeUnenhancedClasses support by accident.
 We are getting that problem resolved on iSeries.  But, since I have also experienced this
type of problem within the Eclipse environment, I thought I would post the problem to JIRA
so that we had it recorded.  Thanks for taking an initial look at the problem.

> RuntimeUnenhancedClasses support can go into a "half baked" state
> -----------------------------------------------------------------
>                 Key: OPENJPA-377
>                 URL:
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 1.0.0
>            Reporter: Kevin Sutter
>             Fix For: 1.0.1, 1.1.0
> As we continue to push OpenJPA through it's paces in an application server environment,
I've hit a problem with the new dynamic unenhanced classes support that I haven't been able
to figure out yet.  Maybe by writing this JIRA issue, it will ring a bell with Patrick or
one of the other developers.
> Here's an example of the callstack that we get.  In this case, the container classloader
transformer doesn't process the Entity for some reason.  (I realize that this the root cause
of the problems, but I don't think we fail like we do.)  Since the Entity has not been enhanced,
we fall into the dynamic unenhanced classes support.  We determine that we're persistence
capable, but something wasn't quite "baked" yet since we hit this exception:
> 	<openjpa-1.1.0-SNAPSHOT-r420667:573398M nonfatal general error> 
> org.apache.openjpa.persistence.PersistenceException: !(x instanceof Integer)
> [9/14/07 11:31:52:040 EST] 00000031 SystemOut     O 
> <openjpa-1.1.0-SNAPSHOT-r420667:573398M nonfatal general error> 
> org.apache.openjpa.persistence.PersistenceException: !(x instanceof Integer)
> 	at java.lang.Throwable.<init>(
> 	at java.lang.RuntimeException.<init>(
> 	at org.apache.openjpa.util.OpenJPAException.<init>(
> 	at org.apache.openjpa.util.OpenJPAException.<init>(
> 	at org.apache.openjpa.util.GeneralException.<init>(
> 	at org.apache.openjpa.kernel.BrokerImpl.persist(
> 	at org.apache.openjpa.kernel.BrokerImpl.persist(
> 	at org.apache.openjpa.kernel.DelegatingBroker.persist(
> 	at org.apache.openjpa.persistence.EntityManagerImpl.persist(
>            :
>            :
> Caused by: java.lang.ClassCastException: !(x instanceof Integer)
> 	at java.lang.Throwable.<init>(
> 	at java.lang.RuntimeException.<init>(
> 	at java.lang.ClassCastException.<init>(
> 	at org.apache.openjpa.util.ApplicationIds.fromPKValues(
> 	at org.apache.openjpa.enhance.ReflectingPersistenceCapable.pcNewObjectIdInstance(Ref
> 	at org.apache.openjpa.util.ApplicationIds.create(
> 	at org.apache.openjpa.kernel.BrokerImpl.persist(
> 	... 20 more
> (I also run across this same type of problem in a Java SE environment when running within
Eclipse.  But, at the time, I got around the problem by just running the PCEnhancer tool beforehand.
 And, since this was not the main problem I was driving, I forgot about it.  I'm just stating
this to indicate that this not just a Container classloader issue.)
> In both cases, it does seem like it's related to creating or using ApplicationIds.  But,
I haven't dug down deeper yet.
> On a related note, I have two other questions related to this scenario:
> o  When we are running in a Container environment, should the RuntimeUnenhancedClasses
support be turned off?  Since the Container is supposed to be intercepting these Entities
and passing them through the Transformer interface, should the RuntimeUnenhancedClasses support
be turned off so that we can more easily detect when this is not working as expected?
> o  I think the "unsupported" option for the openjpa.RuntimeUnenhancedClasses property
is hiding a more meaningful message.  For example, if I run with "warn" option, I get the
warning message (runtime-optimization-disabled) and a null is returned.  In this scenario,
the processing continues and then I get this message:
> <openjpa-1.1.0-SNAPSHOT-r420667:573398M nonfatal user error> 
> org.apache.openjpa.persistence.ArgumentException: Attempt to cast instance "..." to 
> PersistenceCapable failed.  Ensure that it has been enhanced.
> But, if I run with the "unsupported" option, then the only message I get is the (runtime-optimization-disabled)
exception.  Although it still indicates an error exists, it's not as clear as the "PersistenceCapable"
message.  Not sure if we should re-think the "warn" vs "unsupported" argument, or maybe just
an update to the message text for (runtime-optimization-disabled).
> Anyway, the main problem is the ClassCastException.
> Thanks,
> Kevin

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message