openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <>
Subject Fwd: Disable dangerous "fallback enhancement" how?
Date Mon, 23 Jun 2008 13:32:30 GMT
Oops, forgot to reply to both groups...

---------- Forwarded message ----------
From: Kevin Sutter <>
Date: Mon, Jun 23, 2008 at 8:31 AM
Subject: Re: Disable dangerous "fallback enhancement" how?

This "fallback enhancement" can be turned off by using the
openjpa.RuntimeUnenhancedClasses property set to "unsupported".  If your
build processing fails to enhance your Entity classes, or your -javaagent
isn't properly set up, or you are not running in a Container environment
(essentially any of the "normal" enhancement processes), then having this
property set will cause an error message and not fall into the "fallback
enhancement" processing.

Within the WebSphere environment, we actually set this
openjpa.RuntimeUnenhancedClasses property to "warn".  This has the same net
effect as "unsupported" -- that is, it does not allow you to fall into the
"fallback enhancement" processing.  But, it produces a couple of extra error
messages that might help with debugging your situation.

The "unsupported" option stops immediately.  The "warn" option allows you to
run a bit further, but you will eventually stop due to an unenhanced class


On Mon, Jun 23, 2008 at 7:45 AM, Michael Vorburger <> wrote:

> Hello,
> In my experience, that "fallback enhancement" mode (see
> causes much more havoc and trouble and confusion than that it's of any use.
> (I'm not just ranting, but saying this based on experience with people
> starting to adopt an OpenJPA-based piece in-house here - more than once,
> problems like "but it does way to many too much DB access!" are because of
> this.)
> The fact that is still
> an Open New Feature, with five open sub-tasks (so technically this
> development was never finished, yet it's automatically activated and shows
> up in the official doc) and in e.g.
> (and may be others?)
> there are bug reports which are probably only due to this, may support my
> point of view?
> It would much rather that if Entities are not enhanced at build time (which
> we do, through Maven; but sometimes a developers has Eclipse overwriting)
> and the Agent (which developers are encouraged to do when developing locally
> e.g. in JUnit Test for rapid cycles) is not in use, that instead of going to
> that "fallback enhancement" mode, it would abort and say "Use the build-time
> Enhancer or specify the Agent to Enhance at Run-Time (or deploy into a EJB
> container which does enhancement)".
> How about some sort of OpenJPA configuration property for this? For
> backward compatibility, now that it's out, it probably has be remain ON by
> default (or can you make it OFF by default?), but at least give us a
> configuration option to switch this *#ç mode ;-) off! Shall I file a new
> JIRA Enhancement requesting this?
> Thanks,
> Michael
> PS: In the short term, I may make our own OpenJPA wrapper/helper stuff to
> abort... it should be relatively easy to check at start-up if some class
> implements org.apache.openjpa.enhance.PersistenceCapable (by the Enhancer),
> but how could I check if, alternatively, the Agent is actively running?
> _____________________________
> Michael Vorburger, Odyssey Financial Technologies
> Direct phone:  +41 21 310 00 86 (OAMS VOIP: 1086)
> Cell phone: +41 78 805 5541
> Mailto:
> ____________________________________________________________
> • This email and any files transmitted with it are CONFIDENTIAL and
> intended
>  solely for the use of the individual or entity to which they are
> addressed.
> • Any unauthorized copying, disclosure, or distribution of the material
> within
>  this email is strictly forbidden.
> • Any views or opinions presented within this e-mail are solely those of
> the
>  author and do not necessarily represent those of Odyssey Financial
> Technologies SA unless otherwise specifically stated.
> • An electronic message is not binding on its sender. Any message referring
> to
>  a binding engagement must be confirmed in writing and duly signed.
> • If you have received this email in error, please notify the sender
> immediately
>  and delete the original.

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