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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > >> 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 >
