+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 <[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
