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