search

ops4j / org.ops4j.pax.runner

Multi Framework OSGi Runner
http://team.ops4j.org/wiki/display/paxrunner/
47 stars 39 forks source link

com.sun packages not visible [PAXRUNNER-383] #393

Open ops4j-issues opened 13 years ago

ops4j-issues commented 13 years ago

Pieter created PAXRUNNER-383

When I switch from Pax Runner 1.5.0 to 1.6.1, I get an error:
com.sun.xml.internal.messaging.saaj.soap.SAAJMetaFactoryImpl not found

Affects: 1.6.1 Votes: 0, Watches: 0

ops4j-issues commented 13 years ago

Toni Menzel commented

Can you add a stacktrace so we see who requests this class ?

Because usually you need to add such packages to the bootclasspath by yourself.
But if it worked for you in 1.5, then i see your point.

ops4j-issues commented 13 years ago

Bartosz Kowalewski commented

I agree that a stacktrace would be really helpful.

Some thoughts:
By default you should use the SAAJ API (javax.xml.soap) and not the impl. As far as I know only Pax Runner profiles for JDkK>=1.6 declare SAAJ APi packages as system ones. If you're using JDK 1.6, you'll get javax.xml.soap from the system bundle. If this is the case, javax.xml.soap should be able to fetch the com.sun impl. Default SPI mechanisms would be used in SAAJ API and everything should work just fine. All SPI magic should happen in the same classloader - inside the system bundle.

If you're using javax.xml.soap from an external bundle, then it's probably a problem with this bundle. For example ServiceMix4 provides such SAAJ API / IMPL bundles.

Please also note that (as far as I know) the default value for boot delegation in Pax Runner platforms is 'javax.*'. Boot delegation is not enabled for com.sun. If you need to get such behavior, you need to configure it by yourself. Some containers (again, for example ServiceMix4) use plenty of package name patterns when setting up boot delegation.

Thanks,
Bartek