Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Received-SPF: pass (athena.apache.org: domain of
 lists+1214986235816-210739@n2.nabble.com designates 216.139.236.158 as
 permitted sender)
Message-ID: <1244659462091-3057641.post@n2.nabble.com>
Date: Wed, 10 Jun 2009 11:44:22 -0700 (PDT)
From: Michael Dick <michael.d.dick@gmail.com>
To: dev@openjpa.apache.org
Subject: Re: [VOTE] Turn off enhancement by subclassing as the default
In-Reply-To: <7ef9f09c0812161432r69cb9829k5ec981eeca336e6d@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <89c0c52c0812041625x69489674x59d052ffae528e37@mail.gmail.com>
 <F9E439A2-2160-40CA-968A-F366121AF374@gmail.com>
 <89c0c52c0812090719h1d9dcb82r46a7b064f61c4179@mail.gmail.com>
 <1BA3573A-B47C-48C8-B791-E3F9CD1A0875@gmail.com>
 <7ef9f09c0812161432r69cb9829k5ec981eeca336e6d@mail.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 <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
> 
> 

-- 
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.