Alasdair wrote: [cut for length]
> > > 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 don't like using aries.jndi.service.name here because it has a > global scope, how about aries.jdbc.jndi.service.name? That seems reasonable. (Are there any other places where we re-register services for which we might want to support JNDI lookups? If so, we might in fact choose to make this a global pattern.) > > > > 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? > > I'd like to keep the use of osgi.jndi.service.name, even if we just > create some transformation. > > We could also transform the value as well as the service property name. This was my first thought as well, but I've had second thoughts. Transforming the value would mean that lookups of the form osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=the/name/i/hoped/i/could/use) would no longer work. So it would be a breaking change for the blog sample. (Obviously, we could then rewrite the blog sample to use a osgi:service/the/name/i/hoped/i/could/use/after/transformation lookup, which is nicer anyway, but we can't rewrite all the code out in the field which was copied from the blog sample and which would no longer work.) It's probably better to avoid the breaking change by allowing blueprints to opt in to short-form JNDI names for the transformed datasource by setting the special property. Otherwise they'll have to guess the transformed name, even to be able to do a long-form lookup like osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=the/name/i/hoped/i/could/use/after/transformation) 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
