Neither of these fixed the problem for me.  I still need to set the parsers
via system properties.

Thanks,
Josh

On Fri, Sep 4, 2009 at 1:29 PM, Sergey Beryozkin <[email protected]>wrote:

> Hi Josh
>
> Perhaps the DOSGi should include this
>
>
> http://svn.apache.org/repos/asf/servicemix/smx4/specs/tags/specs-1.3.0/jaxp-api-1.4/
>
> or may be
>
>
> http://svn.apache.org/repos/asf/servicemix/smx4/specs/tags/specs-1.3.0/jaxp-api-1.3/
>
> Josh, can you please try installing either of those bundles in your Java
> 1.6 - based env and see if it helps ?
> we will then update the DOSGI single/multi distributions
>
> cheers, Sergey
>
> ----- Original Message ----- From: "Josh Holtzman" <[email protected]
> >
> To: <[email protected]>
> Sent: Friday, September 04, 2009 12:03 PM
> Subject: Re: Problem on JDK 1.6
>
>
>
>  I turned on jaxp debugging, and found that the classloader used to load
>> the
>> xml parsers in 1.6 is null (I'm guessing that means the system
>> classloader)
>> and that it is the CXF bundle's classloader (CXF 2.3.0.SNAPSHOT) when
>> running with 1.5.
>>
>> Thanks Dan for the woodstox hint.  Setting the following system properties
>> from the commandline did the trick:
>>
>> -Djavax.xml.stream.XMLInputFactory=com.ctc.wstx.stax.WstxInputFactory
>> -Djavax.xml.stream.XMLOutputFactory=com.ctc.wstx.stax.WstxOutputFactory
>> -Djavax.xml.stream.XMLEventFactory=com.ctc.wstx.stax.WstxEventFactory
>>
>> I'm still wondering, though, is there is a way to fix this in CXF rather
>> than requiring users to set these properties themselves.  Perhaps
>> including
>> META-INF/services/javax.xml.stream.XML*Factory files in either the CXF or
>> DSW bundle?
>>
>> Thanks,
>> Josh
>>
>>
>> On Tue, Aug 25, 2009 at 11:27 PM, Daniel Kulp <[email protected]> wrote:
>>
>>
>>>
>>> On Fri August 21 2009 7:46:19 am Josh Holtzman wrote:
>>> > I get a stack trace (see below) when viewing a DOSGi-generated WSDL (or
>>> > WADL, for that matter) on JDK 1.6, but not on 1.5.  Any ideas why that
>>> > might be?
>>> >
>>> > I'm running cxf 2.3.0-SNAPSHOT and the DOSGi 1.1-SNAPSHOT versions.
>>>
>>> No idea.   My thought was that maybe the parser in the JDK6 was being
>>> picked
>>> up  instead of woodstox for parsing META-INF/cxf/cxf.xml.    That said,
>>> the
>>> stack trace there sucks.   Not sure how I'd go about diagnosing it.
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>> > Thanks,
>>> > Josh
>>> >
>>> > javax.servlet.UnavailableException: java.lang.RuntimeException:
>>> > org.springframework.beans.factory.BeanDefinitionStoreException:
>>> > Unexpected exception parsing XML document from class path resource
>>> > [META-INF/cxf/cxf.xml]; nested exception is
>>> > java.lang.RuntimeException: Couldn't parse stream.
>>> >
>>> >       at
>>> >
>>>
>>> org.mortbay.jetty.servlet.ServletHolder.makeUnavailable(ServletHolder.java:
>>> >406) at
>>> >
>>>
>>> org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:449)
>>> > at
>>> org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263)
>>> >
>>> >       at
>>> >
>>> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
>>> at
>>> >
>>>
>>> org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:676
>>> >) at
>>> >
>>>
>>> org.mortbay.jetty.servlet.ServletHandler.updateMappings(ServletHandler.java
>>> >:1044)
>>> >
>>> >       at
>>> >
>>>
>>> org.mortbay.jetty.servlet.ServletHandler.setServletMappings(ServletHandler.
>>> >java:1101) at
>>> >
>>>
>>> org.mortbay.jetty.servlet.ServletHandler.addServletMapping(ServletHandler.j
>>> >ava:800) at
>>> >
>>>
>>> org.ops4j.pax.web.service.internal.JettyServerImpl$1.call(JettyServerImpl.j
>>> >ava:139)
>>> >
>>> >       at
>>> >
>>>
>>> org.ops4j.pax.web.service.internal.JettyServerImpl$1.call(JettyServerImpl.j
>>> >ava:136) at
>>> >
>>>
>>> org.ops4j.pax.swissbox.core.ContextClassLoaderUtils.doWithClassLoader(Conte
>>> >xtClassLoaderUtils.java:60) at
>>> >
>>>
>>> org.ops4j.pax.web.service.internal.JettyServerImpl.addServlet(JettyServerIm
>>> >pl.java:131)
>>> >
>>> >       at
>>> >
>>>
>>> org.ops4j.pax.web.service.internal.ServerControllerImpl$Started.addServlet(
>>> >ServerControllerImpl.java:236) at
>>> >
>>>
>>> org.ops4j.pax.web.service.internal.ServerControllerImpl.addServlet(ServerCo
>>> >ntrollerImpl.java:93) at
>>> >
>>>
>>> org.ops4j.pax.web.service.internal.HttpServiceStarted.registerServlet(HttpS
>>> >erviceStarted.java:144)
>>> >
>>> >       at
>>> >
>>>
>>> org.ops4j.pax.web.service.internal.HttpServiceProxy.registerServlet(HttpSer
>>> >viceProxy.java:53) at
>>> >
>>>
>>> org.apache.cxf.dosgi.dsw.handlers.HttpServiceConfigurationTypeHandler.creat
>>> >eServer(HttpServiceConfigurationTypeHandler.java:96)
>>> >
>>> >       at
>>> >
>>>
>>> org.apache.cxf.dosgi.dsw.hooks.ServiceHookUtils.createServer(ServiceHookUti
>>> >ls.java:86) at
>>> >
>>>
>>> org.apache.cxf.dosgi.dsw.hooks.CxfPublishHook.createServer(CxfPublishHook.j
>>> >ava:106) at
>>> >
>>>
>>> org.apache.cxf.dosgi.dsw.hooks.CxfPublishHook.publishEndpoint(CxfPublishHoo
>>> >k.java:80)
>>> >
>>> >       at
>>> >
>>>
>>> org.apache.cxf.dosgi.dsw.Activator.checkExistingServices(Activator.java:151
>>> >) at org.apache.cxf.dosgi.dsw.Activator.start(Activator.java:81)
>>> >       at
>>> >
>>>
>>> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.ja
>>> >va:589)
>>> >
>>> >       at org.apache.felix.framework.Felix.startBundle(Felix.java:1458)
>>> >       at
>>> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:984)
>>> >       at
>>> org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:263)
>>> >
>>> >       at java.lang.Thread.run(Thread.java:636)
>>>
>>> --
>>> Daniel Kulp
>>> [email protected]
>>> http://www.dankulp.com/blog
>>>
>>>
>>

Reply via email to