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 <rongrabow...@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? >
