Error using JDBC templates in SpringDM

[drudman]

Hi,
I am attempting to use the Spring JDBC templates within SpringDM, for example queryForRowset, I first get the following exception:

java.lang.NoClassDefFoundError: javax/sql/rowset/CachedRowSet
at org.springframework.jdbc.core.JdbcTemplate.queryFo rRowSet(JdbcTemplate.java:501)

It looks like the import package specified in the org.springframework.jdbc-2.5.6.A.jar bundle manifest is not being satisfied, which is 1.6 - javax.sql.rowset;version="[1.0.1, 2.0.0)
";resolution:=optional. Maybe this is due to my Java version, which is jdk1.6.0_13.

Next, if I go into org.springframework.jdbc-2.5.6.A.jar bundle manifest and remove the version constraint, the javax/sql/rowset/CachedRowSet is found, but now the following error appears:

java.lang.NullPointerException
at java.util.Properties$LineReader.readLine(Propertie s.java:418)
at java.util.Properties.load0(Properties.java:337)
at java.util.Properties.load(Properties.java:325)
at javax.sql.rowset.spi.SyncFactory.initMapIfNecessar y(SyncFactory.java:400)
at javax.sql.rowset.spi.SyncFactory.getInstance(SyncF actory.java:540)
at com.sun.rowset.CachedRowSetImpl.(CachedRowSetImpl. java:341)
at org.springframework.jdbc.core.SqlRowSetResultSetEx tractor.newCachedRowSet(SqlRowSetResultSetExtracto r.java:83)
at org.springframework.jdbc.core.SqlRowSetResultSetEx tractor.createSqlRowSet(SqlRowSetResultSetExtracto r.java:65)
at org.springframework.jdbc.core.SqlRowSetResultSetEx tractor.extractData(SqlRowSetResultSetExtractor.ja va:49)
at org.springframework.jdbc.core.JdbcTemplate$1QueryS tatementCallback.doInStatement(JdbcTemplate.java:4 48)
at org.springframework.jdbc.core.JdbcTemplate.execute (JdbcTemplate.java:396)
at org.springframework.jdbc.core.JdbcTemplate.query(J dbcTemplate.java:458)
at org.springframework.jdbc.core.JdbcTemplate.queryFo rRowSet(JdbcTemplate.java:501)



Now I am stuck. Any ideas on what I am doing wrong or how this could be resolved?

Thanks

[Glyn Normington]

Please could you provide more information about your environment. Are you running under dm Server? If so, which version of dm Server are you running on?

[drudman]

Yes, this is running as bundles under the SpringDM server. The server version is 1.0.2.

java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)

Win XP prof.

Anything else which might be relevant?

Thanks for your help.

[Glyn Normington]

javax.sql.rowset is exported by the system bundle at version 0. We have added duplicate exports for certain javax packages in the past when there is a well-defined spec. version. We could certainly consider that for javax.sql.rowset. If you think that would be helpful, please raise a user story on our JIRA system. We are unlikely to fix this in dm Server v1 however.

Meanwhile, you can easily edit the java profile file to add in a duplicate export with a suitable version number. This is more reliable than editing Spring framework JARs.

As for the NPE, it's certainly not obvious what the problem is or, indeed, whether dm Server is contributing to the problem. You might like to isolate the problem by creating a simple testcase which reproduces the NPE. Often doing this will turn up an application problem. If you can get to a simple, reproducible testcase, you could then raise a defect on our JIRA system.

Sorry not to be able to give you a simple fix...

[Andy Wilkinson]

SyncFactory is doing the following around line 400:

/*
 * Always available 
 */
ROWSET_PROPERTIES = "javax" + strFileSep + "sql" + strFileSep + "rowset" + strFileSep + "rowset.properties";
               
ClassLoader cl = Thread.currentThread().getContextClassLoader();
properties.load(cl.getResourceAsStream(ROWSET_PROPERTIES));

Line 400 is where the properties.load call is being made. I believe that the NPE is as a result of cl.getResourceAsStream returning null which, in turn, is because the thread context classloader cannot load the properties file. The comment that rowset properties will always be available is a false assumption, especially in an OSGi environment.

It would be interesting to know what the thread context class loader is before the call to JdbcTemplate is made. It may be that the solution is as simple as importing the javax.sql.rowset package in your own bundle. In my opinion, this would certainly be preferable to changing the thread context class loader which is an alternative solution.

[drudman]

Meanwhile, you can easily edit the java profile file to add in a duplicate export with a suitable version number. This is more reliable than editing Spring framework JARs.

Thanks for your help. Not exactly sure which one is the java profile file. I am guessing it is: lib/java6-server.profile? I added a version there and it did help, although now I am still stuck with the NPE.

[drudman]

Thanks for your help Andy.

It would be interesting to know what the thread context class loader is before the call to JdbcTemplate is made.

What's the best way for me to determine this, I can provide this information?

It may be that the solution is as simple as importing the javax.sql.rowset package in your own bundle. In my opinion, this would certainly be preferable to changing the thread context class loader which is an alternative solution.

I tried this, but it did not help, it would seem logical that the javax code itself would need to import this resource, the problem is I am not sure how to manipulate the base JRE code imports.

[Glyn Normington]

Thanks for your help. Not exactly sure which one is the java profile file. I am guessing it is: lib/java6-server.profile? I added a version there and it did help, although now I am still stuck with the NPE.

Yes, that's the correct file.

[Andy Wilkinson]

What's the best way for me to determine this, I can provide this information?

Thread.currentThread().getContextClassLoader() will let you access the current thread context classloader. You can then either use a debugger or just output the classloader to sysout or log it to see what it is.