I have a Virgo OSGi project that uses Spring Web Services and other Spring projects related to web services security. When I attempt to deploy my bundle to Virgo, I get the following error:
An Import-Package could not be resolved. Caused by missing constraint in bundle <gov.noaa.nws.iris.OasisCapServiceImpl_0.0.1>
constraint: <Import-Package: org.springframework.ws.soap.security.wss4j; version="0.0.0">
An Import-Package could not be resolved. Caused by missing constraint in bundle <org.springframework.ws.soap.security_2.0.0.RELEASE>
constraint: <Import-Package: com.sun.xml.wss; version="0.0.0">
An Import-Package could not be resolved. Caused by missing constraint in bundle <com.springsource.com.sun.xml.wss_2.0.0.FCS>
constraint: <Import-Package: com.sun.org.apache.xml.internal.security.algorithms; version="0.0.0">
The last Import-Package error is causing the previous two Import-Package errors. It says it can't find the com.sun.org.apache.xml.internal.security.algorithms package which is part of standard Java. Virgo's lib/java6-server.profile file contains the following:
which I thought meant that the com.sun.org.apache.xml.internal.security.algorithms package should be available.
Am I missing something? Do I not understand what the entries in Virgo's lib/java6-server.profile really do?
Note that there are a couple of properties in java6-server.profile which are relevant here. You are seeing com.sun.* in the boot delegation property.
Essentially for packages available from the application class loader (AKA the "system" class loader) such as those included in the JRE, bundles either have to import them and you need to ensure they are exported from the system bundle by changing the org.osgi.framework.system.packages property in java6-server.profile or you need to boot delegate them and bundles must then not import them.
So I think the solution is to add the relevant package(s) to the org.osgi.framework.system.packages property. This will allow resolution to succeed. I think you can still boot delegate com.sun.* as this will simply short-circuit the class loading algorithm for the relevant packages and they'll be loaded using the application/"system" class loader.
Just out of curiosity, what/who determines the packages included in org.osgi.framework.system.packages by default? Are they limited to more commonly used packages? Is there an advantage to limiting the number of packages listed there?... Why not just list all JRE packages in there?