RE: Disable dangerous fallback enhancement how?
This openjpa.RuntimeUnenhancedClasses=unsupported is GREAT! Saves A LOT of confusion. Thanks a ton, Kevin. IMHO the 'unsupported' is better/clearer than the 'warn'; I tried both. I noticed this isn't actually documented? ;) Created a bug report https://issues.apache.org/jira/browse/OPENJPA-650, just for the doc. Craig, all, so what to do to propose this for inclusion in the Standard? I've taken the liberty of entering an enhancement JIRA for this, see: https://issues.apache.org/jira/browse/OPENJPA-651 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: lundi, 23. juin 2008 21:33 To: users@openjpa.apache.org Subject: Re: Disable dangerous fallback enhancement how? Since the feature is incomplete, I think we should consider defaulting the property to unsupported. 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 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 detection. 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.htm l#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 of this.) The fact that https://issues.apache.org/jira/browse/OPENJPA-293 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. 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 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: [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 material within this email is strictly forbidden. * Any views
Disable dangerous fallback enhancement how?
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 of this.) The fact that https://issues.apache.org/jira/browse/OPENJPA-293 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. 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 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: [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 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.
Re: Disable dangerous fallback enhancement how?
Michael, 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 detection. 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 of this.) The fact that https://issues.apache.org/jira/browse/OPENJPA-293 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. 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 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: [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 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.
Re: Disable dangerous fallback enhancement how?
Since the feature is incomplete, I think we should consider defaulting the property to unsupported. 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 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 detection. 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 of this.) The fact that https://issues.apache.org/jira/browse/OPENJPA-293 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. 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 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: [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 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. 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
