Granted, this makes it impossible to get up and running quickly, but we can guide the user with the error message explicitly saying something like
"To avoid havoc and trouble, please enhance your classes before running using the enhancer tool; enhance at runtime via the Java instrumentation; or run in a container. If you want to try running without enhanced classes, set the openjpa.RuntimeUnenhancedClasses property to "pray".
Craig On Jun 23, 2008, at 6:31 AM, Kevin Sutter wrote:
Michael, This "fallback enhancement" can be turned off by using theopenjpa.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 "fallbackenhancement" processing. Within the WebSphere environment, we actually set thisopenjpa.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 errormessages 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 classdetection. Thanks, Kevin On Mon, Jun 23, 2008 at 7:45 AM, Michael Vorburger < [EMAIL PROTECTED]> wrote:Hello, In my experience, that "fallback enhancement" mode (see http://openjpa.apache.org/docs/latest/manual/ref_guide_pc_enhance.html#ref_guide_pc_enhance_unenhanced_types)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 ofthis.)The fact that https://issues.apache.org/jira/browse/OPENJPA-293 is stillan Open New Feature, with five open sub-tasks (so technically thisdevelopment was never finished, yet it's automatically activated and showsup in the official doc) and in e.g.https://issues.apache.org/jira/browse/OPENJPA-444 (and may be others?) there are bug reports which are probably only due to this, may support mypoint 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 EJBcontainer which does enhancement)". How about some sort of OpenJPA configuration property for this? Forbackward compatibility, now that it's out, it probably has be remain ON bydefault (or can you make it OFF by default?), but at least give us aconfiguration option to switch this *#ç mode ;-) off! Shall I file a newJIRA Enhancement requesting this? Thanks, MichaelPS: 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: [EMAIL PROTECTED] ____________________________________________________________ • 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 materialwithin this email is strictly forbidden.• Any views or opinions presented within this e-mail are solely those ofthe 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 referringto 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.
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
