openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <dwo...@apache.org>
Subject Re: [VOTE] Turn off enhancement by subclassing as the default
Date Wed, 20 May 2009 16:44:09 GMT
+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 <dianner4@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 <plinskey@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 <plinskey@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
>>
> 

Mime
View raw message