You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jarek Gawor <jg...@gmail.com> on 2010/05/19 04:41:19 UTC

Runtime entity enhancement for OSGi applications

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

Re: Runtime entity enhancement for OSGi applications

Posted by Guillaume Nodet <gn...@gmail.com>.
It does not look like the patch has been applied.  You'd have to
comment on it and push for a solution if you want it to be included
somehow.

On Wed, May 19, 2010 at 23:34, Jarek Gawor <jg...@gmail.com> wrote:
> Btw, I was referring to
> https://issues.apache.org/jira/browse/FELIX-2197. I thought parts of
> the patch were applied to Felix but I guess I was wrong.
>
> Jarek
>
> On Wed, May 19, 2010 at 5:15 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>> FWIW, I would think #3 is a good option, but I don't think Felix has
>> anything to support that (but I may be wrong).
>>
>> On Wed, May 19, 2010 at 04:41, Jarek Gawor <jg...@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
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Re: Runtime entity enhancement for OSGi applications

Posted by Jarek Gawor <jg...@gmail.com>.
Btw, I was referring to
https://issues.apache.org/jira/browse/FELIX-2197. I thought parts of
the patch were applied to Felix but I guess I was wrong.

Jarek

On Wed, May 19, 2010 at 5:15 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> FWIW, I would think #3 is a good option, but I don't think Felix has
> anything to support that (but I may be wrong).
>
> On Wed, May 19, 2010 at 04:41, Jarek Gawor <jg...@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
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>

Re: Runtime entity enhancement for OSGi applications

Posted by Guillaume Nodet <gn...@gmail.com>.
FWIW, I would think #3 is a good option, but I don't think Felix has
anything to support that (but I may be wrong).

On Wed, May 19, 2010 at 04:41, Jarek Gawor <jg...@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
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Re: Runtime entity enhancement for OSGi applications

Posted by Kevan Miller <ke...@gmail.com>.
On May 19, 2010, at 5:12 PM, David Jencks wrote:

> 
> On May 19, 2010, at 1:41 PM, Kevan Miller wrote:
> 
>> 
>> On May 19, 2010, at 4:28 PM, David Jencks wrote:
>> 
>>> 
>>> 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.
>> 
>> Right. I hope Donald is referring to the subclassing approach. Which I agree/understand is "deficient" (we've seen instances of this).
>> 
>>> 
>>> Is this stuff documented clearly somewhere in the openjpa docs?  I've never found a comprehensible explanation when I've looked in the past.
>> 
>> Try this -- http://openjpa.apache.org/builds/2.0.0/apache-openjpa-2.0.0/docs/manual/main.html
>> 
>> I don't follow section 2.2. 
> 
> I think you mean 3.5.2.2, but this is the explanation I've found that to me is difficult to understand.  I guess the ee5 runtime hooks they refer to are the method on PersistenceUnitInfo (provided by the container) where the provider can try to install a transformer. 

Oops. I pasted the wrong url. Was supposed to be http://openjpa.apache.org/builds/2.0.0/apache-openjpa-2.0.0/docs/manual/ref_guide_pc_enhance.html 

Yes. That's the section I was referring to. 

--kevan

Re: Runtime entity enhancement for OSGi applications

Posted by David Jencks <da...@yahoo.com>.
On May 19, 2010, at 1:41 PM, Kevan Miller wrote:

> 
> On May 19, 2010, at 4:28 PM, David Jencks wrote:
> 
>> 
>> 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.
> 
> Right. I hope Donald is referring to the subclassing approach. Which I agree/understand is "deficient" (we've seen instances of this).
> 
>> 
>> Is this stuff documented clearly somewhere in the openjpa docs?  I've never found a comprehensible explanation when I've looked in the past.
> 
> Try this -- http://openjpa.apache.org/builds/2.0.0/apache-openjpa-2.0.0/docs/manual/main.html
> 
> I don't follow section 2.2. 

I think you mean 3.5.2.2, but this is the explanation I've found that to me is difficult to understand.  I guess the ee5 runtime hooks they refer to are the method on PersistenceUnitInfo (provided by the container) where the provider can try to install a transformer.  

david jencks

> 
> --kevan


Re: Runtime entity enhancement for OSGi applications

Posted by Kevan Miller <ke...@gmail.com>.
On May 19, 2010, at 4:28 PM, David Jencks wrote:

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

Right. I hope Donald is referring to the subclassing approach. Which I agree/understand is "deficient" (we've seen instances of this).

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

Try this -- http://openjpa.apache.org/builds/2.0.0/apache-openjpa-2.0.0/docs/manual/main.html

I don't follow section 2.2. 

--kevan

Re: Runtime entity enhancement for OSGi applications

Posted by Donald Woods <dw...@apache.org>.

On 5/19/10 4:28 PM, David Jencks wrote:
> 
> 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.
> 

Javaagent - yes, it should be the same.
Subclassing - no, that is what we tell people not to use.

BTW - Geronimo is the only App Server that we know of that uses the
-javaagent method for enhancing....


-Donald


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

Re: Runtime entity enhancement for OSGi applications

Posted by David Jencks <da...@yahoo.com>.
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 <jg...@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
>>> 
>> 


Re: Runtime entity enhancement for OSGi applications

Posted by Kevan Miller <ke...@gmail.com>.
On May 19, 2010, at 4: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.
> 
> If we need to continue supporting this in Geronimo (for the developer
> scenarios), then I'd go with #3 for now.

Hmm. I'm confused, now. You don't mean the javaagent runtime ehancement is deficient, do you? Perhaps we have a problem with terminology?

--kevan

Re: Runtime entity enhancement for OSGi applications

Posted by Donald Woods <dw...@apache.org>.
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.

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

Re: Runtime entity enhancement for OSGi applications

Posted by Lin Sun <li...@gmail.com>.
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 <jg...@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
>

Re: Runtime entity enhancement for OSGi applications

Posted by Jarek Gawor <jg...@gmail.com>.
Sorry, if this wasn't clear. This is for OSGi based JPA applications
not regular Java EE applications.

Jarek

On Tue, May 18, 2010 at 11:11 PM, Ivan <xh...@gmail.com> wrote:
> If we know what classes are required, I am thinking we should be able add
> them while deploying the module. In the persistenceUnitBuilder, just add
> those packages in the Environment variable ?
>
> 2010/5/19 Jarek Gawor <jg...@gmail.com>
>>
>> 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
>
>
>
> --
> Ivan
>

Re: Runtime entity enhancement for OSGi applications

Posted by Ivan <xh...@gmail.com>.
If we know what classes are required, I am thinking we should be able add
them while deploying the module. In the persistenceUnitBuilder, just add
those packages in the Environment variable ?

2010/5/19 Jarek Gawor <jg...@gmail.com>

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



-- 
Ivan