openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick" <michael.d.d...@gmail.com>
Subject Re: [jira] Updated: (OPENJPA-377) RuntimeUnenhancedClasses support can go into a "half baked" state
Date Wed, 30 Jul 2008 18:22:00 GMT
Hi Kevin,

The unenhanced class support does have some limitations but for some cases
it does work "out of the box". I'm not entirely comfortable with changing
the default behavior in a minor or patch release of OpenJPA. The release
conventions at http://openjpa.apache.org/openjpareleasepolicy.html say that
we'll try to keep minor and patch releases backwards compatible and making
this kind of change could cause a regression.

Chaning the default in the next major release is reasonable. If we haven't
resolved these issues by OpenJPA 2.0.0 I wouldn't object to changing the
default value.

For the next minor and patch releases of OpenJPA I think we should change
the message that we log when the unenhanced subclasses are used. Currently
it looks something like this :
1815  test-jse  INFO   [main] openjpa.Enhance - Creating subclass for
"[class foo.bar.jpa.entities.simple.Person]". This means that your
application will be less efficient and will consume more memory than it
would if you ran the OpenJPA enhancer. Additionally, lazy loading will not
be available for one-to-one and many-to-one persistent attributes in types
using field access; they will be loaded eagerly instead.

Due to the number of problems that have been reported with this function I'd
prefer to make the wording a bit sterner. Something along the lines of :
WARN - [main] openjpa.Enhance Automatic runtime enhancement has been used
for <class(es)>. This is done because the entity classes have not been
enhanced by the OpenJPA enahancer tool. This function is suitable for use in
a unit testing environment but is not recommended for use in production. See
the OpenJPA manual at <http://openjpa.apache.org/something> for more
information.

If existing applications are content with the limitations of automatic
subclassing then they can set the log level for Enhance to be FATAL or ERROR
(we might want to make that friendlier too).

How does that sound as a compromise?

-mike

On Wed, Jul 30, 2008 at 8:28 AM, Kevin Sutter <kwsutter@gmail.com> wrote:

> Seeing this movement of this Issue again get moved to the "next release", I
> wonder whether we should still have this "fallback enhancement" processing
> as the default.  Several other recent messages to the users and dev forums
> have asked the same question.  Within WebSphere, we turn this function off
> by disabling the openjpa.RuntimeUnenhancedClasses property.  But, for those
> customers that use OpenJPA straight from Apache, are they experiencing some
> of these problems and getting frustrated with the product?
>
> I know this is a tough call.  The concept of this feature was great -- to
> provide an easier, better "out of the box" experience for new users.  But,
> since these "edge" conditions are not properly detected and communicated,
> customers get frustrated and confused.  We have experienced this even with
> WebSphere customers that are experimenting with the "latest and greatest"
> versions from Apache OpenJPA.
>
> My proposal would be to turn off this feature until we can prove that it's
> ready for prime time.
>
> Kevin
>
> On Tue, Jul 29, 2008 at 2:13 PM, Michael Dick (JIRA) <jira@apache.org
> >wrote:
>
> >
> >     [
> >
> https://issues.apache.org/jira/browse/OPENJPA-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
> >
> > Michael Dick updated OPENJPA-377:
> > ---------------------------------
> >
> >    Fix Version/s:     (was: 1.2.0)
> >                   1.3.0
> >
> > Moving to next release
> >
> > > RuntimeUnenhancedClasses support can go into a "half baked" state
> > > -----------------------------------------------------------------
> > >
> > >                 Key: OPENJPA-377
> > >                 URL: https://issues.apache.org/jira/browse/OPENJPA-377
> > >             Project: OpenJPA
> > >          Issue Type: Bug
> > >          Components: kernel
> > >    Affects Versions: 1.0.0
> > >            Reporter: Kevin Sutter
> > >             Fix For: 1.0.4, 1.3.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>(Throwable.java:196)
> > >       at java.lang.RuntimeException.<init>(RuntimeException.java:43)
> > >       at
> > org.apache.openjpa.util.OpenJPAException.<init>(OpenJPAException.java:77)
> > >       at
> > org.apache.openjpa.util.OpenJPAException.<init>(OpenJPAException.java:70)
> > >       at
> > org.apache.openjpa.util.GeneralException.<init>(GeneralException.java:43)
> > >       at
> > org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2410)
> > >       at
> > org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2224)
> > >       at
> >
> org.apache.openjpa.kernel.DelegatingBroker.persist(DelegatingBroker.java:1005)
> > >       at
> >
> org.apache.openjpa.persistence.EntityManagerImpl.persist(EntityManagerImpl.java:541)
> > >            :
> > >            :
> > > Caused by: java.lang.ClassCastException: !(x instanceof Integer)
> > >       at java.lang.Throwable.<init>(Throwable.java:196)
> > >       at java.lang.RuntimeException.<init>(RuntimeException.java:43)
> > >       at
> java.lang.ClassCastException.<init>(ClassCastException.java:39)
> > >       at
> >
> org.apache.openjpa.util.ApplicationIds.fromPKValues(ApplicationIds.java:151)
> > >       at
> >
> org.apache.openjpa.enhance.ReflectingPersistenceCapable.pcNewObjectIdInstance(Ref
> > > lectingPersistenceCapable.java:257)
> > >       at
> > org.apache.openjpa.util.ApplicationIds.create(ApplicationIds.java:384)
> > >       at
> > org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2378)
> > >       ... 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.
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message