You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Kevin Sutter <kw...@gmail.com> on 2008/12/05 01:25:51 UTC
[VOTE] Turn off enhancement by subclassing as the default
Hi,
This is a tough decision, but one that I think we need to make. If you have
been following the dev mailing list, there have been several discussions [1]
and JIRA Issues [2] about the fallback enhancement by subclassing that we
put in place back in the 1.0.0 timeframe. Although we succeeded in making
the initial out-of-box experience easier for the newbie OpenJPA developer,
we also masked the need for true enhancement for production usage. So,
unless we deem that this subclassing enhancement is critical to OpenJPA's
acceptance and usage, I propose to turn this option off by default. The
ability to do this subclass enhancement will still be available via the
openjpa.RuntimeUnenhancedClasses property, but the default will now be
either "warn" or "unsupported" instead of "supported". I would like to do
this for trunk for sure and possibly the 1.3.x branch as well. Please vote
accordingly. Thanks for your input. Write-in comments are also welcome.
[ +1 | 0 | -1 ] Turn off subclass enhancement in trunk
[ +1 | 0 | -1 ] Turn off subclass enhancement in 1.3.x
I am not proposing to turn it off in the other branches since those are not
active development streams, but rather service streams. We shouldn't
introduce a change like this into a customer's service stream. That is, for
a customer to get 1.0.4 with this option turned off would be a surprise
since they would only be expecting fixes. Fine line in this case, but you
get the picture.
Thanks,
Kevin
[1]
http://n2.nabble.com/Re%3A-Foreign-key-field-doesn%27t-get-populated-in-descendant-class-in-Join-Inheritance-td1574111.html#a1574493
[2] http://issues.apache.org/jira/browse/OPENJPA-651,
http://issues.apache.org/jira/browse/OPENJPA-650,
https://issues.apache.org/jira/browse/OPENJPA-293
Re: [VOTE] Turn off enhancement by subclassing as the default
Posted by Jeremy Bauer <te...@gmail.com>.
+1 Turn off subclass enhancement in trunk
0 Turn off subclass enhancement in 1.3.x
Since the 1.3.x stream has been available for some time, 2.0/trunk seems
like a better place to change default behavior. But, I don't feel strongly
enough about it to oppose. :-)
-Jeremy
On Thu, Dec 4, 2008 at 6:25 PM, Kevin Sutter <kw...@gmail.com> wrote:
> Hi,
> This is a tough decision, but one that I think we need to make. If you
> have
> been following the dev mailing list, there have been several discussions
> [1]
> and JIRA Issues [2] about the fallback enhancement by subclassing that we
> put in place back in the 1.0.0 timeframe. Although we succeeded in making
> the initial out-of-box experience easier for the newbie OpenJPA developer,
> we also masked the need for true enhancement for production usage. So,
> unless we deem that this subclassing enhancement is critical to OpenJPA's
> acceptance and usage, I propose to turn this option off by default. The
> ability to do this subclass enhancement will still be available via the
> openjpa.RuntimeUnenhancedClasses property, but the default will now be
> either "warn" or "unsupported" instead of "supported". I would like to do
> this for trunk for sure and possibly the 1.3.x branch as well. Please vote
> accordingly. Thanks for your input. Write-in comments are also welcome.
>
> [ +1 | 0 | -1 ] Turn off subclass enhancement in trunk
> [ +1 | 0 | -1 ] Turn off subclass enhancement in 1.3.x
>
> I am not proposing to turn it off in the other branches since those are not
> active development streams, but rather service streams. We shouldn't
> introduce a change like this into a customer's service stream. That is,
> for
> a customer to get 1.0.4 with this option turned off would be a surprise
> since they would only be expecting fixes. Fine line in this case, but you
> get the picture.
>
> Thanks,
> Kevin
>
> [1]
>
> http://n2.nabble.com/Re%3A-Foreign-key-field-doesn%27t-get-populated-in-descendant-class-in-Join-Inheritance-td1574111.html#a1574493
> [2] http://issues.apache.org/jira/browse/OPENJPA-651,
> http://issues.apache.org/jira/browse/OPENJPA-650,
> https://issues.apache.org/jira/browse/OPENJPA-293
>
Re: [VOTE] Turn off enhancement by subclassing as the default
Posted by Rick Curtis <cu...@gmail.com>.
+1 Turn off subclass enhancement in trunk
+1 Turn off subclass enhancement in 1.3.x
-Rick
--
View this message in context: http://n2.nabble.com/-VOTE--Turn-off-enhancement-by-subclassing-as-the-default-tp1616140p2947145.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.
Re: [VOTE] Turn off enhancement by subclassing as the default
Posted by Donald Woods <dw...@apache.org>.
+1 to turn of subclassing in trunk AND 1.3.x
-Donald
Michael Dick wrote:
> Resurrecting this old thread, since there seems to be some activity in the
> associated JIRA issue [1]
>
> The results were :
>
> Turn off subclassing in trunk :
> +1 Jeremy, Albert, me
> +0 No one
> -1 No one
>
> Total +3
>
> Turn off subclassing in 1.3.x :
> +1 Me
> +0 Jeremy
> -1 Albert
>
> Total +0
>
> Any other votes that I've missed? Based on the "current" results we should
> disable subclassing in trunk, 1.3.x is still under discussion..
>
> [1] https://issues.apache.org/jira/browse/OPENJPA-651
>
> -mike
>
> On Tue, Dec 16, 2008 at 5:32 PM, Dianne Richards <di...@gmail.com> wrote:
>
>> All - I've been looking into the Sun 1.6 registration of a transformer as
>> mentioned by Patrick and here are the results:
>>
>> 1. The InstrumentationFactory does a
>> Class.forName("com.sun.tools.attach.VirtualMachine") and uses the attach
>> method of that class to load the agent.
>>
>> 2. When I ran it, the initial code in InstrumentationFactory worked. But,
>> when I turned off support for RuntimeUnenhancedClasses, it failed later on
>> in the process. The only thing my test case is doing is creating an
>> EntityManagerFactory and an EntityManager. I'm assuming there are some
>> later
>> checks that can be enhanced to allow this to work, but I haven't gone that
>> far yet.
>>
>> 3. HOWEVER, the VirtualMachine class is not in the default classpath. It's
>> in the lib/tools.jar, which I had to manually add to the classpath in order
>> to get this far. So, this is not an out-of-the-box solution.
>>
>> 4. I also tried this with the IBM jdk 6, since the tools.jar with this
>> class
>> is also shipped with it. When it tried to attach, I got an
>> AttachNotSupportedException with the message "Unable to enqueue operation,
>> pre-6.0 jvm.dll?" This doesn't sound too promising.
>>
>> On Tue, Dec 9, 2008 at 9:55 AM, Patrick Linskey <pl...@gmail.com>
>> wrote:
>>
>>> Excellent question. To be honest, I didn't know that we ended up with
>>>> different "subclassing" behavior when using a 1.5 JVM vs a 1.6 JVM.
>>>>
>>> In Sun-ish 1.6 VMs, we can automatically register a class transformer on
>>> the fly (see InstrumentationFactory). I don't remember all the subtleties
>> of
>>> the configuration and the implications on what we can do, but there are
>>> definitely differences in the pathways, as we can directly mutate code
>>> blocks in 1.6 environments (but maybe we can't add fields and methods?).
>>>
>>> Has anybody spent any cycles on that approach?
>>> I haven't investigated one way or the other. I believe that there's a
>> table
>>> somewhere in the docs that spells out the differences between the various
>>> approaches.
>>>
>>> -Patrick
>>>
>>>
>>> On Dec 9, 2008, at 7:19 AM, Kevin Sutter wrote:
>>>
>>> Hi Patrick,
>>>> On Tue, Dec 9, 2008 at 1:11 AM, Patrick Linskey <pl...@gmail.com>
>>>> wrote:
>>>>
>>>> What is the impact of your proposal on people who are using Sun-ish 1.6
>>>>> VMs, which have on-the-fly class redefinition support?
>>>>>
>>>>> Put another way, to what extent have you considered the differences in
>>>>> flakiness between the 1.5-friendly subclassing approach and the
>>>>> 1.6-needing
>>>>> redefinition approach?
>>>>>
>>>>>
>>>> Excellent question. To be honest, I didn't know that we ended up with
>>>> different "subclassing" behavior when using a 1.5 JVM vs a 1.6 JVM. I
>>>> thought the reported problems were equally applied to both JVM versions.
>>>> Do
>>>> we know that the 1.6 redefinition capabilities avoid the reported
>>>> problems?
>>>> Has anybody spent any cycles on that approach?
>>>>
>>>> Maybe something to think about is to turn off the subclassing support
>> for
>>>> the 1.5 JVM and leave the class redefinition support on for the 1.6 JVM?
>>>> I
>>>> really don't know enough about these alternate approaches to make that
>>>> kind
>>>> of statement at this point.
>>>>
>>>> Other thoughts?
>>>>
>>>> Thanks,
>>>> Kevin
>>>>
>>>>
>>>> -Patrick
>>>>> On Dec 4, 2008, at 4:25 PM, Kevin Sutter wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>> This is a tough decision, but one that I think we need to make. If
>> you
>>>>>> have
>>>>>> been following the dev mailing list, there have been several
>> discussions
>>>>>> [1]
>>>>>> and JIRA Issues [2] about the fallback enhancement by subclassing that
>>>>>> we
>>>>>> put in place back in the 1.0.0 timeframe. Although we succeeded in
>>>>>> making
>>>>>> the initial out-of-box experience easier for the newbie OpenJPA
>>>>>> developer,
>>>>>> we also masked the need for true enhancement for production usage.
>> So,
>>>>>> unless we deem that this subclassing enhancement is critical to
>>>>>> OpenJPA's
>>>>>> acceptance and usage, I propose to turn this option off by default.
>> The
>>>>>> ability to do this subclass enhancement will still be available via
>> the
>>>>>> openjpa.RuntimeUnenhancedClasses property, but the default will now be
>>>>>> either "warn" or "unsupported" instead of "supported". I would like
>> to
>>>>>> do
>>>>>> this for trunk for sure and possibly the 1.3.x branch as well. Please
>>>>>> vote
>>>>>> accordingly. Thanks for your input. Write-in comments are also
>>>>>> welcome.
>>>>>>
>>>>>> [ +1 | 0 | -1 ] Turn off subclass enhancement in trunk
>>>>>> [ +1 | 0 | -1 ] Turn off subclass enhancement in 1.3.x
>>>>>>
>>>>>> I am not proposing to turn it off in the other branches since those
>> are
>>>>>> not
>>>>>> active development streams, but rather service streams. We shouldn't
>>>>>> introduce a change like this into a customer's service stream. That
>> is,
>>>>>> for
>>>>>> a customer to get 1.0.4 with this option turned off would be a
>> surprise
>>>>>> since they would only be expecting fixes. Fine line in this case, but
>>>>>> you
>>>>>> get the picture.
>>>>>>
>>>>>> Thanks,
>>>>>> Kevin
>>>>>>
>>>>>> [1]
>>>>>>
>>>>>>
>>>>>>
>> http://n2.nabble.com/Re%3A-Foreign-key-field-doesn%27t-get-populated-in-descendant-class-in-Join-Inheritance-td1574111.html#a1574493
>>>>>> [2] http://issues.apache.org/jira/browse/OPENJPA-651,
>>>>>> http://issues.apache.org/jira/browse/OPENJPA-650,
>>>>>> https://issues.apache.org/jira/browse/OPENJPA-293
>>>>>>
>>>>>>
>>>>> --
>>>>> Patrick Linskey
>>>>> 202 669 5907
>>>>>
>>>>>
>>>>>
>>> --
>>> Patrick Linskey
>>> 202 669 5907
>>>
>>>
>>
>> --
>> Thanks - Dianne
>>
>
Re: [VOTE] Turn off enhancement by subclassing as the default
Posted by Michael Dick <mi...@gmail.com>.
Resurrecting this old thread, since there seems to be some activity in the
associated JIRA issue [1]
The results were :
Turn off subclassing in trunk :
+1 Jeremy, Albert, me
+0 No one
-1 No one
Total +3
Turn off subclassing in 1.3.x :
+1 Me
+0 Jeremy
-1 Albert
Total +0
Any other votes that I've missed? Based on the "current" results we should
disable subclassing in trunk, 1.3.x is still under discussion..
[1] https://issues.apache.org/jira/browse/OPENJPA-651
-mike
On Tue, Dec 16, 2008 at 5:32 PM, Dianne Richards <di...@gmail.com> wrote:
> All - I've been looking into the Sun 1.6 registration of a transformer as
> mentioned by Patrick and here are the results:
>
> 1. The InstrumentationFactory does a
> Class.forName("com.sun.tools.attach.VirtualMachine") and uses the attach
> method of that class to load the agent.
>
> 2. When I ran it, the initial code in InstrumentationFactory worked. But,
> when I turned off support for RuntimeUnenhancedClasses, it failed later on
> in the process. The only thing my test case is doing is creating an
> EntityManagerFactory and an EntityManager. I'm assuming there are some
> later
> checks that can be enhanced to allow this to work, but I haven't gone that
> far yet.
>
> 3. HOWEVER, the VirtualMachine class is not in the default classpath. It's
> in the lib/tools.jar, which I had to manually add to the classpath in order
> to get this far. So, this is not an out-of-the-box solution.
>
> 4. I also tried this with the IBM jdk 6, since the tools.jar with this
> class
> is also shipped with it. When it tried to attach, I got an
> AttachNotSupportedException with the message "Unable to enqueue operation,
> pre-6.0 jvm.dll?" This doesn't sound too promising.
>
> On Tue, Dec 9, 2008 at 9:55 AM, Patrick Linskey <pl...@gmail.com>
> wrote:
>
> > Excellent question. To be honest, I didn't know that we ended up with
> >> different "subclassing" behavior when using a 1.5 JVM vs a 1.6 JVM.
> >>
> >
> > In Sun-ish 1.6 VMs, we can automatically register a class transformer on
> > the fly (see InstrumentationFactory). I don't remember all the subtleties
> of
> > the configuration and the implications on what we can do, but there are
> > definitely differences in the pathways, as we can directly mutate code
> > blocks in 1.6 environments (but maybe we can't add fields and methods?).
> >
> > Has anybody spent any cycles on that approach?
> >>
> >
> > I haven't investigated one way or the other. I believe that there's a
> table
> > somewhere in the docs that spells out the differences between the various
> > approaches.
> >
> > -Patrick
> >
> >
> > On Dec 9, 2008, at 7:19 AM, Kevin Sutter wrote:
> >
> > Hi Patrick,
> >>
> >> On Tue, Dec 9, 2008 at 1:11 AM, Patrick Linskey <pl...@gmail.com>
> >> wrote:
> >>
> >> What is the impact of your proposal on people who are using Sun-ish 1.6
> >>> VMs, which have on-the-fly class redefinition support?
> >>>
> >>> Put another way, to what extent have you considered the differences in
> >>> flakiness between the 1.5-friendly subclassing approach and the
> >>> 1.6-needing
> >>> redefinition approach?
> >>>
> >>>
> >> Excellent question. To be honest, I didn't know that we ended up with
> >> different "subclassing" behavior when using a 1.5 JVM vs a 1.6 JVM. I
> >> thought the reported problems were equally applied to both JVM versions.
> >> Do
> >> we know that the 1.6 redefinition capabilities avoid the reported
> >> problems?
> >> Has anybody spent any cycles on that approach?
> >>
> >> Maybe something to think about is to turn off the subclassing support
> for
> >> the 1.5 JVM and leave the class redefinition support on for the 1.6 JVM?
> >> I
> >> really don't know enough about these alternate approaches to make that
> >> kind
> >> of statement at this point.
> >>
> >> Other thoughts?
> >>
> >> Thanks,
> >> Kevin
> >>
> >>
> >> -Patrick
> >>>
> >>> On Dec 4, 2008, at 4:25 PM, Kevin Sutter wrote:
> >>>
> >>> Hi,
> >>>
> >>>> This is a tough decision, but one that I think we need to make. If
> you
> >>>> have
> >>>> been following the dev mailing list, there have been several
> discussions
> >>>> [1]
> >>>> and JIRA Issues [2] about the fallback enhancement by subclassing that
> >>>> we
> >>>> put in place back in the 1.0.0 timeframe. Although we succeeded in
> >>>> making
> >>>> the initial out-of-box experience easier for the newbie OpenJPA
> >>>> developer,
> >>>> we also masked the need for true enhancement for production usage.
> So,
> >>>> unless we deem that this subclassing enhancement is critical to
> >>>> OpenJPA's
> >>>> acceptance and usage, I propose to turn this option off by default.
> The
> >>>> ability to do this subclass enhancement will still be available via
> the
> >>>> openjpa.RuntimeUnenhancedClasses property, but the default will now be
> >>>> either "warn" or "unsupported" instead of "supported". I would like
> to
> >>>> do
> >>>> this for trunk for sure and possibly the 1.3.x branch as well. Please
> >>>> vote
> >>>> accordingly. Thanks for your input. Write-in comments are also
> >>>> welcome.
> >>>>
> >>>> [ +1 | 0 | -1 ] Turn off subclass enhancement in trunk
> >>>> [ +1 | 0 | -1 ] Turn off subclass enhancement in 1.3.x
> >>>>
> >>>> I am not proposing to turn it off in the other branches since those
> are
> >>>> not
> >>>> active development streams, but rather service streams. We shouldn't
> >>>> introduce a change like this into a customer's service stream. That
> is,
> >>>> for
> >>>> a customer to get 1.0.4 with this option turned off would be a
> surprise
> >>>> since they would only be expecting fixes. Fine line in this case, but
> >>>> you
> >>>> get the picture.
> >>>>
> >>>> Thanks,
> >>>> Kevin
> >>>>
> >>>> [1]
> >>>>
> >>>>
> >>>>
> http://n2.nabble.com/Re%3A-Foreign-key-field-doesn%27t-get-populated-in-descendant-class-in-Join-Inheritance-td1574111.html#a1574493
> >>>> [2] http://issues.apache.org/jira/browse/OPENJPA-651,
> >>>> http://issues.apache.org/jira/browse/OPENJPA-650,
> >>>> https://issues.apache.org/jira/browse/OPENJPA-293
> >>>>
> >>>>
> >>> --
> >>> Patrick Linskey
> >>> 202 669 5907
> >>>
> >>>
> >>>
> > --
> > Patrick Linskey
> > 202 669 5907
> >
> >
>
>
> --
> Thanks - Dianne
>
Re: [VOTE] Turn off enhancement by subclassing as the default
Posted by Michael Dick <mi...@gmail.com>.
At this time the IBM SDK doesn't provide the attach API (Rick has done some
work in this area) which explains why it never worked with an IBM SDK.
Regarding class redefinition itself I think we'll run into some restrictions
there as well. From the javadoc [1] :
"The redefinition may change method bodies, the constant pool and
attributes. The redefinition must not add, remove or rename fields or
methods, change the signatures of methods, or change inheritance. These
restrictions maybe be lifted in future versions. The class file bytes are
not checked, verified and installed until after the transformations have
been applied, if the resultant bytes are in error this method will throw an
exception. "
[1]
http://java.sun.com/javase/6/docs/api/java/lang/instrument/Instrumentation.html#redefineClasses(java.lang.instrument.ClassDefinition...)
The enhancer currently adds new methods pcXYZ(), so until (unless?) this
restriction is lifted I think we'll need to use agent based enhancement.
-mike
Dianne Richards wrote:
>
> All - I've been looking into the Sun 1.6 registration of a transformer as
> mentioned by Patrick and here are the results:
>
> 1. The InstrumentationFactory does a
> Class.forName("com.sun.tools.attach.VirtualMachine") and uses the attach
> method of that class to load the agent.
>
> 2. When I ran it, the initial code in InstrumentationFactory worked. But,
> when I turned off support for RuntimeUnenhancedClasses, it failed later on
> in the process. The only thing my test case is doing is creating an
> EntityManagerFactory and an EntityManager. I'm assuming there are some
> later
> checks that can be enhanced to allow this to work, but I haven't gone that
> far yet.
>
> 3. HOWEVER, the VirtualMachine class is not in the default classpath. It's
> in the lib/tools.jar, which I had to manually add to the classpath in
> order
> to get this far. So, this is not an out-of-the-box solution.
>
> 4. I also tried this with the IBM jdk 6, since the tools.jar with this
> class
> is also shipped with it. When it tried to attach, I got an
> AttachNotSupportedException with the message "Unable to enqueue operation,
> pre-6.0 jvm.dll?" This doesn't sound too promising.
>
> On Tue, Dec 9, 2008 at 9:55 AM, Patrick Linskey <pl...@gmail.com>
> wrote:
>
>> Excellent question. To be honest, I didn't know that we ended up with
>>> different "subclassing" behavior when using a 1.5 JVM vs a 1.6 JVM.
>>>
>>
>> In Sun-ish 1.6 VMs, we can automatically register a class transformer on
>> the fly (see InstrumentationFactory). I don't remember all the subtleties
>> of
>> the configuration and the implications on what we can do, but there are
>> definitely differences in the pathways, as we can directly mutate code
>> blocks in 1.6 environments (but maybe we can't add fields and methods?).
>>
>> Has anybody spent any cycles on that approach?
>>>
>>
>> I haven't investigated one way or the other. I believe that there's a
>> table
>> somewhere in the docs that spells out the differences between the various
>> approaches.
>>
>> -Patrick
>>
>>
>> On Dec 9, 2008, at 7:19 AM, Kevin Sutter wrote:
>>
>> Hi Patrick,
>>>
>>> On Tue, Dec 9, 2008 at 1:11 AM, Patrick Linskey <pl...@gmail.com>
>>> wrote:
>>>
>>> What is the impact of your proposal on people who are using Sun-ish 1.6
>>>> VMs, which have on-the-fly class redefinition support?
>>>>
>>>> Put another way, to what extent have you considered the differences in
>>>> flakiness between the 1.5-friendly subclassing approach and the
>>>> 1.6-needing
>>>> redefinition approach?
>>>>
>>>>
>>> Excellent question. To be honest, I didn't know that we ended up with
>>> different "subclassing" behavior when using a 1.5 JVM vs a 1.6 JVM. I
>>> thought the reported problems were equally applied to both JVM versions.
>>> Do
>>> we know that the 1.6 redefinition capabilities avoid the reported
>>> problems?
>>> Has anybody spent any cycles on that approach?
>>>
>>> Maybe something to think about is to turn off the subclassing support
>>> for
>>> the 1.5 JVM and leave the class redefinition support on for the 1.6 JVM?
>>> I
>>> really don't know enough about these alternate approaches to make that
>>> kind
>>> of statement at this point.
>>>
>>> Other thoughts?
>>>
>>> Thanks,
>>> Kevin
>>>
>>>
>>> -Patrick
>>>>
>>>> On Dec 4, 2008, at 4:25 PM, Kevin Sutter wrote:
>>>>
>>>> Hi,
>>>>
>>>>> This is a tough decision, but one that I think we need to make. If
>>>>> you
>>>>> have
>>>>> been following the dev mailing list, there have been several
>>>>> discussions
>>>>> [1]
>>>>> and JIRA Issues [2] about the fallback enhancement by subclassing that
>>>>> we
>>>>> put in place back in the 1.0.0 timeframe. Although we succeeded in
>>>>> making
>>>>> the initial out-of-box experience easier for the newbie OpenJPA
>>>>> developer,
>>>>> we also masked the need for true enhancement for production usage.
>>>>> So,
>>>>> unless we deem that this subclassing enhancement is critical to
>>>>> OpenJPA's
>>>>> acceptance and usage, I propose to turn this option off by default.
>>>>> The
>>>>> ability to do this subclass enhancement will still be available via
>>>>> the
>>>>> openjpa.RuntimeUnenhancedClasses property, but the default will now be
>>>>> either "warn" or "unsupported" instead of "supported". I would like
>>>>> to
>>>>> do
>>>>> this for trunk for sure and possibly the 1.3.x branch as well. Please
>>>>> vote
>>>>> accordingly. Thanks for your input. Write-in comments are also
>>>>> welcome.
>>>>>
>>>>> [ +1 | 0 | -1 ] Turn off subclass enhancement in trunk
>>>>> [ +1 | 0 | -1 ] Turn off subclass enhancement in 1.3.x
>>>>>
>>>>> I am not proposing to turn it off in the other branches since those
>>>>> are
>>>>> not
>>>>> active development streams, but rather service streams. We shouldn't
>>>>> introduce a change like this into a customer's service stream. That
>>>>> is,
>>>>> for
>>>>> a customer to get 1.0.4 with this option turned off would be a
>>>>> surprise
>>>>> since they would only be expecting fixes. Fine line in this case, but
>>>>> you
>>>>> get the picture.
>>>>>
>>>>> Thanks,
>>>>> Kevin
>>>>>
>>>>> [1]
>>>>>
>>>>>
>>>>> http://n2.nabble.com/Re%3A-Foreign-key-field-doesn%27t-get-populated-in-descendant-class-in-Join-Inheritance-td1574111.html#a1574493
>>>>> [2] http://issues.apache.org/jira/browse/OPENJPA-651,
>>>>> http://issues.apache.org/jira/browse/OPENJPA-650,
>>>>> https://issues.apache.org/jira/browse/OPENJPA-293
>>>>>
>>>>>
>>>> --
>>>> Patrick Linskey
>>>> 202 669 5907
>>>>
>>>>
>>>>
>> --
>> Patrick Linskey
>> 202 669 5907
>>
>>
>
>
> --
> Thanks - Dianne
>
>
--
View this message in context: http://n2.nabble.com/-VOTE--Turn-off-enhancement-by-subclassing-as-the-default-tp1616140p3057641.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.
Re: [VOTE] Turn off enhancement by subclassing as the default
Posted by Dianne Richards <di...@gmail.com>.
All - I've been looking into the Sun 1.6 registration of a transformer as
mentioned by Patrick and here are the results:
1. The InstrumentationFactory does a
Class.forName("com.sun.tools.attach.VirtualMachine") and uses the attach
method of that class to load the agent.
2. When I ran it, the initial code in InstrumentationFactory worked. But,
when I turned off support for RuntimeUnenhancedClasses, it failed later on
in the process. The only thing my test case is doing is creating an
EntityManagerFactory and an EntityManager. I'm assuming there are some later
checks that can be enhanced to allow this to work, but I haven't gone that
far yet.
3. HOWEVER, the VirtualMachine class is not in the default classpath. It's
in the lib/tools.jar, which I had to manually add to the classpath in order
to get this far. So, this is not an out-of-the-box solution.
4. I also tried this with the IBM jdk 6, since the tools.jar with this class
is also shipped with it. When it tried to attach, I got an
AttachNotSupportedException with the message "Unable to enqueue operation,
pre-6.0 jvm.dll?" This doesn't sound too promising.
On Tue, Dec 9, 2008 at 9:55 AM, Patrick Linskey <pl...@gmail.com> wrote:
> Excellent question. To be honest, I didn't know that we ended up with
>> different "subclassing" behavior when using a 1.5 JVM vs a 1.6 JVM.
>>
>
> In Sun-ish 1.6 VMs, we can automatically register a class transformer on
> the fly (see InstrumentationFactory). I don't remember all the subtleties of
> the configuration and the implications on what we can do, but there are
> definitely differences in the pathways, as we can directly mutate code
> blocks in 1.6 environments (but maybe we can't add fields and methods?).
>
> Has anybody spent any cycles on that approach?
>>
>
> I haven't investigated one way or the other. I believe that there's a table
> somewhere in the docs that spells out the differences between the various
> approaches.
>
> -Patrick
>
>
> On Dec 9, 2008, at 7:19 AM, Kevin Sutter wrote:
>
> Hi Patrick,
>>
>> On Tue, Dec 9, 2008 at 1:11 AM, Patrick Linskey <pl...@gmail.com>
>> wrote:
>>
>> What is the impact of your proposal on people who are using Sun-ish 1.6
>>> VMs, which have on-the-fly class redefinition support?
>>>
>>> Put another way, to what extent have you considered the differences in
>>> flakiness between the 1.5-friendly subclassing approach and the
>>> 1.6-needing
>>> redefinition approach?
>>>
>>>
>> Excellent question. To be honest, I didn't know that we ended up with
>> different "subclassing" behavior when using a 1.5 JVM vs a 1.6 JVM. I
>> thought the reported problems were equally applied to both JVM versions.
>> Do
>> we know that the 1.6 redefinition capabilities avoid the reported
>> problems?
>> Has anybody spent any cycles on that approach?
>>
>> Maybe something to think about is to turn off the subclassing support for
>> the 1.5 JVM and leave the class redefinition support on for the 1.6 JVM?
>> I
>> really don't know enough about these alternate approaches to make that
>> kind
>> of statement at this point.
>>
>> Other thoughts?
>>
>> Thanks,
>> Kevin
>>
>>
>> -Patrick
>>>
>>> On Dec 4, 2008, at 4:25 PM, Kevin Sutter wrote:
>>>
>>> Hi,
>>>
>>>> This is a tough decision, but one that I think we need to make. If you
>>>> have
>>>> been following the dev mailing list, there have been several discussions
>>>> [1]
>>>> and JIRA Issues [2] about the fallback enhancement by subclassing that
>>>> we
>>>> put in place back in the 1.0.0 timeframe. Although we succeeded in
>>>> making
>>>> the initial out-of-box experience easier for the newbie OpenJPA
>>>> developer,
>>>> we also masked the need for true enhancement for production usage. So,
>>>> unless we deem that this subclassing enhancement is critical to
>>>> OpenJPA's
>>>> acceptance and usage, I propose to turn this option off by default. The
>>>> ability to do this subclass enhancement will still be available via the
>>>> openjpa.RuntimeUnenhancedClasses property, but the default will now be
>>>> either "warn" or "unsupported" instead of "supported". I would like to
>>>> do
>>>> this for trunk for sure and possibly the 1.3.x branch as well. Please
>>>> vote
>>>> accordingly. Thanks for your input. Write-in comments are also
>>>> welcome.
>>>>
>>>> [ +1 | 0 | -1 ] Turn off subclass enhancement in trunk
>>>> [ +1 | 0 | -1 ] Turn off subclass enhancement in 1.3.x
>>>>
>>>> I am not proposing to turn it off in the other branches since those are
>>>> not
>>>> active development streams, but rather service streams. We shouldn't
>>>> introduce a change like this into a customer's service stream. That is,
>>>> for
>>>> a customer to get 1.0.4 with this option turned off would be a surprise
>>>> since they would only be expecting fixes. Fine line in this case, but
>>>> you
>>>> get the picture.
>>>>
>>>> Thanks,
>>>> Kevin
>>>>
>>>> [1]
>>>>
>>>>
>>>> http://n2.nabble.com/Re%3A-Foreign-key-field-doesn%27t-get-populated-in-descendant-class-in-Join-Inheritance-td1574111.html#a1574493
>>>> [2] http://issues.apache.org/jira/browse/OPENJPA-651,
>>>> http://issues.apache.org/jira/browse/OPENJPA-650,
>>>> https://issues.apache.org/jira/browse/OPENJPA-293
>>>>
>>>>
>>> --
>>> Patrick Linskey
>>> 202 669 5907
>>>
>>>
>>>
> --
> Patrick Linskey
> 202 669 5907
>
>
--
Thanks - Dianne
Re: [VOTE] Turn off enhancement by subclassing as the default
Posted by Patrick Linskey <pl...@gmail.com>.
> Excellent question. To be honest, I didn't know that we ended up with
> different "subclassing" behavior when using a 1.5 JVM vs a 1.6 JVM.
In Sun-ish 1.6 VMs, we can automatically register a class transformer
on the fly (see InstrumentationFactory). I don't remember all the
subtleties of the configuration and the implications on what we can
do, but there are definitely differences in the pathways, as we can
directly mutate code blocks in 1.6 environments (but maybe we can't
add fields and methods?).
> Has anybody spent any cycles on that approach?
I haven't investigated one way or the other. I believe that there's a
table somewhere in the docs that spells out the differences between
the various approaches.
-Patrick
On Dec 9, 2008, at 7:19 AM, Kevin Sutter wrote:
> Hi Patrick,
>
> On Tue, Dec 9, 2008 at 1:11 AM, Patrick Linskey <pl...@gmail.com>
> wrote:
>
>> What is the impact of your proposal on people who are using Sun-ish
>> 1.6
>> VMs, which have on-the-fly class redefinition support?
>>
>> Put another way, to what extent have you considered the differences
>> in
>> flakiness between the 1.5-friendly subclassing approach and the 1.6-
>> needing
>> redefinition approach?
>>
>
> Excellent question. To be honest, I didn't know that we ended up with
> different "subclassing" behavior when using a 1.5 JVM vs a 1.6 JVM. I
> thought the reported problems were equally applied to both JVM
> versions. Do
> we know that the 1.6 redefinition capabilities avoid the reported
> problems?
> Has anybody spent any cycles on that approach?
>
> Maybe something to think about is to turn off the subclassing
> support for
> the 1.5 JVM and leave the class redefinition support on for the 1.6
> JVM? I
> really don't know enough about these alternate approaches to make
> that kind
> of statement at this point.
>
> Other thoughts?
>
> Thanks,
> Kevin
>
>
>> -Patrick
>>
>> On Dec 4, 2008, at 4:25 PM, Kevin Sutter wrote:
>>
>> Hi,
>>> This is a tough decision, but one that I think we need to make.
>>> If you
>>> have
>>> been following the dev mailing list, there have been several
>>> discussions
>>> [1]
>>> and JIRA Issues [2] about the fallback enhancement by subclassing
>>> that we
>>> put in place back in the 1.0.0 timeframe. Although we succeeded
>>> in making
>>> the initial out-of-box experience easier for the newbie OpenJPA
>>> developer,
>>> we also masked the need for true enhancement for production
>>> usage. So,
>>> unless we deem that this subclassing enhancement is critical to
>>> OpenJPA's
>>> acceptance and usage, I propose to turn this option off by
>>> default. The
>>> ability to do this subclass enhancement will still be available
>>> via the
>>> openjpa.RuntimeUnenhancedClasses property, but the default will
>>> now be
>>> either "warn" or "unsupported" instead of "supported". I would
>>> like to do
>>> this for trunk for sure and possibly the 1.3.x branch as well.
>>> Please
>>> vote
>>> accordingly. Thanks for your input. Write-in comments are also
>>> welcome.
>>>
>>> [ +1 | 0 | -1 ] Turn off subclass enhancement in trunk
>>> [ +1 | 0 | -1 ] Turn off subclass enhancement in 1.3.x
>>>
>>> I am not proposing to turn it off in the other branches since
>>> those are
>>> not
>>> active development streams, but rather service streams. We
>>> shouldn't
>>> introduce a change like this into a customer's service stream.
>>> That is,
>>> for
>>> a customer to get 1.0.4 with this option turned off would be a
>>> surprise
>>> since they would only be expecting fixes. Fine line in this case,
>>> but you
>>> get the picture.
>>>
>>> Thanks,
>>> Kevin
>>>
>>> [1]
>>>
>>> http://n2.nabble.com/Re%3A-Foreign-key-field-doesn%27t-get-populated-in-descendant-class-in-Join-Inheritance-td1574111.html#a1574493
>>> [2] http://issues.apache.org/jira/browse/OPENJPA-651,
>>> http://issues.apache.org/jira/browse/OPENJPA-650,
>>> https://issues.apache.org/jira/browse/OPENJPA-293
>>>
>>
>> --
>> Patrick Linskey
>> 202 669 5907
>>
>>
--
Patrick Linskey
202 669 5907
Re: [VOTE] Turn off enhancement by subclassing as the default
Posted by Kevin Sutter <kw...@gmail.com>.
Hi Patrick,
On Tue, Dec 9, 2008 at 1:11 AM, Patrick Linskey <pl...@gmail.com> wrote:
> What is the impact of your proposal on people who are using Sun-ish 1.6
> VMs, which have on-the-fly class redefinition support?
>
> Put another way, to what extent have you considered the differences in
> flakiness between the 1.5-friendly subclassing approach and the 1.6-needing
> redefinition approach?
>
Excellent question. To be honest, I didn't know that we ended up with
different "subclassing" behavior when using a 1.5 JVM vs a 1.6 JVM. I
thought the reported problems were equally applied to both JVM versions. Do
we know that the 1.6 redefinition capabilities avoid the reported problems?
Has anybody spent any cycles on that approach?
Maybe something to think about is to turn off the subclassing support for
the 1.5 JVM and leave the class redefinition support on for the 1.6 JVM? I
really don't know enough about these alternate approaches to make that kind
of statement at this point.
Other thoughts?
Thanks,
Kevin
> -Patrick
>
> On Dec 4, 2008, at 4:25 PM, Kevin Sutter wrote:
>
> Hi,
>> This is a tough decision, but one that I think we need to make. If you
>> have
>> been following the dev mailing list, there have been several discussions
>> [1]
>> and JIRA Issues [2] about the fallback enhancement by subclassing that we
>> put in place back in the 1.0.0 timeframe. Although we succeeded in making
>> the initial out-of-box experience easier for the newbie OpenJPA developer,
>> we also masked the need for true enhancement for production usage. So,
>> unless we deem that this subclassing enhancement is critical to OpenJPA's
>> acceptance and usage, I propose to turn this option off by default. The
>> ability to do this subclass enhancement will still be available via the
>> openjpa.RuntimeUnenhancedClasses property, but the default will now be
>> either "warn" or "unsupported" instead of "supported". I would like to do
>> this for trunk for sure and possibly the 1.3.x branch as well. Please
>> vote
>> accordingly. Thanks for your input. Write-in comments are also welcome.
>>
>> [ +1 | 0 | -1 ] Turn off subclass enhancement in trunk
>> [ +1 | 0 | -1 ] Turn off subclass enhancement in 1.3.x
>>
>> I am not proposing to turn it off in the other branches since those are
>> not
>> active development streams, but rather service streams. We shouldn't
>> introduce a change like this into a customer's service stream. That is,
>> for
>> a customer to get 1.0.4 with this option turned off would be a surprise
>> since they would only be expecting fixes. Fine line in this case, but you
>> get the picture.
>>
>> Thanks,
>> Kevin
>>
>> [1]
>>
>> http://n2.nabble.com/Re%3A-Foreign-key-field-doesn%27t-get-populated-in-descendant-class-in-Join-Inheritance-td1574111.html#a1574493
>> [2] http://issues.apache.org/jira/browse/OPENJPA-651,
>> http://issues.apache.org/jira/browse/OPENJPA-650,
>> https://issues.apache.org/jira/browse/OPENJPA-293
>>
>
> --
> Patrick Linskey
> 202 669 5907
>
>
Re: [VOTE] Turn off enhancement by subclassing as the default
Posted by Patrick Linskey <pl...@gmail.com>.
What is the impact of your proposal on people who are using Sun-ish
1.6 VMs, which have on-the-fly class redefinition support?
Put another way, to what extent have you considered the differences in
flakiness between the 1.5-friendly subclassing approach and the 1.6-
needing redefinition approach?
-Patrick
On Dec 4, 2008, at 4:25 PM, Kevin Sutter wrote:
> Hi,
> This is a tough decision, but one that I think we need to make. If
> you have
> been following the dev mailing list, there have been several
> discussions [1]
> and JIRA Issues [2] about the fallback enhancement by subclassing
> that we
> put in place back in the 1.0.0 timeframe. Although we succeeded in
> making
> the initial out-of-box experience easier for the newbie OpenJPA
> developer,
> we also masked the need for true enhancement for production usage.
> So,
> unless we deem that this subclassing enhancement is critical to
> OpenJPA's
> acceptance and usage, I propose to turn this option off by default.
> The
> ability to do this subclass enhancement will still be available via
> the
> openjpa.RuntimeUnenhancedClasses property, but the default will now be
> either "warn" or "unsupported" instead of "supported". I would like
> to do
> this for trunk for sure and possibly the 1.3.x branch as well.
> Please vote
> accordingly. Thanks for your input. Write-in comments are also
> welcome.
>
> [ +1 | 0 | -1 ] Turn off subclass enhancement in trunk
> [ +1 | 0 | -1 ] Turn off subclass enhancement in 1.3.x
>
> I am not proposing to turn it off in the other branches since those
> are not
> active development streams, but rather service streams. We shouldn't
> introduce a change like this into a customer's service stream. That
> is, for
> a customer to get 1.0.4 with this option turned off would be a
> surprise
> since they would only be expecting fixes. Fine line in this case,
> but you
> get the picture.
>
> Thanks,
> Kevin
>
> [1]
> http://n2.nabble.com/Re%3A-Foreign-key-field-doesn%27t-get-populated-in-descendant-class-in-Join-Inheritance-td1574111.html#a1574493
> [2] http://issues.apache.org/jira/browse/OPENJPA-651,
> http://issues.apache.org/jira/browse/OPENJPA-650,
> https://issues.apache.org/jira/browse/OPENJPA-293
--
Patrick Linskey
202 669 5907
Re: [VOTE] Turn off enhancement by subclassing as the default
Posted by Albert Lee <al...@gmail.com>.
+1 Turn off subclass enhancement in trunk
-1 Turn off subclass enhancement in 1.3.x
Trunk will turn into a JPA 2.0 and 1.3 remains in JPA 1.0. For continuity
for the 1.0 base, I would suggest to leave 1.3 the way it is but turn off
enhancing in the trunk.
Albert Lee.
On Thu, Dec 4, 2008 at 6:25 PM, Kevin Sutter <kw...@gmail.com> wrote:
> Hi,
> This is a tough decision, but one that I think we need to make. If you
> have
> been following the dev mailing list, there have been several discussions
> [1]
> and JIRA Issues [2] about the fallback enhancement by subclassing that we
> put in place back in the 1.0.0 timeframe. Although we succeeded in making
> the initial out-of-box experience easier for the newbie OpenJPA developer,
> we also masked the need for true enhancement for production usage. So,
> unless we deem that this subclassing enhancement is critical to OpenJPA's
> acceptance and usage, I propose to turn this option off by default. The
> ability to do this subclass enhancement will still be available via the
> openjpa.RuntimeUnenhancedClasses property, but the default will now be
> either "warn" or "unsupported" instead of "supported". I would like to do
> this for trunk for sure and possibly the 1.3.x branch as well. Please vote
> accordingly. Thanks for your input. Write-in comments are also welcome.
>
> [ +1 | 0 | -1 ] Turn off subclass enhancement in trunk
> [ +1 | 0 | -1 ] Turn off subclass enhancement in 1.3.x
>
> I am not proposing to turn it off in the other branches since those are not
> active development streams, but rather service streams. We shouldn't
> introduce a change like this into a customer's service stream. That is,
> for
> a customer to get 1.0.4 with this option turned off would be a surprise
> since they would only be expecting fixes. Fine line in this case, but you
> get the picture.
>
> Thanks,
> Kevin
>
> [1]
>
> http://n2.nabble.com/Re%3A-Foreign-key-field-doesn%27t-get-populated-in-descendant-class-in-Join-Inheritance-td1574111.html#a1574493
> [2] http://issues.apache.org/jira/browse/OPENJPA-651,
> http://issues.apache.org/jira/browse/OPENJPA-650,
> https://issues.apache.org/jira/browse/OPENJPA-293
>
--
Albert Lee.
Re: [VOTE] Turn off enhancement by subclassing as the default
Posted by Kevin Sutter <kw...@gmail.com>.
As some of you from private conversations, I've been waffling on this
issue. At first, I was totally on the band wagon to turn the sub-classing
support off by default (thus, the reason for the [VOTE] in the first
place). But, when I see all of the questions being posted about how to do
our enhancement processing, I have to question whether our enhancement
processing is the correct way to go -- although it has been proven to kick
butt on performance and reliability (as compared to our current sub-classing
support).
As Mike has pointed out, we have several JIRA Issues related to the
sub-classing support [1]. Although I would be in favor of the sub-classing
support if we could the Issues resolved and get the performance inline with
our enhancement processing, I just don't see anybody signing up for this
piece of work. So, until that happens, I think our only alternative is to
turn off the support in both 1.3 and trunk. The way we have it right now
allows too many people feel a false sense of security. OpenJPA works out of
the box with the simple "hello world" example, but then when they need to
push it a little harder they start to run into problems and are required to
use the enhancement processing. It's confusing for our customers.
For these reasons, at this point, I feel that we should promote the
enhancement processing that works and performs. If and when we can
demonstrate that the sub-classing support meets the same level of
capabilities, then we can re-visit this issue.
Long explanation for +1 for turning off the sub-classing support by default
on both 1.3 and trunk. :-)
Kevin
[1]
https://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12313257
On Wed, May 20, 2009 at 9:40 PM, Michael Dick <mi...@gmail.com>wrote:
> RuntimeUnenhancedClasses=unsupported is the proposed solution.
>
> Currently there are 14 known issues [1] with unenhanced classes. I'm sure
> there are other unreported issues, and questions on the mailing lists that
> could have turned into issues, but that's largely academic.
>
> I think the long term goal is to get to a single strategy : bytecode
> enhancement or subclassing. Once we've chosen one we should make that
> strategy as easy to use, functional and perform as well as possible.
> Maintaining two strategies is not cost effective. I have mixed feelings
> about which is the better strategy long term though.
>
> The known issues with subclassing and behavioral differences lead me to
> think that it should be disabled by default at least until the known issues
> are resolved. The function need not be forgotten, but I don't think it's
> ready to be the default behavior yet.
>
> [1]
>
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=12310351&sorter/order=DESC&sorter/field=priority&resolution=-1&component=12312835
>
> Regards,
>
> -mike
>
> On Wed, May 20, 2009 at 5:45 PM, Pinaki Poddar <pp...@apache.org> wrote:
>
> >
> > Hi Kevin,
> >
> > +1 on 1.3 if you mean "turn off" as
> > openjpa.RuntimeUnenhancedClasses=unsupported.
> >
> > I am rather ambivalent about trunk though.
> >
> > Few more aspects that we should take note of:
> > 1. We must recognize the core notion behind runtime enhancement is a
> > strong and useful feature.
> >
> > 2. The available support has its flaws (which is the reason for this
> > discussion being resurrected) -- but more importantly, we do not know the
> > footprint of the incompleteness of this feature. Given that we run our
> test
> > corpus on enhanced classes only, we basically wait till a user's report
> is
> > diagnosed as yet another bug caused by this feature.
> >
> > 3. "Turning it off" has the risk of this powerful feature being
> > "forgotten" -- if it turns out so, it will not be a desirable outcome.
> >
> >
> > -----
> > Pinaki Poddar http://ppoddar.blogspot.com/
> >
> > http://www.linkedin.com/in/pinakipoddar
> > OpenJPA PMC Member/Committer
> > JPA Expert Group Member
> > --
> > View this message in context:
> >
> http://n2.nabble.com/-VOTE--Turn-off-enhancement-by-subclassing-as-the-default-tp1616140p2949153.html
> > Sent from the OpenJPA Developers mailing list archive at Nabble.com.
> >
> >
>
Re: [VOTE] Turn off enhancement by subclassing as the default
Posted by Michael Dick <mi...@gmail.com>.
RuntimeUnenhancedClasses=unsupported is the proposed solution.
Currently there are 14 known issues [1] with unenhanced classes. I'm sure
there are other unreported issues, and questions on the mailing lists that
could have turned into issues, but that's largely academic.
I think the long term goal is to get to a single strategy : bytecode
enhancement or subclassing. Once we've chosen one we should make that
strategy as easy to use, functional and perform as well as possible.
Maintaining two strategies is not cost effective. I have mixed feelings
about which is the better strategy long term though.
The known issues with subclassing and behavioral differences lead me to
think that it should be disabled by default at least until the known issues
are resolved. The function need not be forgotten, but I don't think it's
ready to be the default behavior yet.
[1]
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=12310351&sorter/order=DESC&sorter/field=priority&resolution=-1&component=12312835
Regards,
-mike
On Wed, May 20, 2009 at 5:45 PM, Pinaki Poddar <pp...@apache.org> wrote:
>
> Hi Kevin,
>
> +1 on 1.3 if you mean "turn off" as
> openjpa.RuntimeUnenhancedClasses=unsupported.
>
> I am rather ambivalent about trunk though.
>
> Few more aspects that we should take note of:
> 1. We must recognize the core notion behind runtime enhancement is a
> strong and useful feature.
>
> 2. The available support has its flaws (which is the reason for this
> discussion being resurrected) -- but more importantly, we do not know the
> footprint of the incompleteness of this feature. Given that we run our test
> corpus on enhanced classes only, we basically wait till a user's report is
> diagnosed as yet another bug caused by this feature.
>
> 3. "Turning it off" has the risk of this powerful feature being
> "forgotten" -- if it turns out so, it will not be a desirable outcome.
>
>
> -----
> Pinaki Poddar http://ppoddar.blogspot.com/
>
> http://www.linkedin.com/in/pinakipoddar
> OpenJPA PMC Member/Committer
> JPA Expert Group Member
> --
> View this message in context:
> http://n2.nabble.com/-VOTE--Turn-off-enhancement-by-subclassing-as-the-default-tp1616140p2949153.html
> Sent from the OpenJPA Developers mailing list archive at Nabble.com.
>
>
Re: [VOTE] Turn off enhancement by subclassing as the default
Posted by Michael Dick <mi...@gmail.com>.
Hi all,
Just re-tallying the votes.
Turn off subclassing by default in trunk :
+1 : Mike, Jeremy, Albert, Rick (non binding?), Donald, Kevin, Craig
+0 : no one
-1 : no one
Abstained : Pinaki
Total +6 (7 with Rick)
Turn off subclassing by default in 1.3.x :
+1 : Mike, Rick (non binding?), Donald, Kevin, Craig, Pinaki
+0 : Jeremy
-1 : Albert
Abstained : No one
Total +4 (5 with Rick's vote)
I would like to add that this does not mean that we will remove the
subclassing code, or that we'll never consider improving it or re-enabling
it in the future. It's only a measure to prevent users from going down this
path (given its limitations) without being aware of it.
To that end I've assigned OPENJPA-651 to myself and I'll make the
appropriate changes in trunk (no -1 votes, 1.3 can follow later).
-mike
Craig L Russell wrote:
>
> +1 to turn it off in both 1.3 and trunk.
>
> Turning it off will not let it be forgotten. Every user who naively
> runs without benefit of enhancement will get a nice message just like
> today. The difference is that after getting the message that
> enhancement was not done, today the user continues and tomorrow the
> user will have to actually read the message.
>
> The message should direct the user to explicit instructions on how to
> enhance the classes, and how to run without enhancement.
>
> I can tell you that it took me a while to figure it out.
>
> Craig
>
> On May 20, 2009, at 3:45 PM, Pinaki Poddar wrote:
>
>>
>> Hi Kevin,
>>
>> +1 on 1.3 if you mean "turn off" as
>> openjpa.RuntimeUnenhancedClasses=unsupported.
>>
>> I am rather ambivalent about trunk though.
>>
>> Few more aspects that we should take note of:
>> 1. We must recognize the core notion behind runtime enhancement is a
>> strong and useful feature.
>>
>> 2. The available support has its flaws (which is the reason for this
>> discussion being resurrected) -- but more importantly, we do not
>> know the
>> footprint of the incompleteness of this feature. Given that we run
>> our test
>> corpus on enhanced classes only, we basically wait till a user's
>> report is
>> diagnosed as yet another bug caused by this feature.
>>
>> 3. "Turning it off" has the risk of this powerful feature being
>> "forgotten" -- if it turns out so, it will not be a desirable outcome.
>>
>>
>> -----
>> Pinaki Poddar http://ppoddar.blogspot.com/
>>
>> http://www.linkedin.com/in/pinakipoddar
>> OpenJPA PMC Member/Committer
>> JPA Expert Group Member
>> --
>> View this message in context:
>> http://n2.nabble.com/-VOTE--Turn-off-enhancement-by-subclassing-as-the-default-tp1616140p2949153.html
>> Sent from the OpenJPA Developers mailing list archive at Nabble.com.
>>
>
> Craig L Russell
> Architect, Sun Java Enterprise System http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
>
>
--
View this message in context: http://n2.nabble.com/-VOTE--Turn-off-enhancement-by-subclassing-as-the-default-tp1616140p3057569.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.
Re: [VOTE] Turn off enhancement by subclassing as the default
Posted by Craig L Russell <Cr...@Sun.COM>.
+1 to turn it off in both 1.3 and trunk.
Turning it off will not let it be forgotten. Every user who naively
runs without benefit of enhancement will get a nice message just like
today. The difference is that after getting the message that
enhancement was not done, today the user continues and tomorrow the
user will have to actually read the message.
The message should direct the user to explicit instructions on how to
enhance the classes, and how to run without enhancement.
I can tell you that it took me a while to figure it out.
Craig
On May 20, 2009, at 3:45 PM, Pinaki Poddar wrote:
>
> Hi Kevin,
>
> +1 on 1.3 if you mean "turn off" as
> openjpa.RuntimeUnenhancedClasses=unsupported.
>
> I am rather ambivalent about trunk though.
>
> Few more aspects that we should take note of:
> 1. We must recognize the core notion behind runtime enhancement is a
> strong and useful feature.
>
> 2. The available support has its flaws (which is the reason for this
> discussion being resurrected) -- but more importantly, we do not
> know the
> footprint of the incompleteness of this feature. Given that we run
> our test
> corpus on enhanced classes only, we basically wait till a user's
> report is
> diagnosed as yet another bug caused by this feature.
>
> 3. "Turning it off" has the risk of this powerful feature being
> "forgotten" -- if it turns out so, it will not be a desirable outcome.
>
>
> -----
> Pinaki Poddar http://ppoddar.blogspot.com/
>
> http://www.linkedin.com/in/pinakipoddar
> OpenJPA PMC Member/Committer
> JPA Expert Group Member
> --
> View this message in context: http://n2.nabble.com/-VOTE--Turn-off-enhancement-by-subclassing-as-the-default-tp1616140p2949153.html
> Sent from the OpenJPA Developers mailing list archive at Nabble.com.
>
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: [VOTE] Turn off enhancement by subclassing as the default
Posted by Pinaki Poddar <pp...@apache.org>.
Hi Kevin,
+1 on 1.3 if you mean "turn off" as
openjpa.RuntimeUnenhancedClasses=unsupported.
I am rather ambivalent about trunk though.
Few more aspects that we should take note of:
1. We must recognize the core notion behind runtime enhancement is a
strong and useful feature.
2. The available support has its flaws (which is the reason for this
discussion being resurrected) -- but more importantly, we do not know the
footprint of the incompleteness of this feature. Given that we run our test
corpus on enhanced classes only, we basically wait till a user's report is
diagnosed as yet another bug caused by this feature.
3. "Turning it off" has the risk of this powerful feature being
"forgotten" -- if it turns out so, it will not be a desirable outcome.
-----
Pinaki Poddar http://ppoddar.blogspot.com/
http://www.linkedin.com/in/pinakipoddar
OpenJPA PMC Member/Committer
JPA Expert Group Member
--
View this message in context: http://n2.nabble.com/-VOTE--Turn-off-enhancement-by-subclassing-as-the-default-tp1616140p2949153.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.
Re: [VOTE] Turn off enhancement by subclassing as the default
Posted by Albert Lee <al...@gmail.com>.
Just want to point out that there is no impact for application deployed in
app server which will perform automatic class enhancement even no build time
enhancement or javaagent is specified.
Albert Lee.
On Thu, Dec 4, 2008 at 9:29 PM, Michael Dick <mi...@apache.org> wrote:
> Hi David,
>
> You're correct on both counts. You'll only be affected if you do not run
> the
> PCEnhancer, or use a javaagent.
>
> My Votes :
> +1 Turn off subclass enhancement in trunk
>
> +1 Turn off subclass enhancement in 1.3.x
> In for a penny in for a pound. . .
>
> I think the subclass support a noble goal but it needs some additional work
> before it should be the default behavior. Until we find a champion who is
> interested and has the time to dedicate to ironing out the bugs we should
> leave it turned off.
>
> -mike
>
> On Thu, Dec 4, 2008 at 7:51 PM, David Jencks <da...@yahoo.com>
> wrote:
>
> > Just to be really clear, this won't affect either:
> >
> > - projects that have pre-enhanced their classes at build time using e.g.
> a
> > maven plugin or ant task
> > - app servers (for instance) that start up with an appropriate javaagent
> > that hooks up to the openjpa enhancer
> >
> > it will only affect people who don't make any effort to enhance their
> > classes
> >
> > Correct?
> >
> > thanks
> > david jencks
> >
> >
> > On Dec 4, 2008, at 4:25 PM, Kevin Sutter wrote:
> >
> > Hi,
> >> This is a tough decision, but one that I think we need to make. If you
> >> have
> >> been following the dev mailing list, there have been several discussions
> >> [1]
> >> and JIRA Issues [2] about the fallback enhancement by subclassing that
> we
> >> put in place back in the 1.0.0 timeframe. Although we succeeded in
> making
> >> the initial out-of-box experience easier for the newbie OpenJPA
> developer,
> >> we also masked the need for true enhancement for production usage. So,
> >> unless we deem that this subclassing enhancement is critical to
> OpenJPA's
> >> acceptance and usage, I propose to turn this option off by default. The
> >> ability to do this subclass enhancement will still be available via the
> >> openjpa.RuntimeUnenhancedClasses property, but the default will now be
> >> either "warn" or "unsupported" instead of "supported". I would like to
> do
> >> this for trunk for sure and possibly the 1.3.x branch as well. Please
> >> vote
> >> accordingly. Thanks for your input. Write-in comments are also
> welcome.
> >>
> >> [ +1 | 0 | -1 ] Turn off subclass enhancement in trunk
> >> [ +1 | 0 | -1 ] Turn off subclass enhancement in 1.3.x
> >>
> >> I am not proposing to turn it off in the other branches since those are
> >> not
> >> active development streams, but rather service streams. We shouldn't
> >> introduce a change like this into a customer's service stream. That is,
> >> for
> >> a customer to get 1.0.4 with this option turned off would be a surprise
> >> since they would only be expecting fixes. Fine line in this case, but
> you
> >> get the picture.
> >>
> >> Thanks,
> >> Kevin
> >>
> >> [1]
> >>
> >>
> http://n2.nabble.com/Re%3A-Foreign-key-field-doesn%27t-get-populated-in-descendant-class-in-Join-Inheritance-td1574111.html#a1574493
> >> [2] http://issues.apache.org/jira/browse/OPENJPA-651,
> >> http://issues.apache.org/jira/browse/OPENJPA-650,
> >> https://issues.apache.org/jira/browse/OPENJPA-293
> >>
> >
> >
>
--
Albert Lee.
Re: [VOTE] Turn off enhancement by subclassing as the default
Posted by Michael Dick <mi...@apache.org>.
Hi David,
You're correct on both counts. You'll only be affected if you do not run the
PCEnhancer, or use a javaagent.
My Votes :
+1 Turn off subclass enhancement in trunk
+1 Turn off subclass enhancement in 1.3.x
In for a penny in for a pound. . .
I think the subclass support a noble goal but it needs some additional work
before it should be the default behavior. Until we find a champion who is
interested and has the time to dedicate to ironing out the bugs we should
leave it turned off.
-mike
On Thu, Dec 4, 2008 at 7:51 PM, David Jencks <da...@yahoo.com> wrote:
> Just to be really clear, this won't affect either:
>
> - projects that have pre-enhanced their classes at build time using e.g. a
> maven plugin or ant task
> - app servers (for instance) that start up with an appropriate javaagent
> that hooks up to the openjpa enhancer
>
> it will only affect people who don't make any effort to enhance their
> classes
>
> Correct?
>
> thanks
> david jencks
>
>
> On Dec 4, 2008, at 4:25 PM, Kevin Sutter wrote:
>
> Hi,
>> This is a tough decision, but one that I think we need to make. If you
>> have
>> been following the dev mailing list, there have been several discussions
>> [1]
>> and JIRA Issues [2] about the fallback enhancement by subclassing that we
>> put in place back in the 1.0.0 timeframe. Although we succeeded in making
>> the initial out-of-box experience easier for the newbie OpenJPA developer,
>> we also masked the need for true enhancement for production usage. So,
>> unless we deem that this subclassing enhancement is critical to OpenJPA's
>> acceptance and usage, I propose to turn this option off by default. The
>> ability to do this subclass enhancement will still be available via the
>> openjpa.RuntimeUnenhancedClasses property, but the default will now be
>> either "warn" or "unsupported" instead of "supported". I would like to do
>> this for trunk for sure and possibly the 1.3.x branch as well. Please
>> vote
>> accordingly. Thanks for your input. Write-in comments are also welcome.
>>
>> [ +1 | 0 | -1 ] Turn off subclass enhancement in trunk
>> [ +1 | 0 | -1 ] Turn off subclass enhancement in 1.3.x
>>
>> I am not proposing to turn it off in the other branches since those are
>> not
>> active development streams, but rather service streams. We shouldn't
>> introduce a change like this into a customer's service stream. That is,
>> for
>> a customer to get 1.0.4 with this option turned off would be a surprise
>> since they would only be expecting fixes. Fine line in this case, but you
>> get the picture.
>>
>> Thanks,
>> Kevin
>>
>> [1]
>>
>> http://n2.nabble.com/Re%3A-Foreign-key-field-doesn%27t-get-populated-in-descendant-class-in-Join-Inheritance-td1574111.html#a1574493
>> [2] http://issues.apache.org/jira/browse/OPENJPA-651,
>> http://issues.apache.org/jira/browse/OPENJPA-650,
>> https://issues.apache.org/jira/browse/OPENJPA-293
>>
>
>
Re: [VOTE] Turn off enhancement by subclassing as the default
Posted by David Jencks <da...@yahoo.com>.
Just to be really clear, this won't affect either:
- projects that have pre-enhanced their classes at build time using
e.g. a maven plugin or ant task
- app servers (for instance) that start up with an appropriate
javaagent that hooks up to the openjpa enhancer
it will only affect people who don't make any effort to enhance their
classes
Correct?
thanks
david jencks
On Dec 4, 2008, at 4:25 PM, Kevin Sutter wrote:
> Hi,
> This is a tough decision, but one that I think we need to make. If
> you have
> been following the dev mailing list, there have been several
> discussions [1]
> and JIRA Issues [2] about the fallback enhancement by subclassing
> that we
> put in place back in the 1.0.0 timeframe. Although we succeeded in
> making
> the initial out-of-box experience easier for the newbie OpenJPA
> developer,
> we also masked the need for true enhancement for production usage.
> So,
> unless we deem that this subclassing enhancement is critical to
> OpenJPA's
> acceptance and usage, I propose to turn this option off by default.
> The
> ability to do this subclass enhancement will still be available via
> the
> openjpa.RuntimeUnenhancedClasses property, but the default will now be
> either "warn" or "unsupported" instead of "supported". I would like
> to do
> this for trunk for sure and possibly the 1.3.x branch as well.
> Please vote
> accordingly. Thanks for your input. Write-in comments are also
> welcome.
>
> [ +1 | 0 | -1 ] Turn off subclass enhancement in trunk
> [ +1 | 0 | -1 ] Turn off subclass enhancement in 1.3.x
>
> I am not proposing to turn it off in the other branches since those
> are not
> active development streams, but rather service streams. We shouldn't
> introduce a change like this into a customer's service stream. That
> is, for
> a customer to get 1.0.4 with this option turned off would be a
> surprise
> since they would only be expecting fixes. Fine line in this case,
> but you
> get the picture.
>
> Thanks,
> Kevin
>
> [1]
> http://n2.nabble.com/Re%3A-Foreign-key-field-doesn%27t-get-populated-in-descendant-class-in-Join-Inheritance-td1574111.html#a1574493
> [2] http://issues.apache.org/jira/browse/OPENJPA-651,
> http://issues.apache.org/jira/browse/OPENJPA-650,
> https://issues.apache.org/jira/browse/OPENJPA-293