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