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

Reply via email to