aries-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alasdair Nottingham <>
Subject Re: OSGi JPA and JDBC Services
Date Fri, 17 Sep 2010 16:49:48 GMT
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


On 17 September 2010 07:45, Bengt Rodehav <> 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 <>
>> 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
>>> 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:
>>> > To:
>>> > 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
>>> > 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
>>> > 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

View raw message