openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Sutter <kwsut...@gmail.com>
Subject Re: Can openjpa.RuntimeUnenhancedClasses=supported try harder to enhance when used within an app server?
Date Thu, 22 Dec 2011 23:52:34 GMT
Hi Ron,
The RuntimeUnenhancedClasses "feature" was an attempt to provide JPA ORM
capabilities without using bytecode enhancement techniques.  Instead,
dynamic subclasses were generated which attempted to provide the same level
of functionality.  This "feature" never got the necessary attention to make
it ready for prime time, so it was turned off by default in the OpenJPA
2.0.x timeframe.  WebSphere has been turning off this feature for even
longer than that.

Bottom line is not to worry about the lack of this RuntimeUnenhancedClasses
feature when using OpenJPA -- inside or outside of WebSphere.  You really
don't want to count on it, especially in production environments.  As you
found out, it does tend to work okay for very simple projects in a JSE
environment.  But, once you move to more complicated environments in JEE,
it falls on it's knees.

Instead, OpenJPA has always promoted the use of byte code enhancement of
Entity classes.  Not only is this functionally complete, the performance of
this approach is much better than attempting to subclass the solution.

A colleague of mine wrote an excellent blog post on the use of
Enhancement.  It's a couple of years ago, but it it still accurate and
pertinent:
http://webspherepersistence.blogspot.com/2009/02/openjpa-enhancement.html

Also, whether you byte code enhance at build time or at runtime via the
Container hook, the performance is the same.  The same bytecodes are
inserted or modified regardless of when the process takes place.  Letting
the container hook take care of the enhancement process is probably the
easiest since you don't have to modify your build process.  There is a
(very) slight delay when the Entity classes are first loaded in order to
allow for the byte code enhancement, but in most environments this is not
even noticeable.

I hope this helps with your understanding of OpenJPA's enhancement
processing.

Kevin

On Thu, Dec 22, 2011 at 4:34 PM, Ron Grabowski <rongrabowski@yahoo.com>wrote:

> I've just recently started using OpenJPA and from a new user perspective I
> interpreted "openjpa.RuntimeUnenhancedClasses=supported" to mean first
> check if the code is running within an app server and let the app server
> enhance the classes *then* fallback and actually do a runtime enhancement.
> It turns
> out "supported" may be better described as "true" in that it only makes
> one enhancement attempt then fails. I can successfully use "supported" when
> running my small JPA project not in an app server but when I put it on an
> app server I need to create my emf in a slightly different manner:
>
> if (isWebSphere()) {
>  Map<String, String> configOverrides = new HashMap<String, String>();
>  configOverrides.put("openjpa.RuntimeUnenhancedClasses",
> "unsupported");
>  entityManagerFactory =
> Persistence.createEntityManagerFactory(persistenceUnitName,
> configOverrides);
> } else {
>  entityManagerFactory =
> Persistence.createEntityManagerFactory(persistenceUnitName);
> }
>
> I wish "supported" tried harder before failing. I've glanced at
> OPENJPA-377 and OPENJPA-651. Maybe I'm approaching things incorrectly?
>
>
> Does enhancing my classes at build time in my Ant script give me the same
> outcome/performance as letting the app server enhance my classes?
>

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