Hi all,
I'm working through a variant of the blog sample at the moment. In the
blog sample we use the service property osgi.jndi.service.name to uniquely
identify the datasource services. However, in the persistence.xml, we only
use the jndi service name as a filter property, like:
<jta-data-source>osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jdbc/blogdb)</jta-data-source>
instead of writing:
<jta-data-source>osgi:service/jdbc/blogdb</jta-data-source>
It seems a shame to bother to specify the jndi.service.name property but
then not take advantage of the shorter JNDI name, but there's a good
reason we don't - it doesn't work. :)
The datasource blueprint.xml declares two services, for DataSource and
XADataSource, and then Aries helpfully auto-creates a third service, which
makes the EmbeddedXADataSource bean for lookups of the DataSource
interface.
Unfortunately, once this has been done we have two services with the same
JNDI service name. Anything which uses the JNDI name
osgi:service/jdbc/blogdb, expecting an XADataSource, gets the following
cast exception:
<openjpa-2.0.0-r422266:935683 nonfatal general error>
org.apache.openjpa.persistence.PersistenceException: $Proxy13 incompatible
with javax.sql.DataSource
at
org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:208)
at
org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java:156)
at
org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:213)
at
org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:57)
at
org.apache.aries.jpa.container.impl.CountingEntityManagerFactory.createEntityManager(CountingEntityManagerFactory.java:70)
at
org.apache.aries.jpa.container.context.transaction.impl.JTAPersistenceContextRegistry.getCurrentPersistenceContext(JTAPersistenceContextRegistry.java:131)
I have a few questions:
1. When we create the DataSource service from the XADataSource, should we
treat the osgi.jndi.service.name differently from the other properties? It
seems wrong for us to deliberately create a JNDI name clash.
2. In my testing, I found that just registering the EmbeddedXADataSource
as a javax.sql.DataSource service and not registering any services for the
XADataSource worked quite well. However, I assume there's a reason we
didn't write the sample this way. :) What's the service under the
XADataSource interface used for? The service isn't referenced in the blog
persistence.xml, so I'm assuming that the blog persistence unit never sees
it.
(For those who don't have the code in front of them, the persistence XML
only uses the DataSource services:
<jta-data-source>osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jdbc/blogdb)</jta-data-source>
<non-jta-data-source>osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jdbc/blogdbnojta)</non-jta-data-source>
If I rewrite the dataSource.xml blueprint to remove the bit in the square
brackets,
<service id="xaDataSource" ref="derbyXADataSource"
interface="javax.sql.[XA]DataSource">
<service-properties>
<entry key="osgi.jndi.service.name" value="jdbc/blogdb"/>
</service-properties>
</service>
I can rewrite the persistence.xml to
<jta-data-source>osgi:service/jdbc/blogdb)</jta-data-source>
<non-jta-data-source>osgi:service/jdbc/blogdbnojta)</non-jta-data-source>
without apparent ill effects, *and* the Aries container has to do less
work. I assume I'm not hitting some important scenario in my test
coverage, but I'm not sure what it is.)
Holly
--
Holly Cummins
OSGi Applications
IBM Hursley, UK
[email protected]
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
