You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@aries.apache.org by Harald Wellmann <Ha...@multi-m.de> on 2010/09/16 20:31:48 UTC
OSGi JPA and JDBC Services
I'm currently trying to make OpenJPA 2.0.1 work in an OSGi environment, and while looking for examples, I found a pointer to Apache Aries on the OpenJPA Users' mailing list.
So I had a look at the Aries website, checked out the latest code from trunk, played around with it for a couple of hours and was left with no usable result - it sort of feels like being offered a four course meal when all you were asking for was a plate of soup, and you don't even get a spoon...
All I want to do is use OpenJPA in plain old unmanaged mode and have it discover my persistence units and load classes from my application bundles without DynamicImport-Package, buddy policies or fragments. I am currently perfectly happy with Declarative Services and have no intention of converting my application to Blueprint.
Can Aries be used to achieve just that? If so, what is the minimum set of Aries bundles I need to include in my application?
I got as far as having my persistence unit discovered, but on creating an EntityManagerFactory, OpenJPA always complained about missing JTA support. Does Aries implement unmanaged JPA at all? (It is supported by the OSGi JPA spec, at any rate.) I can only see a call of PersistenceProvider.createContainerEntityManagerFactory() in Aries and no occurrence of createEntityManagerFactory(). On the OpenJPA side, there is some code related to OSGi classloaders, but again, this is just used for the managed factories and not for the unmanaged ones.
Another question: how does the Persistence Provider discover the data source - where does the magic happen so that the lookup of <jta-data-source>osgi:service:/javax.sql.DataSource</jta-data-source> will work? Is that done by Aries alone, or does the persistence provider need to be OSGi aware in this respect?
Thanks in advance for any hints!
Best regards,
Harald
RE: AW: OSGi JPA and JDBC Services
Posted by Timothy Ward <ti...@hotmail.com>.
Hi Harald,
I have two questions:
1. Are you pre-enhancing your Entity classes? This is a requirement using the base Aries JPA container as load-time weaving cannot be supported in a generic OSGi framework (although some runtimes extend the Aries code to provide this, e.g. Geronimo and WebSphere).
2. Are you listing all of your entity classes in the persistence unit definition and setting <exclude-unlisted-classes>false</exclude-unlisted-classes>? In unmanaged JPA you are supposed to do this (though many providers support scanning in unmanaged environments). In OSGi scanning doesn't work the same way, and is, once again, not supported in the Aries JPA container (though it is provided in WebSphere).
Both of these limitations will (hopefully) be lifted in the future, but they will need to rely on features proposed for version 4.3 of OSGi, and so there's not a lot we can do about them at the moment.
Regards,
Tim
----------------------------------------
> From: Harald.Wellmann@multi-m.de
> To: aries-user@incubator.apache.org
> Date: Fri, 17 Sep 2010 14:41:06 +0200
> Subject: AW: OSGi JPA and JDBC Services
>
> Thanks, Tim and Alasdair, for your clarifications - I wasn't aware of the Aries JNDI service before, and I didn't have an explicit transaction-type="RESOURCE_LOCAL" in persistence.xml.
>
> I had another try with the aries.jpa.api, aries.jpa.container and aries.util bundles added to my application. My persistence unit gets discovered, and I can see an EntityManagerFactory in the service registry. However, this factory is not usable, because of the following errors:
>
>
> 36 test.openjpa TRACE [Start Level Event Dispatcher] openjpa.MetaData - Scanning URL "bundleresource://11.fwk1603837828/" for persistent types.
> 0 test.openjpa TRACE [Start Level Event Dispatcher] openjpa.Runtime - Setting the following properties from "?" into configuration: {openjpa.BrokerFactory=jdbc, javax.persistence.validation.mode=AUTO, openjpa.RuntimeUnenhancedClasses=supported, openjpa.BrokerImpl=non-finalizing, openjpa.MetaDataFactory=jpa(URLs=bundleresource://11.fwk1603837828/, Types=test.openjpa.model.Book), openjpa.ClassResolver=org.apache.openjpa.persistence.PersistenceUnitInfoImpl$ClassResolverImpl@42f1916f, javax.persistence.sharedCache.mode=UNSPECIFIED, openjpa.jdbc.DBDictionary=org.apache.openjpa.jdbc.sql.PostgresDictionary(storeCharsAsNumbers=false), openjpa.Log=DefaultLevel=TRACE, PersistenceVersion=2.0, openjpa.Id=test.openjpa}
> 15 test.openjpa WARN [Start Level Event Dispatcher] openjpa.Runtime - An error occurred while registering a ClassTransformer with org.apache.aries.jpa.container.unit.impl.PersistenceUnitInfoImpl@69264eab. The error is logged along with this warning. Load-time class transformation will not be available.
> org.apache.commons.lang.exception.NestableRuntimeException: Error extracting class information from "bundleresource://11.fwk1603837828/".
> at org.apache.openjpa.lib.meta.ClassArgParser.parseTypeNames(ClassArgParser.java:249)
> at org.apache.openjpa.meta.AbstractCFMetaDataFactory.parsePersistentTypeNames(AbstractCFMetaDataFactory.java:724)
>
> ...
> Caused by: java.io.FileNotFoundException: /appl/plugins/test.openjpa/bin (Is a directory)
> at java.io.FileInputStream.open(Native Method)
> at java.io.FileInputStream.(FileInputStream.java:106)
> at org.eclipse.osgi.framework.util.SecureAction.getFileInputStream(SecureAction.java:124)
> at org.eclipse.osgi.baseadaptor.bundlefile.FileBundleEntry.getInputStream(FileBundleEntry.java:56)
> at org.eclipse.osgi.framework.internal.core.BundleURLConnection.connect(BundleURLConnection.java:53)
> at org.eclipse.osgi.framework.internal.core.BundleURLConnection.getInputStream(BundleURLConnection.java:99)
> at java.net.URL.openStream(URL.java:1010)
> at org.apache.openjpa.lib.util.J2DoPrivHelper$41.run(J2DoPrivHelper.java:907)
> at org.apache.openjpa.lib.util.J2DoPrivHelper$41.run(J2DoPrivHelper.java:905)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.apache.openjpa.lib.meta.URLMetaDataIterator.getInputStream(URLMetaDataIterator.java:67)
> at org.apache.openjpa.lib.meta.ClassArgParser.parseTypeNames(ClassArgParser.java:246)
>
>
>
> The problem appears to be the bundleresource://... URL returned by PersistenceUnitInfoImpl.getPersistenceUnitRootUrl(), which OpenJPA thinks is a file, not a directory. I'm not really intimate with pax-exam, but apparently it installs all bundles as JARs, whereas I'm launching Equinox directly from the Eclipse IDE, so my bundles are installed from class folders, not from JARs, which might explain why the Aries integration tests work and my setup does not...
>
> Anyway, it seems this is an issue on the OpenJPA side and not in Aries, so I'm going to cross-post this on the OpenJPA mailing list.
>
> Best regards,
>
> Harald
AW: OSGi JPA and JDBC Services
Posted by Harald Wellmann <Ha...@multi-m.de>.
Thanks, Tim and Alasdair, for your clarifications - I wasn't aware of the Aries JNDI service before, and I didn't have an explicit transaction-type="RESOURCE_LOCAL" in persistence.xml.
I had another try with the aries.jpa.api, aries.jpa.container and aries.util bundles added to my application. My persistence unit gets discovered, and I can see an EntityManagerFactory in the service registry. However, this factory is not usable, because of the following errors:
36 test.openjpa TRACE [Start Level Event Dispatcher] openjpa.MetaData - Scanning URL "bundleresource://11.fwk1603837828/" for persistent types.
0 test.openjpa TRACE [Start Level Event Dispatcher] openjpa.Runtime - Setting the following properties from "?" into configuration: {openjpa.BrokerFactory=jdbc, javax.persistence.validation.mode=AUTO, openjpa.RuntimeUnenhancedClasses=supported, openjpa.BrokerImpl=non-finalizing, openjpa.MetaDataFactory=jpa(URLs=bundleresource://11.fwk1603837828/, Types=test.openjpa.model.Book), openjpa.ClassResolver=org.apache.openjpa.persistence.PersistenceUnitInfoImpl$ClassResolverImpl@42f1916f, javax.persistence.sharedCache.mode=UNSPECIFIED, openjpa.jdbc.DBDictionary=org.apache.openjpa.jdbc.sql.PostgresDictionary(storeCharsAsNumbers=false), openjpa.Log=DefaultLevel=TRACE, PersistenceVersion=2.0, openjpa.Id=test.openjpa}
15 test.openjpa WARN [Start Level Event Dispatcher] openjpa.Runtime - An error occurred while registering a ClassTransformer with org.apache.aries.jpa.container.unit.impl.PersistenceUnitInfoImpl@69264eab. The error is logged along with this warning. Load-time class transformation will not be available.
org.apache.commons.lang.exception.NestableRuntimeException: Error extracting class information from "bundleresource://11.fwk1603837828/".
at org.apache.openjpa.lib.meta.ClassArgParser.parseTypeNames(ClassArgParser.java:249)
at org.apache.openjpa.meta.AbstractCFMetaDataFactory.parsePersistentTypeNames(AbstractCFMetaDataFactory.java:724)
...
Caused by: java.io.FileNotFoundException: /appl/plugins/test.openjpa/bin (Is a directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
at org.eclipse.osgi.framework.util.SecureAction.getFileInputStream(SecureAction.java:124)
at org.eclipse.osgi.baseadaptor.bundlefile.FileBundleEntry.getInputStream(FileBundleEntry.java:56)
at org.eclipse.osgi.framework.internal.core.BundleURLConnection.connect(BundleURLConnection.java:53)
at org.eclipse.osgi.framework.internal.core.BundleURLConnection.getInputStream(BundleURLConnection.java:99)
at java.net.URL.openStream(URL.java:1010)
at org.apache.openjpa.lib.util.J2DoPrivHelper$41.run(J2DoPrivHelper.java:907)
at org.apache.openjpa.lib.util.J2DoPrivHelper$41.run(J2DoPrivHelper.java:905)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.openjpa.lib.meta.URLMetaDataIterator.getInputStream(URLMetaDataIterator.java:67)
at org.apache.openjpa.lib.meta.ClassArgParser.parseTypeNames(ClassArgParser.java:246)
The problem appears to be the bundleresource://... URL returned by PersistenceUnitInfoImpl.getPersistenceUnitRootUrl(), which OpenJPA thinks is a file, not a directory. I'm not really intimate with pax-exam, but apparently it installs all bundles as JARs, whereas I'm launching Equinox directly from the Eclipse IDE, so my bundles are installed from class folders, not from JARs, which might explain why the Aries integration tests work and my setup does not...
Anyway, it seems this is an issue on the OpenJPA side and not in Aries, so I'm going to cross-post this on the OpenJPA mailing list.
Best regards,
Harald
RE: OSGi JPA and JDBC Services
Posted by Timothy Ward <ti...@hotmail.com>.
Another thing to note, osgi:service is a standard and aries:services is not. The design for aries:services was used as the basis for standardising the osgi:service lookup, and is a good example of what the Apache Aries project is about. In future OSGi specifications we hope to provide standards for our blueprint declarative transactions, JPA container, and many other parts of our programming model.
Regards,
Tim
________________________________
> From: not@apache.org
> To: aries-user@incubator.apache.org
> Subject: Re: OSGi JPA and JDBC Services
> Date: Fri, 17 Sep 2010 07:04:10 -0700
>
> aries:services is also a JNDI lookup scheme, it works much the same way
> as osgi:service, but osgi:service returns a proxy to the target object
> which switches out the target if it changes. aries:services does not
> proxy, you get e raw object so it is a little bit less dynamic and
> safe.
>
> Alasdair Nottingham
>
> On 17 Sep 2010, at 03:10, Bengt Rodehav
>> wrote:
>
> Have I misunderstood when I use "aries:" instead of "osgi:" or is it
> just different prefixes to the same namespace? In the JPA samples I
> cannot see in the persistence descriptor what namespace "aries:"
> actually refers to.
>
> /Bengt
>
> 2010/9/17 Timothy Ward
>
>
> Hi Harald,
>
> The Aries project aims to provide a managed programming model, and as
> such the Aries JPA runtime is not an implementation of the JPA service
> specification.
>
> As a result I'm afraid my first answer is no, Aries JPA cannot be used
> to get unmanaged JPA support, however if you declare your persistence
> units to use RESOURCE_LOCAL transactions then there shouldn't be a need
> for OpenJPA to load any JTA classes. Please let me know if OpenJPA
> continues to complain about the lack of JTA interfaces for
> RESOURCE_LOCAL persistence units and I'll try to get that fixed.
>
> For your requirements you should need two bundles from the Aries JPA
> project, the Aries JPA API bundle and the Aries JPA container bundle.
> You will also need the Aries Util bundle, which the JPA project uses.
>
> For reference, the JPA container bundles provide the following support:
>
> jpa-api :- Core interfaces used by the Aries JPA runtime
> and Service providers
> jpa-container :- The core JPA container, provides managed
> EntityManager factories for use in Application-Managed JPA
> jpa-container-context :- JPA managed persistence context support,
> allows for bundles to be registered as clients of a managed persistence
> context
> jpa-blueprint-aries :- Integration with the aries blueprint service
> providing a custom namespace for JPA resource injection
>
>
> The Aries JPA container is loosely coupled, so it is entirely possible
> to pick the bundles you need for the support you want, though each
> piece of support builds upon the previous one, so it doesn't make much
> sense to have managed persistence context support without managed
> persistence unit support.
>
> There's no need to use blueprint, Declarative Services is perfectly
> capable of retrieving EntityManagerFactory services from the service
> registry.
>
> How data sources are discovered depends upon how they are configured,
> if you use the or tag, then the
> Aries JPA container will use JNDI to get the resource registered with
> that JNDI name. In most cases you actually want to access a DataSource
> object in the service registry, which means you need the Aries JNDI
> support (available as a single bundle, or as separate core and URL
> handler bundles) which provides the osgi: namespace.
>
> If you want to specify database driver class names in the
> section of the persistence unit then the JPA provider needs to be able
> to load those drivers. I do not know whether OpenJPA has support for
> the OSGi JDBC service specification, or whether they will simply try to
> load the driver classes, and so this may not work.
>
> I hope this message has been helpful, and I agree that there is
> insufficient documentation in this area. I would be more than happy for
> any Aries users to contribute information that they find useful so that
> better documentation can be built.
>
> Regards,
>
> Tim
>
> ----------------------------------------
>> From:
> Harald.Wellmann@multi-m.de
>> To:
> aries-user@incubator.apache.org
>> Date: Thu, 16 Sep 2010 20:31:48 +0200
>> Subject: OSGi JPA and JDBC Services
>>
>> I'm currently trying to make OpenJPA 2.0.1 work in an OSGi
> environment, and while looking for examples, I found a pointer to
> Apache Aries on the OpenJPA Users' mailing list.
>>
>> So I had a look at the Aries website, checked out the latest code
> from trunk, played around with it for a couple of hours and was left
> with no usable result - it sort of feels like being offered a four
> course meal when all you were asking for was a plate of soup, and you
> don't even get a spoon...
>>
>> All I want to do is use OpenJPA in plain old unmanaged mode and have
> it discover my persistence units and load classes from my application
> bundles without DynamicImport-Package, buddy policies or fragments. I
> am currently perfectly happy with Declarative Services and have no
> intention of converting my application to Blueprint.
>>
>> Can Aries be used to achieve just that? If so, what is the minimum
> set of Aries bundles I need to include in my application?
>>
>> I got as far as having my persistence unit discovered, but on
> creating an EntityManagerFactory, OpenJPA always complained about
> missing JTA support. Does Aries implement unmanaged JPA at all? (It is
> supported by the OSGi JPA spec, at any rate.) I can only see a call of
> PersistenceProvider.createContainerEntityManagerFactory() in Aries and
> no occurrence of createEntityManagerFactory(). On the OpenJPA side,
> there is some code related to OSGi classloaders, but again, this is
> just used for the managed factories and not for the unmanaged ones.
>>
>> Another question: how does the Persistence Provider discover the data
> source - where does the magic happen so that the lookup of
> osgi:service:/javax.sql.DataSource will work? Is that done by Aries
> alone, or does the persistence provider need to be OSGi aware in this
> respect?
>>
>> Thanks in advance for any hints!
>>
>> Best regards,
>> Harald
>
>
Re: AW: OSGi JPA and JDBC Services
Posted by Alasdair Nottingham <no...@apache.org>.
Hmm, it sounds like we need to do something about that, we definitely aren't creating an application server here.
Alasdair Nottingham
On 17 Sep 2010, at 11:32, Harald Wellmann <Ha...@multi-m.de> wrote:
> I agree.
>
> I would suggest to reorganize the Aries web site a bit, to document each of the JNDI, JPA and JDBC services and to make clear(er) that you can use them without Blueprint or an Aries container.
>
> My first impression after landing on the site was "oh no, yet another non-standard application server". I know better after today's discussion, which was very helpful, but imagine how many visitors may be scared off right away without bothering to ask on the mailing list...
>
> Best regards,
>
> Harald
>
> ________________________________________
> Von: bengt.rodehav@gmail.com [bengt.rodehav@gmail.com] im Auftrag von Bengt Rodehav [bengt@rodehav.com]
> Gesendet: Freitag, 17. September 2010 19:51
> An: aries-user@incubator.apache.org
> Betreff: Re: OSGi JPA and JDBC Services
>
> Excellent documentation!
>
> /Bengt
>
AW: OSGi JPA and JDBC Services
Posted by Harald Wellmann <Ha...@multi-m.de>.
I agree.
I would suggest to reorganize the Aries web site a bit, to document each of the JNDI, JPA and JDBC services and to make clear(er) that you can use them without Blueprint or an Aries container.
My first impression after landing on the site was "oh no, yet another non-standard application server". I know better after today's discussion, which was very helpful, but imagine how many visitors may be scared off right away without bothering to ask on the mailing list...
Best regards,
Harald
________________________________________
Von: bengt.rodehav@gmail.com [bengt.rodehav@gmail.com] im Auftrag von Bengt Rodehav [bengt@rodehav.com]
Gesendet: Freitag, 17. September 2010 19:51
An: aries-user@incubator.apache.org
Betreff: Re: OSGi JPA and JDBC Services
Excellent documentation!
/Bengt
Re: OSGi JPA and JDBC Services
Posted by Bengt Rodehav <be...@rodehav.com>.
Excellent documentation!
/Bengt
2010/9/17 Alasdair Nottingham <no...@apache.org>
> Hi, you are right about the samples, it is on my todo list, but I
> haven't got to it yet.
>
> I've written some documentation as a result of your email. It isn't on
> our website yet, it needs to sync from the wiki, but you can view it
> here: https://cwiki.apache.org/confluence/display/ARIES/JNDIProject
>
> Alasdair
>
> On 17 September 2010 07:45, Bengt Rodehav <be...@rodehav.com> wrote:
> > Thanks for the clarification Alasdair,
> > Are there any samples/examples of "osgi:" I can look at. Do I need to add
> a
> > namespace in the persistent descriptor, deploy certain bundles etc?
> > Clearly, the way you describe it, "osgi:" must be preferred to "aries:".
> > Maybe the Aries samples should change to reflect that?
> > /Bengt
> >
> > 2010/9/17 Alasdair Nottingham <no...@apache.org>
> >>
> >> aries:services is also a JNDI lookup scheme, it works much the same way
> as
> >> osgi:service, but osgi:service returns a proxy to the target object
> which
> >> switches out the target if it changes. aries:services does not proxy,
> you
> >> get e raw object so it is a little bit less dynamic and safe.
> >>
> >> Alasdair Nottingham
> >> On 17 Sep 2010, at 03:10, Bengt Rodehav <be...@rodehav.com> wrote:
> >>
> >> Have I misunderstood when I use "aries:" instead of "osgi:" or is it
> just
> >> different prefixes to the same namespace? In the JPA samples I cannot
> see in
> >> the persistence descriptor what namespace "aries:" actually refers to.
> >> /Bengt
> >>
> >> 2010/9/17 Timothy Ward <ti...@hotmail.com>
> >>>
> >>> Hi Harald,
> >>>
> >>> The Aries project aims to provide a managed programming model, and as
> >>> such the Aries JPA runtime is not an implementation of the JPA service
> >>> specification.
> >>>
> >>> As a result I'm afraid my first answer is no, Aries JPA cannot be used
> to
> >>> get unmanaged JPA support, however if you declare your persistence
> units to
> >>> use RESOURCE_LOCAL transactions then there shouldn't be a need for
> OpenJPA
> >>> to load any JTA classes. Please let me know if OpenJPA continues to
> complain
> >>> about the lack of JTA interfaces for RESOURCE_LOCAL persistence units
> and
> >>> I'll try to get that fixed.
> >>>
> >>> For your requirements you should need two bundles from the Aries JPA
> >>> project, the Aries JPA API bundle and the Aries JPA container bundle.
> You
> >>> will also need the Aries Util bundle, which the JPA project uses.
> >>>
> >>> For reference, the JPA container bundles provide the following support:
> >>>
> >>> jpa-api :- Core interfaces used by the Aries JPA runtime
> >>> and Service providers
> >>> jpa-container :- The core JPA container, provides managed
> >>> EntityManager factories for use in Application-Managed JPA
> >>> jpa-container-context :- JPA managed persistence context support,
> allows
> >>> for bundles to be registered as clients of a managed persistence
> context
> >>> jpa-blueprint-aries :- Integration with the aries blueprint service
> >>> providing a custom namespace for JPA resource injection
> >>>
> >>>
> >>> The Aries JPA container is loosely coupled, so it is entirely possible
> to
> >>> pick the bundles you need for the support you want, though each piece
> of
> >>> support builds upon the previous one, so it doesn't make much sense to
> have
> >>> managed persistence context support without managed persistence unit
> >>> support.
> >>>
> >>> There's no need to use blueprint, Declarative Services is perfectly
> >>> capable of retrieving EntityManagerFactory services from the service
> >>> registry.
> >>>
> >>> How data sources are discovered depends upon how they are configured,
> if
> >>> you use the <jta-data-source> or <non-jta-data-source> tag, then the
> Aries
> >>> JPA container will use JNDI to get the resource registered with that
> JNDI
> >>> name. In most cases you actually want to access a DataSource object in
> the
> >>> service registry, which means you need the Aries JNDI support
> (available as
> >>> a single bundle, or as separate core and URL handler bundles) which
> provides
> >>> the osgi: namespace.
> >>>
> >>> If you want to specify database driver class names in the <properties>
> >>> section of the persistence unit then the JPA provider needs to be able
> to
> >>> load those drivers. I do not know whether OpenJPA has support for the
> OSGi
> >>> JDBC service specification, or whether they will simply try to load the
> >>> driver classes, and so this may not work.
> >>>
> >>> I hope this message has been helpful, and I agree that there is
> >>> insufficient documentation in this area. I would be more than happy for
> any
> >>> Aries users to contribute information that they find useful so that
> better
> >>> documentation can be built.
> >>>
> >>> Regards,
> >>>
> >>> Tim
> >>>
> >>> ----------------------------------------
> >>> > From: Harald.Wellmann@multi-m.de
> >>> > To: aries-user@incubator.apache.org
> >>> > Date: Thu, 16 Sep 2010 20:31:48 +0200
> >>> > Subject: OSGi JPA and JDBC Services
> >>> >
> >>> > I'm currently trying to make OpenJPA 2.0.1 work in an OSGi
> environment,
> >>> > and while looking for examples, I found a pointer to Apache Aries on
> the
> >>> > OpenJPA Users' mailing list.
> >>> >
> >>> > So I had a look at the Aries website, checked out the latest code
> from
> >>> > trunk, played around with it for a couple of hours and was left with
> no
> >>> > usable result - it sort of feels like being offered a four course
> meal when
> >>> > all you were asking for was a plate of soup, and you don't even get a
> >>> > spoon...
> >>> >
> >>> > All I want to do is use OpenJPA in plain old unmanaged mode and have
> it
> >>> > discover my persistence units and load classes from my application
> bundles
> >>> > without DynamicImport-Package, buddy policies or fragments. I am
> currently
> >>> > perfectly happy with Declarative Services and have no intention of
> >>> > converting my application to Blueprint.
> >>> >
> >>> > Can Aries be used to achieve just that? If so, what is the minimum
> set
> >>> > of Aries bundles I need to include in my application?
> >>> >
> >>> > I got as far as having my persistence unit discovered, but on
> creating
> >>> > an EntityManagerFactory, OpenJPA always complained about missing JTA
> >>> > support. Does Aries implement unmanaged JPA at all? (It is supported
> by the
> >>> > OSGi JPA spec, at any rate.) I can only see a call of
> >>> > PersistenceProvider.createContainerEntityManagerFactory() in Aries
> and no
> >>> > occurrence of createEntityManagerFactory(). On the OpenJPA side,
> there is
> >>> > some code related to OSGi classloaders, but again, this is just used
> for the
> >>> > managed factories and not for the unmanaged ones.
> >>> >
> >>> > Another question: how does the Persistence Provider discover the data
> >>> > source - where does the magic happen so that the lookup of
> >>> > osgi:service:/javax.sql.DataSource will work? Is that done by Aries
> alone,
> >>> > or does the persistence provider need to be OSGi aware in this
> respect?
> >>> >
> >>> > Thanks in advance for any hints!
> >>> >
> >>> > Best regards,
> >>> > Harald
> >>>
> >
> >
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
Re: OSGi JPA and JDBC Services
Posted by Alasdair Nottingham <no...@apache.org>.
Hi, you are right about the samples, it is on my todo list, but I
haven't got to it yet.
I've written some documentation as a result of your email. It isn't on
our website yet, it needs to sync from the wiki, but you can view it
here: https://cwiki.apache.org/confluence/display/ARIES/JNDIProject
Alasdair
On 17 September 2010 07:45, Bengt Rodehav <be...@rodehav.com> wrote:
> Thanks for the clarification Alasdair,
> Are there any samples/examples of "osgi:" I can look at. Do I need to add a
> namespace in the persistent descriptor, deploy certain bundles etc?
> Clearly, the way you describe it, "osgi:" must be preferred to "aries:".
> Maybe the Aries samples should change to reflect that?
> /Bengt
>
> 2010/9/17 Alasdair Nottingham <no...@apache.org>
>>
>> aries:services is also a JNDI lookup scheme, it works much the same way as
>> osgi:service, but osgi:service returns a proxy to the target object which
>> switches out the target if it changes. aries:services does not proxy, you
>> get e raw object so it is a little bit less dynamic and safe.
>>
>> Alasdair Nottingham
>> On 17 Sep 2010, at 03:10, Bengt Rodehav <be...@rodehav.com> wrote:
>>
>> Have I misunderstood when I use "aries:" instead of "osgi:" or is it just
>> different prefixes to the same namespace? In the JPA samples I cannot see in
>> the persistence descriptor what namespace "aries:" actually refers to.
>> /Bengt
>>
>> 2010/9/17 Timothy Ward <ti...@hotmail.com>
>>>
>>> Hi Harald,
>>>
>>> The Aries project aims to provide a managed programming model, and as
>>> such the Aries JPA runtime is not an implementation of the JPA service
>>> specification.
>>>
>>> As a result I'm afraid my first answer is no, Aries JPA cannot be used to
>>> get unmanaged JPA support, however if you declare your persistence units to
>>> use RESOURCE_LOCAL transactions then there shouldn't be a need for OpenJPA
>>> to load any JTA classes. Please let me know if OpenJPA continues to complain
>>> about the lack of JTA interfaces for RESOURCE_LOCAL persistence units and
>>> I'll try to get that fixed.
>>>
>>> For your requirements you should need two bundles from the Aries JPA
>>> project, the Aries JPA API bundle and the Aries JPA container bundle. You
>>> will also need the Aries Util bundle, which the JPA project uses.
>>>
>>> For reference, the JPA container bundles provide the following support:
>>>
>>> jpa-api :- Core interfaces used by the Aries JPA runtime
>>> and Service providers
>>> jpa-container :- The core JPA container, provides managed
>>> EntityManager factories for use in Application-Managed JPA
>>> jpa-container-context :- JPA managed persistence context support, allows
>>> for bundles to be registered as clients of a managed persistence context
>>> jpa-blueprint-aries :- Integration with the aries blueprint service
>>> providing a custom namespace for JPA resource injection
>>>
>>>
>>> The Aries JPA container is loosely coupled, so it is entirely possible to
>>> pick the bundles you need for the support you want, though each piece of
>>> support builds upon the previous one, so it doesn't make much sense to have
>>> managed persistence context support without managed persistence unit
>>> support.
>>>
>>> There's no need to use blueprint, Declarative Services is perfectly
>>> capable of retrieving EntityManagerFactory services from the service
>>> registry.
>>>
>>> How data sources are discovered depends upon how they are configured, if
>>> you use the <jta-data-source> or <non-jta-data-source> tag, then the Aries
>>> JPA container will use JNDI to get the resource registered with that JNDI
>>> name. In most cases you actually want to access a DataSource object in the
>>> service registry, which means you need the Aries JNDI support (available as
>>> a single bundle, or as separate core and URL handler bundles) which provides
>>> the osgi: namespace.
>>>
>>> If you want to specify database driver class names in the <properties>
>>> section of the persistence unit then the JPA provider needs to be able to
>>> load those drivers. I do not know whether OpenJPA has support for the OSGi
>>> JDBC service specification, or whether they will simply try to load the
>>> driver classes, and so this may not work.
>>>
>>> I hope this message has been helpful, and I agree that there is
>>> insufficient documentation in this area. I would be more than happy for any
>>> Aries users to contribute information that they find useful so that better
>>> documentation can be built.
>>>
>>> Regards,
>>>
>>> Tim
>>>
>>> ----------------------------------------
>>> > From: Harald.Wellmann@multi-m.de
>>> > To: aries-user@incubator.apache.org
>>> > Date: Thu, 16 Sep 2010 20:31:48 +0200
>>> > Subject: OSGi JPA and JDBC Services
>>> >
>>> > I'm currently trying to make OpenJPA 2.0.1 work in an OSGi environment,
>>> > and while looking for examples, I found a pointer to Apache Aries on the
>>> > OpenJPA Users' mailing list.
>>> >
>>> > So I had a look at the Aries website, checked out the latest code from
>>> > trunk, played around with it for a couple of hours and was left with no
>>> > usable result - it sort of feels like being offered a four course meal when
>>> > all you were asking for was a plate of soup, and you don't even get a
>>> > spoon...
>>> >
>>> > All I want to do is use OpenJPA in plain old unmanaged mode and have it
>>> > discover my persistence units and load classes from my application bundles
>>> > without DynamicImport-Package, buddy policies or fragments. I am currently
>>> > perfectly happy with Declarative Services and have no intention of
>>> > converting my application to Blueprint.
>>> >
>>> > Can Aries be used to achieve just that? If so, what is the minimum set
>>> > of Aries bundles I need to include in my application?
>>> >
>>> > I got as far as having my persistence unit discovered, but on creating
>>> > an EntityManagerFactory, OpenJPA always complained about missing JTA
>>> > support. Does Aries implement unmanaged JPA at all? (It is supported by the
>>> > OSGi JPA spec, at any rate.) I can only see a call of
>>> > PersistenceProvider.createContainerEntityManagerFactory() in Aries and no
>>> > occurrence of createEntityManagerFactory(). On the OpenJPA side, there is
>>> > some code related to OSGi classloaders, but again, this is just used for the
>>> > managed factories and not for the unmanaged ones.
>>> >
>>> > Another question: how does the Persistence Provider discover the data
>>> > source - where does the magic happen so that the lookup of
>>> > osgi:service:/javax.sql.DataSource will work? Is that done by Aries alone,
>>> > or does the persistence provider need to be OSGi aware in this respect?
>>> >
>>> > Thanks in advance for any hints!
>>> >
>>> > Best regards,
>>> > Harald
>>>
>
>
--
Alasdair Nottingham
not@apache.org
Re: OSGi JPA and JDBC Services
Posted by Bengt Rodehav <be...@rodehav.com>.
Thanks for the clarification Alasdair,
Are there any samples/examples of "osgi:" I can look at. Do I need to add a
namespace in the persistent descriptor, deploy certain bundles etc?
Clearly, the way you describe it, "osgi:" must be preferred to "aries:".
Maybe the Aries samples should change to reflect that?
/Bengt
2010/9/17 Alasdair Nottingham <no...@apache.org>
> aries:services is also a JNDI lookup scheme, it works much the same way as
> osgi:service, but osgi:service returns a proxy to the target object which
> switches out the target if it changes. aries:services does not proxy, you
> get e raw object so it is a little bit less dynamic and safe.
>
> Alasdair Nottingham
>
> On 17 Sep 2010, at 03:10, Bengt Rodehav <be...@rodehav.com> wrote:
>
> Have I misunderstood when I use "aries:" instead of "osgi:" or is it just
> different prefixes to the same namespace? In the JPA samples I cannot see in
> the persistence descriptor what namespace "aries:" actually refers to.
>
> /Bengt
>
> 2010/9/17 Timothy Ward < <ti...@hotmail.com>
> timothyjward@hotmail.com>
>
>>
>> Hi Harald,
>>
>> The Aries project aims to provide a managed programming model, and as such
>> the Aries JPA runtime is not an implementation of the JPA service
>> specification.
>>
>> As a result I'm afraid my first answer is no, Aries JPA cannot be used to
>> get unmanaged JPA support, however if you declare your persistence units to
>> use RESOURCE_LOCAL transactions then there shouldn't be a need for OpenJPA
>> to load any JTA classes. Please let me know if OpenJPA continues to complain
>> about the lack of JTA interfaces for RESOURCE_LOCAL persistence units and
>> I'll try to get that fixed.
>>
>> For your requirements you should need two bundles from the Aries JPA
>> project, the Aries JPA API bundle and the Aries JPA container bundle. You
>> will also need the Aries Util bundle, which the JPA project uses.
>>
>> For reference, the JPA container bundles provide the following support:
>>
>> jpa-api :- Core interfaces used by the Aries JPA runtime and
>> Service providers
>> jpa-container :- The core JPA container, provides managed
>> EntityManager factories for use in Application-Managed JPA
>> jpa-container-context :- JPA managed persistence context support, allows
>> for bundles to be registered as clients of a managed persistence context
>> jpa-blueprint-aries :- Integration with the aries blueprint service
>> providing a custom namespace for JPA resource injection
>>
>>
>> The Aries JPA container is loosely coupled, so it is entirely possible to
>> pick the bundles you need for the support you want, though each piece of
>> support builds upon the previous one, so it doesn't make much sense to have
>> managed persistence context support without managed persistence unit
>> support.
>>
>> There's no need to use blueprint, Declarative Services is perfectly
>> capable of retrieving EntityManagerFactory services from the service
>> registry.
>>
>> How data sources are discovered depends upon how they are configured, if
>> you use the <jta-data-source> or <non-jta-data-source> tag, then the Aries
>> JPA container will use JNDI to get the resource registered with that JNDI
>> name. In most cases you actually want to access a DataSource object in the
>> service registry, which means you need the Aries JNDI support (available as
>> a single bundle, or as separate core and URL handler bundles) which provides
>> the osgi: namespace.
>>
>> If you want to specify database driver class names in the <properties>
>> section of the persistence unit then the JPA provider needs to be able to
>> load those drivers. I do not know whether OpenJPA has support for the OSGi
>> JDBC service specification, or whether they will simply try to load the
>> driver classes, and so this may not work.
>>
>> I hope this message has been helpful, and I agree that there is
>> insufficient documentation in this area. I would be more than happy for any
>> Aries users to contribute information that they find useful so that better
>> documentation can be built.
>>
>> Regards,
>>
>> Tim
>>
>> ----------------------------------------
>> > From: <Ha...@multi-m.de>Harald.Wellmann@multi-m.de
>> > To: <ar...@incubator.apache.org>aries-user@incubator.apache.org
>> > Date: Thu, 16 Sep 2010 20:31:48 +0200
>> > Subject: OSGi JPA and JDBC Services
>> >
>> > I'm currently trying to make OpenJPA 2.0.1 work in an OSGi environment,
>> and while looking for examples, I found a pointer to Apache Aries on the
>> OpenJPA Users' mailing list.
>> >
>> > So I had a look at the Aries website, checked out the latest code from
>> trunk, played around with it for a couple of hours and was left with no
>> usable result - it sort of feels like being offered a four course meal when
>> all you were asking for was a plate of soup, and you don't even get a
>> spoon...
>> >
>> > All I want to do is use OpenJPA in plain old unmanaged mode and have it
>> discover my persistence units and load classes from my application bundles
>> without DynamicImport-Package, buddy policies or fragments. I am currently
>> perfectly happy with Declarative Services and have no intention of
>> converting my application to Blueprint.
>> >
>> > Can Aries be used to achieve just that? If so, what is the minimum set
>> of Aries bundles I need to include in my application?
>> >
>> > I got as far as having my persistence unit discovered, but on creating
>> an EntityManagerFactory, OpenJPA always complained about missing JTA
>> support. Does Aries implement unmanaged JPA at all? (It is supported by the
>> OSGi JPA spec, at any rate.) I can only see a call of
>> PersistenceProvider.createContainerEntityManagerFactory() in Aries and no
>> occurrence of createEntityManagerFactory(). On the OpenJPA side, there is
>> some code related to OSGi classloaders, but again, this is just used for the
>> managed factories and not for the unmanaged ones.
>> >
>> > Another question: how does the Persistence Provider discover the data
>> source - where does the magic happen so that the lookup of
>> osgi:service:/javax.sql.DataSource will work? Is that done by Aries alone,
>> or does the persistence provider need to be OSGi aware in this respect?
>> >
>> > Thanks in advance for any hints!
>> >
>> > Best regards,
>> > Harald
>>
>>
>
>
Re: OSGi JPA and JDBC Services
Posted by Alasdair Nottingham <no...@apache.org>.
aries:services is also a JNDI lookup scheme, it works much the same way as osgi:service, but osgi:service returns a proxy to the target object which switches out the target if it changes. aries:services does not proxy, you get e raw object so it is a little bit less dynamic and safe.
Alasdair Nottingham
On 17 Sep 2010, at 03:10, Bengt Rodehav <be...@rodehav.com> wrote:
> Have I misunderstood when I use "aries:" instead of "osgi:" or is it just different prefixes to the same namespace? In the JPA samples I cannot see in the persistence descriptor what namespace "aries:" actually refers to.
>
> /Bengt
>
> 2010/9/17 Timothy Ward <ti...@hotmail.com>
>
> Hi Harald,
>
> The Aries project aims to provide a managed programming model, and as such the Aries JPA runtime is not an implementation of the JPA service specification.
>
> As a result I'm afraid my first answer is no, Aries JPA cannot be used to get unmanaged JPA support, however if you declare your persistence units to use RESOURCE_LOCAL transactions then there shouldn't be a need for OpenJPA to load any JTA classes. Please let me know if OpenJPA continues to complain about the lack of JTA interfaces for RESOURCE_LOCAL persistence units and I'll try to get that fixed.
>
> For your requirements you should need two bundles from the Aries JPA project, the Aries JPA API bundle and the Aries JPA container bundle. You will also need the Aries Util bundle, which the JPA project uses.
>
> For reference, the JPA container bundles provide the following support:
>
> jpa-api :- Core interfaces used by the Aries JPA runtime and Service providers
> jpa-container :- The core JPA container, provides managed EntityManager factories for use in Application-Managed JPA
> jpa-container-context :- JPA managed persistence context support, allows for bundles to be registered as clients of a managed persistence context
> jpa-blueprint-aries :- Integration with the aries blueprint service providing a custom namespace for JPA resource injection
>
>
> The Aries JPA container is loosely coupled, so it is entirely possible to pick the bundles you need for the support you want, though each piece of support builds upon the previous one, so it doesn't make much sense to have managed persistence context support without managed persistence unit support.
>
> There's no need to use blueprint, Declarative Services is perfectly capable of retrieving EntityManagerFactory services from the service registry.
>
> How data sources are discovered depends upon how they are configured, if you use the <jta-data-source> or <non-jta-data-source> tag, then the Aries JPA container will use JNDI to get the resource registered with that JNDI name. In most cases you actually want to access a DataSource object in the service registry, which means you need the Aries JNDI support (available as a single bundle, or as separate core and URL handler bundles) which provides the osgi: namespace.
>
> If you want to specify database driver class names in the <properties> section of the persistence unit then the JPA provider needs to be able to load those drivers. I do not know whether OpenJPA has support for the OSGi JDBC service specification, or whether they will simply try to load the driver classes, and so this may not work.
>
> I hope this message has been helpful, and I agree that there is insufficient documentation in this area. I would be more than happy for any Aries users to contribute information that they find useful so that better documentation can be built.
>
> Regards,
>
> Tim
>
> ----------------------------------------
> > From: Harald.Wellmann@multi-m.de
> > To: aries-user@incubator.apache.org
> > Date: Thu, 16 Sep 2010 20:31:48 +0200
> > Subject: OSGi JPA and JDBC Services
> >
> > I'm currently trying to make OpenJPA 2.0.1 work in an OSGi environment, and while looking for examples, I found a pointer to Apache Aries on the OpenJPA Users' mailing list.
> >
> > So I had a look at the Aries website, checked out the latest code from trunk, played around with it for a couple of hours and was left with no usable result - it sort of feels like being offered a four course meal when all you were asking for was a plate of soup, and you don't even get a spoon...
> >
> > All I want to do is use OpenJPA in plain old unmanaged mode and have it discover my persistence units and load classes from my application bundles without DynamicImport-Package, buddy policies or fragments. I am currently perfectly happy with Declarative Services and have no intention of converting my application to Blueprint.
> >
> > Can Aries be used to achieve just that? If so, what is the minimum set of Aries bundles I need to include in my application?
> >
> > I got as far as having my persistence unit discovered, but on creating an EntityManagerFactory, OpenJPA always complained about missing JTA support. Does Aries implement unmanaged JPA at all? (It is supported by the OSGi JPA spec, at any rate.) I can only see a call of PersistenceProvider.createContainerEntityManagerFactory() in Aries and no occurrence of createEntityManagerFactory(). On the OpenJPA side, there is some code related to OSGi classloaders, but again, this is just used for the managed factories and not for the unmanaged ones.
> >
> > Another question: how does the Persistence Provider discover the data source - where does the magic happen so that the lookup of osgi:service:/javax.sql.DataSource will work? Is that done by Aries alone, or does the persistence provider need to be OSGi aware in this respect?
> >
> > Thanks in advance for any hints!
> >
> > Best regards,
> > Harald
>
>
Re: OSGi JPA and JDBC Services
Posted by Bengt Rodehav <be...@rodehav.com>.
Have I misunderstood when I use "aries:" instead of "osgi:" or is it just
different prefixes to the same namespace? In the JPA samples I cannot see in
the persistence descriptor what namespace "aries:" actually refers to.
/Bengt
2010/9/17 Timothy Ward <ti...@hotmail.com>
>
> Hi Harald,
>
> The Aries project aims to provide a managed programming model, and as such
> the Aries JPA runtime is not an implementation of the JPA service
> specification.
>
> As a result I'm afraid my first answer is no, Aries JPA cannot be used to
> get unmanaged JPA support, however if you declare your persistence units to
> use RESOURCE_LOCAL transactions then there shouldn't be a need for OpenJPA
> to load any JTA classes. Please let me know if OpenJPA continues to complain
> about the lack of JTA interfaces for RESOURCE_LOCAL persistence units and
> I'll try to get that fixed.
>
> For your requirements you should need two bundles from the Aries JPA
> project, the Aries JPA API bundle and the Aries JPA container bundle. You
> will also need the Aries Util bundle, which the JPA project uses.
>
> For reference, the JPA container bundles provide the following support:
>
> jpa-api :- Core interfaces used by the Aries JPA runtime and
> Service providers
> jpa-container :- The core JPA container, provides managed
> EntityManager factories for use in Application-Managed JPA
> jpa-container-context :- JPA managed persistence context support, allows
> for bundles to be registered as clients of a managed persistence context
> jpa-blueprint-aries :- Integration with the aries blueprint service
> providing a custom namespace for JPA resource injection
>
>
> The Aries JPA container is loosely coupled, so it is entirely possible to
> pick the bundles you need for the support you want, though each piece of
> support builds upon the previous one, so it doesn't make much sense to have
> managed persistence context support without managed persistence unit
> support.
>
> There's no need to use blueprint, Declarative Services is perfectly capable
> of retrieving EntityManagerFactory services from the service registry.
>
> How data sources are discovered depends upon how they are configured, if
> you use the <jta-data-source> or <non-jta-data-source> tag, then the Aries
> JPA container will use JNDI to get the resource registered with that JNDI
> name. In most cases you actually want to access a DataSource object in the
> service registry, which means you need the Aries JNDI support (available as
> a single bundle, or as separate core and URL handler bundles) which provides
> the osgi: namespace.
>
> If you want to specify database driver class names in the <properties>
> section of the persistence unit then the JPA provider needs to be able to
> load those drivers. I do not know whether OpenJPA has support for the OSGi
> JDBC service specification, or whether they will simply try to load the
> driver classes, and so this may not work.
>
> I hope this message has been helpful, and I agree that there is
> insufficient documentation in this area. I would be more than happy for any
> Aries users to contribute information that they find useful so that better
> documentation can be built.
>
> Regards,
>
> Tim
>
> ----------------------------------------
> > From: Harald.Wellmann@multi-m.de
> > To: aries-user@incubator.apache.org
> > Date: Thu, 16 Sep 2010 20:31:48 +0200
> > Subject: OSGi JPA and JDBC Services
> >
> > I'm currently trying to make OpenJPA 2.0.1 work in an OSGi environment,
> and while looking for examples, I found a pointer to Apache Aries on the
> OpenJPA Users' mailing list.
> >
> > So I had a look at the Aries website, checked out the latest code from
> trunk, played around with it for a couple of hours and was left with no
> usable result - it sort of feels like being offered a four course meal when
> all you were asking for was a plate of soup, and you don't even get a
> spoon...
> >
> > All I want to do is use OpenJPA in plain old unmanaged mode and have it
> discover my persistence units and load classes from my application bundles
> without DynamicImport-Package, buddy policies or fragments. I am currently
> perfectly happy with Declarative Services and have no intention of
> converting my application to Blueprint.
> >
> > Can Aries be used to achieve just that? If so, what is the minimum set of
> Aries bundles I need to include in my application?
> >
> > I got as far as having my persistence unit discovered, but on creating an
> EntityManagerFactory, OpenJPA always complained about missing JTA support.
> Does Aries implement unmanaged JPA at all? (It is supported by the OSGi JPA
> spec, at any rate.) I can only see a call of
> PersistenceProvider.createContainerEntityManagerFactory() in Aries and no
> occurrence of createEntityManagerFactory(). On the OpenJPA side, there is
> some code related to OSGi classloaders, but again, this is just used for the
> managed factories and not for the unmanaged ones.
> >
> > Another question: how does the Persistence Provider discover the data
> source - where does the magic happen so that the lookup of
> osgi:service:/javax.sql.DataSource will work? Is that done by Aries alone,
> or does the persistence provider need to be OSGi aware in this respect?
> >
> > Thanks in advance for any hints!
> >
> > Best regards,
> > Harald
>
>
RE: OSGi JPA and JDBC Services
Posted by Timothy Ward <ti...@hotmail.com>.
Hi Harald,
The Aries project aims to provide a managed programming model, and as such the Aries JPA runtime is not an implementation of the JPA service specification.
As a result I'm afraid my first answer is no, Aries JPA cannot be used to get unmanaged JPA support, however if you declare your persistence units to use RESOURCE_LOCAL transactions then there shouldn't be a need for OpenJPA to load any JTA classes. Please let me know if OpenJPA continues to complain about the lack of JTA interfaces for RESOURCE_LOCAL persistence units and I'll try to get that fixed.
For your requirements you should need two bundles from the Aries JPA project, the Aries JPA API bundle and the Aries JPA container bundle. You will also need the Aries Util bundle, which the JPA project uses.
For reference, the JPA container bundles provide the following support:
jpa-api :- Core interfaces used by the Aries JPA runtime and Service providers
jpa-container :- The core JPA container, provides managed EntityManager factories for use in Application-Managed JPA
jpa-container-context :- JPA managed persistence context support, allows for bundles to be registered as clients of a managed persistence context
jpa-blueprint-aries :- Integration with the aries blueprint service providing a custom namespace for JPA resource injection
The Aries JPA container is loosely coupled, so it is entirely possible to pick the bundles you need for the support you want, though each piece of support builds upon the previous one, so it doesn't make much sense to have managed persistence context support without managed persistence unit support.
There's no need to use blueprint, Declarative Services is perfectly capable of retrieving EntityManagerFactory services from the service registry.
How data sources are discovered depends upon how they are configured, if you use the <jta-data-source> or <non-jta-data-source> tag, then the Aries JPA container will use JNDI to get the resource registered with that JNDI name. In most cases you actually want to access a DataSource object in the service registry, which means you need the Aries JNDI support (available as a single bundle, or as separate core and URL handler bundles) which provides the osgi: namespace.
If you want to specify database driver class names in the <properties> section of the persistence unit then the JPA provider needs to be able to load those drivers. I do not know whether OpenJPA has support for the OSGi JDBC service specification, or whether they will simply try to load the driver classes, and so this may not work.
I hope this message has been helpful, and I agree that there is insufficient documentation in this area. I would be more than happy for any Aries users to contribute information that they find useful so that better documentation can be built.
Regards,
Tim
----------------------------------------
> From: Harald.Wellmann@multi-m.de
> To: aries-user@incubator.apache.org
> Date: Thu, 16 Sep 2010 20:31:48 +0200
> Subject: OSGi JPA and JDBC Services
>
> I'm currently trying to make OpenJPA 2.0.1 work in an OSGi environment, and while looking for examples, I found a pointer to Apache Aries on the OpenJPA Users' mailing list.
>
> So I had a look at the Aries website, checked out the latest code from trunk, played around with it for a couple of hours and was left with no usable result - it sort of feels like being offered a four course meal when all you were asking for was a plate of soup, and you don't even get a spoon...
>
> All I want to do is use OpenJPA in plain old unmanaged mode and have it discover my persistence units and load classes from my application bundles without DynamicImport-Package, buddy policies or fragments. I am currently perfectly happy with Declarative Services and have no intention of converting my application to Blueprint.
>
> Can Aries be used to achieve just that? If so, what is the minimum set of Aries bundles I need to include in my application?
>
> I got as far as having my persistence unit discovered, but on creating an EntityManagerFactory, OpenJPA always complained about missing JTA support. Does Aries implement unmanaged JPA at all? (It is supported by the OSGi JPA spec, at any rate.) I can only see a call of PersistenceProvider.createContainerEntityManagerFactory() in Aries and no occurrence of createEntityManagerFactory(). On the OpenJPA side, there is some code related to OSGi classloaders, but again, this is just used for the managed factories and not for the unmanaged ones.
>
> Another question: how does the Persistence Provider discover the data source - where does the magic happen so that the lookup of osgi:service:/javax.sql.DataSource will work? Is that done by Aries alone, or does the persistence provider need to be OSGi aware in this respect?
>
> Thanks in advance for any hints!
>
> Best regards,
> Harald
Re: OSGi JPA and JDBC Services
Posted by Bengt Rodehav <be...@rodehav.com>.
I've also spent a lot of time looking through the sample applications trying
to find out how JPA works with Aries. In my case I use managed JPA which I
think is closer to how the samples work. I agree with Harald that this is
pretty tough to grasp without clear and concise documentation. It would be
extremely useful with a tutorial (not a sample) where all the necessary
steps are described.
BTW I have been using "aries:" and not "osgi:" when referring to a published
service and I did not know that Aries JNDI was required for that. I thought
a namespace handler for this namespace was part of "core" Aries Blueprint.
Good evidence that better documentation is really needed.
/Bengt
2010/9/17 Alasdair Nottingham <no...@apache.org>
> On 16 September 2010 11:31, Harald Wellmann <Ha...@multi-m.de>
> wrote:
> >
> > Another question: how does the Persistence Provider discover the data
> source - where does the magic happen so that the lookup of
> <jta-data-source>osgi:service:/javax.sql.DataSource</jta-data-source> will
> work? Is that done by Aries alone, or does the persistence provider need to
> be OSGi aware in this respect?
> >
>
> The osgi:service/javax.sql.DataSource (your example had an extra : I
> removed), is a JNDI lookup into the service registry. Aries does not
> have any code for creating DataSources, but the blog and aries trader
> sample use blueprint to cause a derby datasource to be defined and
> registered, I suspect you can use DS or anything to get one
> registered. You then need the aries JNDI sub project which makes this
> all work.
>
> > Thanks in advance for any hints!
> >
> > Best regards,
> > Harald
> >
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
Re: OSGi JPA and JDBC Services
Posted by Alasdair Nottingham <no...@apache.org>.
On 16 September 2010 11:31, Harald Wellmann <Ha...@multi-m.de> wrote:
>
> Another question: how does the Persistence Provider discover the data source - where does the magic happen so that the lookup of <jta-data-source>osgi:service:/javax.sql.DataSource</jta-data-source> will work? Is that done by Aries alone, or does the persistence provider need to be OSGi aware in this respect?
>
The osgi:service/javax.sql.DataSource (your example had an extra : I
removed), is a JNDI lookup into the service registry. Aries does not
have any code for creating DataSources, but the blog and aries trader
sample use blueprint to cause a derby datasource to be defined and
registered, I suspect you can use DS or anything to get one
registered. You then need the aries JNDI sub project which makes this
all work.
> Thanks in advance for any hints!
>
> Best regards,
> Harald
>
--
Alasdair Nottingham
not@apache.org