Hi Brian, Thanks for the response. I've added some comments below:
[cut for length] > The dataSource blueprint.xml file is meant to be the equivalent of the > configuration that you would provide to an application server when > configuring data sources, i.e. this is the way that the data source is > configured to use a particular jndi name. This name is then copied to the > data source that the application uses (see below). My concern is that copying the JNDI name to the data source that the application uses doesn't have the intended effect, because the datasource can't actually be looked up using that JNDI name. So instead of providing the equivalent of the configuration you'd provide to the application server, you provide a broken-ish configuration. In order to disambiguate between the javax.sql.DataSource and the javax.sql.XADataSource which both have the same osgi.jndi.service.name property, a full OSGi service lookup is required: osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=the/name/i/hoped/i/could/use) If we can't use the osgi.jndi.service.name to infer a usable JNDI name, we should perhaps use some other, arbitary, property in the sample. Otherwise the samples are misleading. > > > 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. > > This may work fine for the blog sample, but if you have an application that > needs to participate in XA transactions then you need to provide an > XADataSource so that the transaction wrappers bundle can detect it and > create a DataSource capable of enlisting in XA transactions for the > application to use. I guess what I was struggling to understand was why an EmbeddedXADataSource wasn't able to participate in XA transactions. I understand now that - despite its name - the EmbeddedXADataSource isn't capable of the full XA support we need and that it needs to be wrapped in a fuller featured datasource. That's the piece I was missing. I do think we need some improvement in this area. One option is just to replace the misleading use of osgi.jndi.service.name in the sample with another property which can be still used as a filter but doesn't suggest the datasources can be looked up by friendly JNDI names. An alternative (thanks Tim!), if we do want to enable the 'short-form' JNDI names, is that we set a property something like 'aries.jndi.service.name' on the javax.sql.XADataSource. When Aries registers the javax.sql.DataSource, it could turn the 'aries.jndi.service.name' into the 'osgi.jndi.service.name'. This would enable the short-form JNDI lookup while avoiding the name clash. I'll raise a JIRA either to rewrite the sample or provide support for datasource lookups of the form osgi:service/the/name/i/hoped/i/could/use with an extra property. Do people have a preference between these two options? Or any other thoughts? [cut for length] Holly 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
