openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick" <>
Subject Re: [VOTE] Turn off enhancement by subclassing as the default
Date Fri, 05 Dec 2008 03:29:12 GMT
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.


On Thu, Dec 4, 2008 at 7:51 PM, David Jencks <> 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]
>> [2],

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message