aries-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Ward <>
Subject RE: OSGi JPA and JDBC Services
Date Fri, 17 Sep 2010 14:43:14 GMT

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.



> From:
> To:
> 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:
>> 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 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
View raw message