On 3/24/14, 17:18 , [email protected] wrote:
Thanks for your advice Richard. How could this be solved with a more recent
framework release in detail? Despite the fact that we are currently not able to
update to a higher version of Felix, I'm interested to see how OpenJPA would
fit into future product releases.
Well, I won't go into too much detail, since I only glanced at the
patch, but it appears that it tries to access outstanding module
revisions using internal Felix framework API, but now this is possible
using Bundle.adapt(BundleRevisions.class) and from each BundleRevision
you can now get a BundleWiring from which you can get the class loader
associated with the bundle.
It looks like that's all your patch needed, but I could be missing
something. If that's all, then this can be supplied in a bundle outside
of the framework...
-> richard
You are right. We use CQ 5.5 with Apache Felix 3.0.8.
Regards,
Dirk
-----Ursprüngliche Nachricht-----
Von: Richard S. Hall [mailto:[email protected]]
Gesendet: Montag, 24. März 2014 19:01
An: [email protected]
Betreff: Re: OpenJPA Support in Apache Felix
This code looks to be based on a fairly old version of the framework...I would
guess version 3.x, which is prior to OSGi R4.3. You need to do some updates to
get this to work with the latest framework releases (now version 4.4). Further,
I think that OSGi R4.3 introduced some changes that might make it possible to
do this all outside the framework as a bundle now, such as getting access to
bundle revisions (i.e., modules) and their class loaders.
In light of that, I'd say it would be better to consider donating this as a
stand-alone bundle to Apache OpenJPA...
-> richard
On 3/24/14, 06:28 , [email protected] wrote:
Hi all,
in our current project, we intensively use database access to store
information and share it between different (not clustered) instances.
As for the persistence layer, we use Apache OpenJPA in an Apache Felix
container (CQ5.5) with Apache Aries bundles installed. The setting up
faced out some problems related to the special ClassLoader scenario in
the OSGI environment. For a detailed related previous discussion have
a look at [1] and [2].
To sum up, the most frustrating problem was that the Classes loaded by
a special ModuleClassLoader could not be collected by the GC. So, the
static PCRegistry of OpenJPA referenced Classes, whose ClassLoader has
been closed/invalidated by Felix before and on any further access on
these Classes, caused NoClassDefFoundErrors.
To solve this issue we implemented a framework extension that
registers a BundleListener, cleaning up the PCRegistry every time a
Bundle is updated. This code we would like to contribute and any
comments are appreciated.
[1]
http://mail-archives.apache.org/mod_mbox/openjpa-dev/200707.mbox/%3CFB
[email protected]%3E
[2] https://issues.apache.org/jira/browse/OPENJPA-285
Kind regards,
*Dirk Rudolph *
T-Systems Multimedia Solutions GmbH
Organisationseinheit CCS
Dirk Rudolph
Software-Entwicklung, OCJP
Hausanschrift: Riesaer Straße 5, 01129 Dresden
Postanschrift: Postfach 10 02 24, 01072 Dresden
+49 351 2820-5363 (Tel)
E-Mail:[email protected]
<mailto:[email protected]>
Internet: http://www.t-systems-mms.com <http://www.t-systems-mms.de/>
T-Systems Multimedia Solutions GmbH
Aufsichtsrat: Thilo Kusch (Vorsitzender)
Geschäftsführung: Peter Klingenburg, Susanne Heger, Dr. Rolf Werner
Handelsregister: Amtsgericht Dresden HRB 11433 Sitz der Gesellschaft:
Dresden
Ust-IdNr.: DE 811 807 949
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
