DM server support for Java 6 classes

[tjhaz]

Hi...

I am building a webservices web module using apache cxf.

I'm running Java 6, so therefore many of the CXF dependencies are included within the JVM (javax.activation, etc).

The problem I am seeing is that the dm server does not seem to recognize the built in classes in 1.6. For example, it can't find javax.activation.DataSource which is in the rt.jar for this JVM. It shouldn't have to be added to the classpath. Is the classloader hiding the 1.6 package add-ons??

(I've done the normal troubleshooting like making sure JAVA_HOME is pointing to a valid 1.6 JDK... as well as printing out verbose info on startup)


The error/stacktrace is attached.

Thanks!

[tjhaz]

Well... after more research it is becoming clearer.

It seems that DM server has a config file called java*-server.profile that controls package exports. What is the purpose of these files? It's not clear to me after reading the documentation.

The java6-server.profile has a line 'javax.activation' in the org.osgi.framework.system.packages. Does this make it available system wide or must I still use Import-Package? Why?

Thanks!

[Glyn Normington]

The java6-server.profile file define two properties related to class loading.

The org.osgi.framework.system.packages property lists packages, such as javax.activation, that are exported by the OSGi framework's system bundle. To access these packages, a bundle must import them. The import is then resolved to the system bundle just like any other import.

On the other hand, the org.osgi.framework.bootdelegation property lists packages, in addition to packages beginning with 'java.', which are provided by the parent class loader of the framework. These packages are typically Java SE standard packages or JRE implementation specific packages that are commonly needed. For instance, some of the reflection code in the JRE assumes that 'sun.' packages are always loadable by any class loader. The package names may include wildcards, e.g. 'com.sun.*', to denote all the packages with a common prefix. To access these packages, a bundle can just use them and must not import them.

You can read more about these properties in the OSGi R4.1 specification (http://www.osgi.org/Specifications/HomePage).