Error when trying to use the OSGi Oracle driver bundle.

[setatum]

I've made my own data sources bundle in an attempt to expose data sources for my web apps. The relevant bean in my module-context.xml looks like this:

	<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource"
		p:driverClassName="oracle.jdbc.OracleDriver" p:url="${ds.url}"
		p:username="${ds.username}" p:password="${ds.password}"
		p:initialSize="${ds.initial.size}" p:maxIdle="${ds.max.idle}"
		p:maxActive="${ds.max.active}" p:maxWait="${ds.max.wait}"
		init-method="createDataSource" destroy-method="close" />

The osgi-context.xml file then exposes this bean as a service.

My MANIFEST.MF looks like this:

Manifest-Version: 1.0
Bundle-Classpath: .
Built-By: statum
Bundle-Name: Data Sources
Created-By: Apache Maven
Import-Bundle: com.springsource.oracle.jdbc;version="[10.2.0.2,10.2.0.
 2]"
Bundle-Vendor: Company
Bundle-Version: 1.0.0
Build-Jdk: 1.6.0_13
Bundle-ManifestVersion: 2
Import-Package: javax.sql;version="0",org.apache.commons.dbcp;version=
 "[1.2.2.osgi, 1.2.2.osgi]"
Bundle-SymbolicName: com.company.si.datasources
Archiver-Version: Plexus Archiver

I'm using bundlor to generate this manifest from this template.mf:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: com.company.si.datasources
Bundle-Version: 1.0.0
Bundle-Name: Data Sources
Bundle-Vendor: Company
Import-Bundle: com.springsource.oracle.jdbc;version="[10.2.0.2,10.2.0.2]"
Import-Template: javax.sql;version="0" ,
 org.apache.commons.dbcp.*;version="[1.2.2.osgi, 1.2.2.osgi]"

Though, I had to manually build the jar, pull out the generated MANIFEST.MF, then stick it in /src/main/resources/META-INF, as dm server would not pick it up otherwise, but that is another discussion.

When I attempt to deploy this bundle, I get the following error in dm server:

[2009-05-22 16:51:02.031] onnection(2)-10.102.0.26 <SPDE0018E> Unable to install application from location 'file:///C:/dmserver/stage/datasources.jar'. Could not satisfy constraints for bundle 'com.company.si.datasources' at version '1.0.0'.
 Cannot resolve: com.company.si.datasources
  Resolver report:
    Bundle: com.springsource.oracle.jdbc_10.2.0.2 - Missing Constraint: Import-Package: javax.resource; version="[1.5.0,2.0.0)"

I used STS to install the Oracle JDBC buncle. Does this mean I have something wrong in my manifest, or does it mean that the Oracle bundle provided in the SSER has a bad manifest? I viewed the manifest for the bundle and it does export javax.resource (javax.resource;version="[1.5.0, 2.0.0)"), as well as some subpackages.

Has anyone else spent hours just trying to use a data source? I'm trying not to think about how easy this was before.

-Scott

[setatum]

After a couple hours of trying different things, I eventually figured it out. I had to make two changes. First, javax.resource is not part of the dm server install - I had to download and install com.springsource.javax.resource 1.5.0. Second, I ended up with this template.mf:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: com.company.si.datasource
Bundle-Version: 1.0.0
Bundle-Name: SI Data Sources
Bundle-Vendor: Company
Import-Bundle: com.springsource.javax.resource;version="[1.5.0,1.5.0]",
 com.springsource.oracle.jdbc;version="10.2.0.2" 
Import-Package: javax.sql;version="0",
 oracle.jdbc.pool;version="10.2.0.2"

Originally I had the two Import-Bundle statements as Import-Package statements, but I would get this error:

 Cannot resolve: com.company.si.datasources
  Unsatisfied leaf constraints:
    Bundle: com.company.si.datasources_1.0.0 - Import-Package: com.springsource.javax.resource; version="[1.5.0,1.5.0]"
      Did you mean: 'com.springsource.json.parser'?

Still not sure why I need those particular Import-Package statements in addition to the Import-Bundle, but that's what bundlor told me to add, so I added them. I guess I'll figure it out as I learn more OSGi.

-Scott

[Glyn Normington]

Bundlor does not 'understand' import-bundle (which is a SpringSource specific header), so it can't tell that the import of the bundle com.springsource.oracle.jdbc is likely to provide the package oracle.jdbc.pool.

Try removing the package import of oracle.jdbc.pool and it should still work.

[setatum]

It does still work, thanks. I have a different question now though.

When I run the generation of MANIFEST.MF from template.mf within STS, it generates this manifest:

Manifest-Version: 1.0
Import-Bundle: com.springsource.javax.resource;version="[1.5.0,1.5.0]"
 ,com.springsource.oracle.jdbc;version="10.2.0.2"
Bundle-Vendor: Company
Bundle-Classpath: .
Bundle-Version: 1.0.0
Bundle-Name: SI Data Sources
Bundle-ManifestVersion: 2
Import-Package: javax.sql;version="0",oracle.jdbc.pool
Bundle-SymbolicName: com.company.si.datasources

Notice the unversioned oracle.jdbc.pool. I don't have this in my template anywhere, so as you say since Bundlor doesn't know about Import-Bundle, it thinks I'm not importing oracle.jdbc.pool and thus adds an entry.

My understanding is that at some point dmServer (or perhaps more specifically, Spring DM) expands the Import-Bundle statements into multiple Import-Package statements, which should effectively give me an Import-Package of oracle.jdbc.pool at 10.2.0.2 (and up). This is a duplicate now since Bundlor added an explicit unversioned import already. Which one gets used?

Actually, I can pull the headers for the deployed bundle from the OSGi console, and tell that the 10.2.0.2 version is what ended up there, and there is not an unversioned duplicate. Is there some rule that expanded Import-Bundle statements that conflict with Import-Package entries will take precedence?

I feel like I'm asking a Spring DM question now.

-Scott

[Glyn Normington]

No, that's most definitely a dm Server question. (You're not the only person who has confused Spring DM and SpringSource dm Server. Spring DM is the extender thing that builds application contexts from XML files in META-INF/spring whereas dm Server is the microkernel plus application server which happens to imbed Spring DM.)

When we expand import-bundle to imported packages, we merge those imported packages with any existing package imports in the manifest. This merging process includes calculating the intersection of version ranges. The default range of "0" (meaning [0,infinity)) has the pleasant property that when intersected with a range R, it produces the same range R. I think this is what you are observing. During the merge process, if some version ranges intersect to produce an empty range (i.e. a range with no elements such as [3,2)), then we throw an ImportMergeException.

[setatum]

Thanks for the clarification - the intersection of the two version ranges makes perfect sense. Good to know.

-Scott