Develop Reference

NoClassDefFoundError for com.sun.xml.internal.ws.fault.SOAPFaultBuilder

Our web service client in live environment recently got the exception:
java.lang.NoClassDefFoundError: Could not initialize class com.sun.xml.internal.ws.fault.SOAPFaultBuilder
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:107)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:135)
at com.sun.proxy.$Proxy146.search(Unknown Source)
....
I've done a lot of search online, including a few posts here at StackOverflow:
Catching webservice exception with CXF: NoClassDefFoundError: SOAPFaultBuilder
Could not initialize class com.sun.xml.internal.ws.fault.SOAPFaultBuilder
java.lang.NoClassDefFoundError: Could not initialize class com.sun.xml.internal.ws.fault.SOAPFaultBuilder
And my understanding was our client received a SOAP Fault from the server and it's missing some jar file. So I'm trying to solve the problem by first recreating it.
I created a simple Web Service server project in Eclipse which has a web method throws a simple fault class annotated by #WebFault. Then I created a simple Web Service client project which consumes the web method. The client project doesn't have any additional libraries/jars in its classpath; all it has is the JRE. To my surprise, it didn't throw the NoClassDefFoundError exception! Instead, I got the javax.xml.ws.soap.SOAPFaultException I defined on the server side.
The class SOAPFaultBuilder is indeed in rt.jar in JRE. So the simple web service projects I created probably just work as they should. However, how come the web service client in our live environment throw the NoClassDefFoundError exception? That project definitely has rt.jar in the classpath.
Can anyone please shed some light on this problem? If it's missing some jar files (either from the jaxws RI or Apache CXF or others), why would the super simple client I created didn't throw the error? Both the live environment and my local environment use Java7u51.

I have encountered the same problem and I could subsequently resolve this.
Due to the following error mentioned in the Problem, the underlying cause of the SOAP Fault could not be found.
I followed the steps mentioned in the following link, to identify the reason for NoClassDefFoundError.
http://javarevisited.blogspot.in/2011/06/noclassdeffounderror-exception-in.html
I could find the following errors in my application log:
java.lang.ExceptionInInitializerError
Caused by: java.lang.ClassCastException: com.sun.xml.bind.v2.runtime.JAXBContextImpl cannot be cast to com.sun.xml.internal.bind.api.JAXBRIContext
The reason for the above classcast exception is due to conflicting jar files.
rt.jar (this is present in jre classpath)
jaxb-impl-2.0.1.jar (this is present in my application classpath).
I have removed the file jaxb-impl-2.0.1.jar from my classpath and the actual error is gone.

I had the same erorr and I resolved this issue by deleting the jax-impl.jar from the tomcat lib folder. It was a possible conflict of the jaxb jar versions with one of my webapps installed in tomcat.
http://programtalk.com/java/i-was-running-gwt-application-on-tomca/

Unable to add jar to OSGi bundle

Yet another silly question. I am sure it is something easy, but that already took me a lot of time and I don't get it working ;(
I have a written a working prototype to make a rest call to a server. To do this I utilize "jersey-client-1.14.jar". That works quite well by adding it to the eclipse projects class path.
Now I am trying to do the same in an OSGi bundle. These were the steps I did:
I created a /lib folder in my OSGi bundle project.
Added the jersey-client-1.14.jar in that folder.
Added the jar in the MANIFEST.MF in the classpath: Bundle-ClassPath: ., lib/jersey-client-1.14.jar
Checked that it was also correctly added to the projects classpath.
In the Eclipse workspace I have no compiling errors.
At runtime I have the phenomenon that I get a classdef not found exception when creating the jersey client with Client.create();
!ENTRY org.eclipse.equinox.event 4 0 2012-11-08 23:14:43.975
!MESSAGE Exception while dispatching event org.osgi.service.event.Event [topic=openhab/command/Hue_Bulb_2] to handler org.openhab.binding.hue.internal.HueBinding#70f5f42b
!STACK 0
java.lang.NoClassDefFoundError: Could not initialize class com.sun.jersey.spi.service.ServiceFinder
at com.sun.jersey.api.client.Client.init(Client.java:213)
at com.sun.jersey.api.client.Client.access$000(Client.java:118)
at com.sun.jersey.api.client.Client$1.f(Client.java:191)
at com.sun.jersey.api.client.Client$1.f(Client.java:187)
at com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:193)
at com.sun.jersey.api.client.Client.(Client.java:187)
at com.sun.jersey.api.client.Client.(Client.java:159)
at com.sun.jersey.api.client.Client.create(Client.java:669)
at org.openhab.binding.hue.internal.bridge.HueBridge.getSettingsJson(HueBridge.java:64)
at org.openhab.binding.hue.internal.bridge.HueBridge.pairBridgeIfNecessary(HueBridge.java:19)
at org.openhab.binding.hue.internal.HueBinding.receiveCommand(HueBinding.java:37)
at org.openhab.core.events.AbstractEventSubscriber.handleEvent(AbstractEventSubscriber.java:62)
at org.eclipse.equinox.internal.event.EventHandlerWrapper.handleEvent(EventHandlerWrapper.java:197)
at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:197)
at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:1)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
at org.eclipse.equinox.internal.event.EventAdminImpl.dispatchEvent(EventAdminImpl.java:135)
at org.eclipse.equinox.internal.event.EventAdminImpl.sendEvent(EventAdminImpl.java:78)
at org.eclipse.equinox.internal.event.EventComponent.sendEvent(EventComponent.java:39)
at org.openhab.core.internal.events.EventPublisherImpl.sendCommand(EventPublisherImpl.java:76)
at org.openhab.ui.webapp.internal.servlet.CmdServlet.service(CmdServlet.java:115)
at org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(ServletRegistration.java:61)
at org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:128)
at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:60)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:598)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:486)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111)
at org.eclipse.jetty.server.Server.handle(Server.java:350)
at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454)
at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890)
at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:630)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:77)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:606)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:46)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:603)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:538)
at java.lang.Thread.run(Thread.java:680)
23:14:43.992 ERROR OSGi[:98] - Exception while dispatching event org.osgi.service.event.Event [topic=openhab/command/Hue_Bulb_2] to handler org.openhab.binding.hue.internal.HueBinding#70f5f42b
java.lang.NoClassDefFoundError: Could not initialize class com.sun.jersey.spi.service.ServiceFinder
at com.sun.jersey.api.client.Client.init(Client.java:213)
at com.sun.jersey.api.client.Client.access$000(Client.java:118)
at com.sun.jersey.api.client.Client$1.f(Client.java:191)
at com.sun.jersey.api.client.Client$1.f(Client.java:187)
at com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:193)
at com.sun.jersey.api.client.Client.(Client.java:187)
at com.sun.jersey.api.client.Client.(Client.java:159)
at com.sun.jersey.api.client.Client.create(Client.java:669)
at org.openhab.binding.hue.internal.bridge.HueBridge.getSettingsJson(HueBridge.java:64)
at org.openhab.binding.hue.internal.bridge.HueBridge.pairBridgeIfNecessary(HueBridge.java:19)
at org.openhab.binding.hue.internal.HueBinding.receiveCommand(HueBinding.java:37)

You'll also need to add jersey-core to you bundle's classpath, as jersey-client has it as a dependency.
You might alos have to add other dependencies if needed. The process is rather easy if not pleasant:
Add a jar
Run the app
See what class is not found, find the jar where that class lives, add it to the bundle classpath, go back to 2
One thing though: Jersey jars are OSGi-ready, so you might as well just add jersey-client.jar and jersey-core.jar to your taget platform and import the required packages.

Looking at your secondary queries I think you just want to know what is going on :-)
OSGi fences JARs to create modules. By default, the fence is impenetrable, no classes outside the bundle (the jar) are visible (being able to load a class from) to classes on the inside, and outsiders cannot see anything inside the bundle. The advantage should be obvious: you can change the inside to your hearts delight since nothing is known outside.
However, in real life you need some holes in the fence to be able to collaborate with others. In your case a bundle tries to load com.sun.jersey.spi.service.ServiceFinder but it runs into the fence because there is no appropriate hole.
The "holes" in OSGi are packages, these are the shared atoms. You list these packages in the manifest. The Import-Package header indicates the packages that you need to see from the outside world and the Export-Package header defines what packages (and under what version) the packages are visible to other bundles.
Obviously you do not want to manually calculate the imports since these are already in your class files, for this reason there is a tool bnd (I am the author) that can be used from maven, ant, gradle, etc. It takes a recipe and calculates the resulting bundle with proper metadata. This tool is extensively supported with the bndtools Eclipse plugin, which is a very nice environment to learn more about OSGi and these issues.

Sir, in eclipse you have been added different package like.
com.sun.jersey.spi.service.ServiceFinder . to start ur service you have to start other service. on which you bundle is dependent.
like i have an jar, which is depependent on rxtxcomm_api-2.1.7.jar.
i had to initialize it or you can say intiat it. before my service. please check it.

Embedding jars is a bad style in OSGi. Generally you should only do this if there is no other way. Embedding jars will easily lead to classpath problems as packages then may come from different bundles. Is there a special reason why you want to embed the jar?
Jersey is fully OSGi ready since version 1.2. See the documentation for examples how to use it.

Most OSGi containers come with a JAX-RS implementation out-of-the-box - being Jersey or what-not. For instance, we're using Apache ServiceMix, which conveniently provides Apache CXF.
What container are you using?
Do you really have to bundle Jersey with your application?
If you need to bundle Jersey for whatever reason, can you please provide an example of your manifest file.
Have you considered using the Maven-Bundle-Plugin?

REST client inside of OSGi application

I need to integrate a REST client into an existing OSGi application implemented using Apache Felix. The REST service is based on RESTeasy implementation (version 2.3.2.Final) of JAX-RS. I created a separate bundle with clients' dependencies, exporting required RESTeasy packages and importing them in the bundle where the client is used, but unfortunately I cannot get it working inside of the OSGi context.
I tried two different approaches. First one using the generic ClientRequest:
ClientRequest request = new ClientRequest(MyService.URL_TEST+"/stats");
request.body(javax.ws.rs.core.MediaType.APPLICATION_XML, stats);
ClientResponse<String> response = request.post(String.class);
The error that I get in this case is pretty weird:
[java] java.lang.RuntimeException: java.lang.ClassCastException:
org.jboss.resteasy.client.core.executors.ApacheHttpClient4Executor cannot be cast to
org.jboss.resteasy.client.ClientExecutor
where I it is known for sure that ApacheHttpClient4Executor implements the ClientExecutor interface.
When I try to use my own REST client wrapper around RESTeasy like this:
MyService myService = MyServiceClient.getInstance();
myService.saveStatistics(stats);
I get a different exception:
[java] java.lang.LinkageError: ClassCastException: attempting to
castjar:file:/D:/Development/Eclipses/eclipse_4.2_j2ee_x64/lib/jaxrs-api-2.3.2.Final.jar
!/javax/ws/rs/ext/RuntimeDelegate.classtobundle:
//78.0:1/javax/ws/rs/ext/RuntimeDelegate.class
As far as I understand, the LinkageError most probably has to do with the way RESTeasy initializes the RuntimeDelegate using some classloader tricks, which probably fall under the restrictions of OSGi framework. I get the suspicion that the java.lang.ClassCastException mentioned first has the same source.
Is there any way to get RESTeasy working inside of OSGi?
PS: discussion about a similar issue with RESTeasy, but outside of OSGi: java.lang.LinkageError: ClassCastException
Update:
these are the libraries included into restclient bundle:
activation-1.1.jar commons-codec-1.2.jar commons-httpclient-3.1.jar commons-io-2.1.jar commons-logging-1.0.4.jar flexjson-2.1.jar httpclient-4.1.2.jar httpcore-4.1.2.jar javassist-3.12.1.GA.jar jaxb-api-2.2.3.jar jaxb-impl-2.2.4.jar jaxrs-api-2.3.2.Final.jar jcip-annotations-1.0.jar jettison-1.3.1.jar jsr250-api-1.0.jar junit-4.10.jar log4j-1.2.14.jar resteasy-jaxb-provider-2.3.2.Final.jar resteasy-jaxrs-2.3.2.Final.jar resteasy-jettison-provider-2.3.2.Final.jar scannotation-1.0.3.jar slf4j-api-1.6.4.jar slf4j-log4j12-1.6.4.jar myservice-common-0.1.0.3.jar my-service-client-0.1.0.3-SNAPSHOT.jar stax-api-1.0-2.jar xmlpull-1.1.3.1.jar xpp3_min-1.1.4c.jar xstream-1.4.2.jar
These are the exports from the restclient bundle: javax.ws.rs, javax.ws.rs.ext, javax.ws.rs.core, org.jboss.resteasy.client, org.jboss.resteasy.client.cache, org.jboss.resteasy.client.extractors, org.jboss.resteasy.client.marshallers, org.jboss.resteasy.client.core.executors, javax.xml.bind.annotation, org.jboss.resteasy.plugins.providers, org.jboss.resteasy.plugins.providers.jaxb, org.jboss.resteasy.spi

Have a look at the SpringSource Bundle Repo, it's got some very useful pre-built bundles of common libraries including the Apache HTTP Client which we are using (in conjunction with gson) to do our RESTful comms.

(unfortunately a legacy module of my project still uses OSGi, but using RESTeasy 3.0.16 now)
When I need to OSGify a dependency my preferred solution now is to wrap it using the excellent Apache Ops4j Pax Tipi project.
The project provides a preconfigured Maven setup (parent POM handles the bundling) and you just have to adapt the GAV coordinates of the original project in a Tipi sub module with a org.apache.ops4j.pax.tipi prefix and build the new bundle project which draws in the original dependency, unpacks and wraps it as OSGi bundle.
You can start from an existing Tipi sub project that best matches your project setup (dependencies, etc.) and adapt any OSGi imports/exports missing (most often, these are created automatically by the maven-bundle-plugin anyway).
This worked quite well for me as long as the original project did not contain too many exotic or malformed dependencies.
However you may run into snags like transitive dependencies using the root package, as I currently experience, which can be a real show stopper (finding out which library is a real nightmare).
Unfortunately, RESTeasy seems to be affected by this, as I get exactly the same error (default package , even after declaring non-test and non-provided dependencies as optional:
The default package '.' is not permitted by the Import-Package syntax.
Upgrading the maven-bundle-plugin to the latest release 3.0.1 yields a different error (even less helpful):
[ERROR] Bundle org.ops4j.pax.tipi:org.ops4j.pax.tipi.resteasy-jaxrs:bundle:3.0.16.Final.1 : Can not parse name from bundle native code header:
[ERROR] Error(s) found in bundle configuration
Update seems to be solved by upping Tipi version in POM to 1.4.0, testing...

Is RESTEasy mandatory ?
I personally use jersey in OSGi and it is working perfectly, both as client and server.

This problem isn't limited to RESTeasy. It also occurs with Jersey.
It is occurring because you have two copies of the JAX-RS classes on the classpath.
You can see this in the LinkageError:
[java] java.lang.LinkageError: ClassCastException: attempting to cast jar:file:/D:/Development/Eclipses/eclipse_4.2_j2ee_x64/lib/jaxrs-api-2.3.2.Final.jar!/javax/ws/rs/ext/RuntimeDelegate.class to bundle://78.0:1/javax/ws/rs/ext/RuntimeDelegate.class
i.e. one copy is coming from:
D:/Development/Eclipses/eclipse_4.2_j2ee_x64/lib/jaxrs-api-2.3.2.Final.jar
and the other from the OSGI bundle.
This causes problems for the RuntimeDelegate class, which by default uses the system class loader to create the RuntimeDelegate implementation (see javax.ws.rs.ext.FactoryFinder).
The problem can also occur if the same jar is loaded via two different class loaders.
There are a couple of workarounds:
remove the jaxrs-api-2.3.2.Final.jar from the system class path
set the thread context class loader to that of your bundle, prior to making any JAX-RS calls.
The FactoryFinder will use this to load the RuntimeDelegate.
To avoid polluting your code with calls to Thread.currentThread().setContextClassLoader(myBundleClassLoader), you can wrap your JAX-RS client using a Proxy. e.g. see the Thread context classloader section of https://puredanger.github.io/tech.puredanger.com/2007/06/15/classloaders/

How to dynamically load Java classes at Runtime in OSGI framework?

We are performing a POC in our project, where in we send SOAP based request and correspondingly get a SOAP response from a web service. We aim to leverage webservices template (client side API) provided by spring framework in our application. As per our architecture, we create an OSGI compliant bundle (for our code that uses webservices template API to interact with the web service) which is then deployed into the Apache Felix container. We have also installed all the dependent OSGI compliant bundles in the Felix container so that all the dependencies are resolved.
As per the webservices template, the default Web Service Message sender is HttpUrlConnectionMessageSender which is dynamically loaded at run time by the class loader. As per my understanding, we are getting the below exception because the Felix container is not able to load the class from the dependent OSGI bundle (web services bundle contains the HttpUrlConnectionMessageSender).Please refer to the exception logs below.
* org.springframework.beans.factory.BeanInitializationException: Could not find default strategy class for interface [org.springframework.ws.transport.WebServiceMessageSender]; nested exception is java.lang.ClassNotFoundException:org.springframework.ws.transport.http.HttpUrlConnectionMessageSender at org.springframework.ws.support.DefaultStrategiesHelper.getDefaultStrategies(DefaultStrategiesHelper.java:126)
at org.springframework.ws.support.DefaultStrategiesHelper.getDefaultStrategies(DefaultStrategiesHelper.java:90)
at org.springframework.ws.client.core.WebServiceTemplate.initMessageSenders(WebServiceTemplate.java:320)
at org.springframework.ws.client.core.WebServiceTemplate.initDefaultStrategies(WebServiceTemplate.java:306)
at org.springframework.ws.client.core.WebServiceTemplate.<init>(WebServiceTemplate.java:143)
at test.soapservice.service.SOAPServiceImpl.<init>(SOAPServiceImpl.java:40)
at test.soapservice.service.SOAPServiceActivator.start(SOAPServiceActivator.java:17)
at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:641)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1977)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1895)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
at org.apache.felix.gogo.command.Basic.start(Basic.java:729)
Caused by: java.lang.ClassNotFoundException: org.springframework.ws.transport.http.HttpUrlConnectionMessageSender
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at org.springframework.util.ClassUtils.forName(ClassUtils.java:211)
at org.springframework.util.ClassUtils.forName(ClassUtils.java:164)
at org.springframework.ws.support.DefaultStrategiesHelper.getDefaultStrategies(DefaultStrategiesHelper.java:114)
As per my understanding,Felix container is unable to dynamically load the class using ClassUtils.forName() which exists in another bundle. I see this as a collaboration issue where the current bundle has a different class loader as opposed to class loader of dependent bundle.
Did someone from this community have encountered the same exception? If yes, then what were steps taken by you to resolve the run time class dependency? Please share your thoughts/pointers to resolve the above issue.A quick response would be highly appreciated and may help us to make our POC successful.
Thanks in advance,
Mridul Chopra

Classloading in the form of Class.forName() is not a problem in any OSGi container. You problem here is that the MANIFEST.MF file does not contain the right import declarations. One bundle should export the org.springframework.ws.transport package, while your bundle should import the same package.
If you are using Maven to build your bundle, you can use the Felix Bundle Plugin to generate the right manifest information.
<plugins>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<Private-Package>my.private.package.*</Private-Package>
</instructions>
</configuration>
</plugin>
</plugins>
This should inspect your code and add imports for anything that is not inside your "private" package scope. One other thing you should do to make this work is to set the packaging type to bundle.
<packaging>bundle</packaging>
But, the examples above is when you are using Maven as a build tool. If you are using Gradle, you can use the Gradle OSGi plugin to build manifest. Or, if using Ant you can use SpringSource Bundlor project (btw, which also has a Maven plugin).

java.util.logging, ResourceBundles, SAAJ: exception on loading Glassfish OSGi webapp bundle

I'm being driven out of my mind by the following exception:
java.lang.IllegalArgumentException:
com.sun.xml.messaging.saaj.soap.LocalStrings != com.sun.xml.internal.messaging.saaj.soap.LocalStrings
at java.util.logging.Logger.getLogger(Logger.java:357)
at com.sun.xml.internal.messaging.saaj.soap.SAAJMetaFactoryImpl.<clinit>(SAAJMetaFactoryImpl.java:41)
It's occurring when I try to deploy a WAB (web application OSGi bundle) to Glassfish (3.1.1).
I'm trying to use an up-to-date version of SAAJ (com.sun.xml.messaging.saaj...) rather than the old JDK one (which is the com.sun.xml.internal.saaj... one), by putting the string com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl in the file META-INF/services/javax.xml.soap.MessageFactory.
It appears there is some logging going on before the OSGi classloading kicks in, and therefore the 'wrong' ResourceBundle is being returned during initialization of the static log field of com.sun.xml.messaging.saaj.soap.MessageFactoryImpl (SAAJ's implementation of javax.xml.soap.MessageFactory).
Anyone seen this / any workarounds on offer?

Never got to the bottom of this, but manifest voodoo eventually made it go away (with all of the javax.xml.ws / javax.ws.rs packages in Import-Package rather than on the bundle classpath WEB-INF/lib).
It was also possible to work around it by using
-Djavax.xml.soap.MessageFactory=com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl
on Glassfish startup, though obviously this forces that implementation on all users of MessageFactory.

See: JDK-6741342 : Logger.getLogger() throws java.lang.IllegalArgumentException on saaj classes.
Instead, it's related to the introduction of saaj into JDK 6.....and the workaround involved re-ordering jars.