geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Runtime entity enhancement for OSGi applications
Date Wed, 19 May 2010 20:28:47 GMT

On May 19, 2010, at 1:16 PM, Donald Woods wrote:

> Good summary Lin.
> 
> In the OpenJPA community, we've been telling users for awhile now not to
> use the runtime enhancement, as it has known deficiencies, and should
> only be used for quick prototyping and never in production.

What are these deficiencies?  I thought you got the same bytecode whether you ran the enhancer
using maven or as the classes are loaded using a class transformer.  I know the subclassing
approach doesn't work well but that is not being discussed here AFAIK.

Is this stuff documented clearly somewhere in the openjpa docs?  I've never found a comprehensible
explanation when I've looked in the past.

thanks
david jencks

> 
> If we need to continue supporting this in Geronimo (for the developer
> scenarios), then I'd go with #3 for now.
> 
> 
> -Donald
> 
> 
> On 5/19/10 11:19 AM, Lin Sun wrote:
>> Seems No. 3 is the right approach, given that there is no overhead on
>> the user side and it gives the ability to add the imports at the last
>> minute, before the PU is resolved.
>> 
>> No. 2 gives some extra work on the user side which can make the PU not portable.
>> 
>> Np. 4 has to be done when PU is installed, and it is possible the
>> provider is not even there yet.
>> 
>> No. 5 can be confusing to the user as a fragment is attached to their PU.
>> 
>> Lin
>> 
>> On Tue, May 18, 2010 at 10:41 PM, Jarek Gawor <jgawor@gmail.com> wrote:
>>> Hi all,
>>> 
>>> I was looking into getting the runtime JPA entity enhancement for OSGi
>>> applications working in Geronimo. With some modifications to the Aries
>>> JPA code and some to Geronimo I was able to get runtime enhancement
>>> working (using the java agent approach) but with one major issue: The
>>> bundle that contains the persistence unit must be able to load some
>>> persistence provider specific (in our case openjpa) classes. That's
>>> because during the bytecode weaving, openjpa adds some openjpa
>>> specific interfaces to the entity classes. So how should we deal with
>>> this issue in Geronimo?
>>> 
>>> 1) We could do nothing and just say we don't support runtime enhancement.
>>> 
>>> 2) We could support runtime enhancement and require that bundles with
>>> PU have DynamicImport-Package: * header.
>>> 
>>> 3) Use framework "classloader hooks" to dynamically add imports for
>>> the persistence provider specific packages to the bundles with PU .
>>> That of course, would rely on framework specific extensions. I know
>>> Equinox has such hooks and I think recently something similar was
>>> added to Felix.
>>> 
>>> 4) Provide some url handler, e.g. "jpa" which would enhance the entity
>>> classes and add right imports during the install. Something similar to
>>> the "webbundle" url handler for web application archives. Of course,
>>> we would have to make sure the bundles with PU get installed via the
>>> url handler.
>>> 
>>> 5) Have some kind of an extender that would generate a fragment bundle
>>> (with right persistence provider imports) and attach it to the bundle
>>> with PU. Or something similar that would require manifest modification
>>> or generation of additional bundle.
>>> 
>>> Thoughts?
>>> 
>>> Jarek
>>> 
>> 


Mime
View raw message