You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Josh Holtzman <jh...@berkeley.edu> on 2009/08/21 13:46:19 UTC
Problem on JDK 1.6
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.
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.java:800)
at org.ops4j.pax.web.service.internal.JettyServerImpl$1.call(JettyServerImpl.java:139)
at org.ops4j.pax.web.service.internal.JettyServerImpl$1.call(JettyServerImpl.java:136)
at org.ops4j.pax.swissbox.core.ContextClassLoaderUtils.doWithClassLoader(ContextClassLoaderUtils.java:60)
at org.ops4j.pax.web.service.internal.JettyServerImpl.addServlet(JettyServerImpl.java:131)
at org.ops4j.pax.web.service.internal.ServerControllerImpl$Started.addServlet(ServerControllerImpl.java:236)
at org.ops4j.pax.web.service.internal.ServerControllerImpl.addServlet(ServerControllerImpl.java:93)
at org.ops4j.pax.web.service.internal.HttpServiceStarted.registerServlet(HttpServiceStarted.java:144)
at org.ops4j.pax.web.service.internal.HttpServiceProxy.registerServlet(HttpServiceProxy.java:53)
at org.apache.cxf.dosgi.dsw.handlers.HttpServiceConfigurationTypeHandler.createServer(HttpServiceConfigurationTypeHandler.java:96)
at org.apache.cxf.dosgi.dsw.hooks.ServiceHookUtils.createServer(ServiceHookUtils.java:86)
at org.apache.cxf.dosgi.dsw.hooks.CxfPublishHook.createServer(CxfPublishHook.java:106)
at org.apache.cxf.dosgi.dsw.hooks.CxfPublishHook.publishEndpoint(CxfPublishHook.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.java: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)
RE: Problem on JDK 1.6
Posted by Sergey Beryozkin <sb...@progress.com>.
Oh...Sorry Josh, that issue of using Aegis with JAXRS in DOSGi (warnings
to do with JAXP) affected my thinking a bit :-) We ship the stax api
specs bundle though so it has to be something else which is causing the
problem...
Cheers, Sergey
-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org]
Sent: 04 September 2009 16:52
To: users@cxf.apache.org
Cc: Sergey Beryozkin
Subject: Re: Problem on JDK 1.6
No. Woodstox would be stax:
http://svn.apache.org/repos/asf/servicemix/smx4/specs/tags/specs-1.3.0/s
tax-
api-1.0/
Dan
On Fri September 4 2009 7:29:21 am Sergey Beryozkin wrote:
> Hi Josh
>
> Perhaps the DOSGi should include this
>
>
http://svn.apache.org/repos/asf/servicemix/smx4/specs/tags/specs-1.3.0/j
axp
> -api-1.4/
>
> or may be
>
>
http://svn.apache.org/repos/asf/servicemix/smx4/specs/tags/specs-1.3.0/j
axp
> -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" <jh...@berkeley.edu>
> To: <us...@cxf.apache.org>
> 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 <dk...@apache.org>
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.ja
va:
> >> >406) at
> >>
> >>
org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:4
> >>49)
> >>
> >> > at
> >>
> >>
org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263)
> >>
> >> > at
> >> >
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:5
> >> >0)
> >>
> >> at
> >>
> >>
org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:
> >>676
> >>
> >> >) at
> >>
> >>
org.mortbay.jetty.servlet.ServletHandler.updateMappings(ServletHandler.j
> >>ava
> >>
> >> >:1044)
> >> >
> >> > at
> >>
> >>
org.mortbay.jetty.servlet.ServletHandler.setServletMappings(ServletHandl
> >>er.
> >>
> >> >java:1101) at
> >>
> >>
org.mortbay.jetty.servlet.ServletHandler.addServletMapping(ServletHandle
> >>r.j
> >>
> >> >ava:800) at
> >>
> >>
org.ops4j.pax.web.service.internal.JettyServerImpl$1.call(JettyServerImp
> >>l.j
> >>
> >> >ava:139)
> >> >
> >> > at
> >>
> >>
org.ops4j.pax.web.service.internal.JettyServerImpl$1.call(JettyServerImp
> >>l.j
> >>
> >> >ava:136) at
> >>
> >>
org.ops4j.pax.swissbox.core.ContextClassLoaderUtils.doWithClassLoader(Co
> >>nte
> >>
> >> >xtClassLoaderUtils.java:60) at
> >>
> >>
org.ops4j.pax.web.service.internal.JettyServerImpl.addServlet(JettyServe
> >>rIm
> >>
> >> >pl.java:131)
> >> >
> >> > at
> >>
> >>
org.ops4j.pax.web.service.internal.ServerControllerImpl$Started.addServl
> >>et(
> >>
> >> >ServerControllerImpl.java:236) at
> >>
> >>
org.ops4j.pax.web.service.internal.ServerControllerImpl.addServlet(Serve
> >>rCo
> >>
> >> >ntrollerImpl.java:93) at
> >>
> >>
org.ops4j.pax.web.service.internal.HttpServiceStarted.registerServlet(Ht
> >>tpS
> >>
> >> >erviceStarted.java:144)
> >> >
> >> > at
> >>
> >>
org.ops4j.pax.web.service.internal.HttpServiceProxy.registerServlet(Http
> >>Ser
> >>
> >> >viceProxy.java:53) at
> >>
> >>
org.apache.cxf.dosgi.dsw.handlers.HttpServiceConfigurationTypeHandler.cr
> >>eat
> >>
> >> >eServer(HttpServiceConfigurationTypeHandler.java:96)
> >> >
> >> > at
> >>
> >>
org.apache.cxf.dosgi.dsw.hooks.ServiceHookUtils.createServer(ServiceHook
> >>Uti
> >>
> >> >ls.java:86) at
> >>
> >>
org.apache.cxf.dosgi.dsw.hooks.CxfPublishHook.createServer(CxfPublishHoo
> >>k.j
> >>
> >> >ava:106) at
> >>
> >>
org.apache.cxf.dosgi.dsw.hooks.CxfPublishHook.publishEndpoint(CxfPublish
> >>Hoo
> >>
> >> >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
> >> dkulp@apache.org
> >> http://www.dankulp.com/blog
>
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Problem on JDK 1.6
Posted by Daniel Kulp <dk...@apache.org>.
No. Woodstox would be stax:
http://svn.apache.org/repos/asf/servicemix/smx4/specs/tags/specs-1.3.0/stax-
api-1.0/
Dan
On Fri September 4 2009 7:29:21 am Sergey Beryozkin 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" <jh...@berkeley.edu>
> To: <us...@cxf.apache.org>
> 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 <dk...@apache.org> 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:4
> >>49)
> >>
> >> > at
> >>
> >> org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263)
> >>
> >> > at
> >> > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:5
> >> >0)
> >>
> >> at
> >>
> >> org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:
> >>676
> >>
> >> >) at
> >>
> >> org.mortbay.jetty.servlet.ServletHandler.updateMappings(ServletHandler.j
> >>ava
> >>
> >> >:1044)
> >> >
> >> > at
> >>
> >> org.mortbay.jetty.servlet.ServletHandler.setServletMappings(ServletHandl
> >>er.
> >>
> >> >java:1101) at
> >>
> >> org.mortbay.jetty.servlet.ServletHandler.addServletMapping(ServletHandle
> >>r.j
> >>
> >> >ava:800) at
> >>
> >> org.ops4j.pax.web.service.internal.JettyServerImpl$1.call(JettyServerImp
> >>l.j
> >>
> >> >ava:139)
> >> >
> >> > at
> >>
> >> org.ops4j.pax.web.service.internal.JettyServerImpl$1.call(JettyServerImp
> >>l.j
> >>
> >> >ava:136) at
> >>
> >> org.ops4j.pax.swissbox.core.ContextClassLoaderUtils.doWithClassLoader(Co
> >>nte
> >>
> >> >xtClassLoaderUtils.java:60) at
> >>
> >> org.ops4j.pax.web.service.internal.JettyServerImpl.addServlet(JettyServe
> >>rIm
> >>
> >> >pl.java:131)
> >> >
> >> > at
> >>
> >> org.ops4j.pax.web.service.internal.ServerControllerImpl$Started.addServl
> >>et(
> >>
> >> >ServerControllerImpl.java:236) at
> >>
> >> org.ops4j.pax.web.service.internal.ServerControllerImpl.addServlet(Serve
> >>rCo
> >>
> >> >ntrollerImpl.java:93) at
> >>
> >> org.ops4j.pax.web.service.internal.HttpServiceStarted.registerServlet(Ht
> >>tpS
> >>
> >> >erviceStarted.java:144)
> >> >
> >> > at
> >>
> >> org.ops4j.pax.web.service.internal.HttpServiceProxy.registerServlet(Http
> >>Ser
> >>
> >> >viceProxy.java:53) at
> >>
> >> org.apache.cxf.dosgi.dsw.handlers.HttpServiceConfigurationTypeHandler.cr
> >>eat
> >>
> >> >eServer(HttpServiceConfigurationTypeHandler.java:96)
> >> >
> >> > at
> >>
> >> org.apache.cxf.dosgi.dsw.hooks.ServiceHookUtils.createServer(ServiceHook
> >>Uti
> >>
> >> >ls.java:86) at
> >>
> >> org.apache.cxf.dosgi.dsw.hooks.CxfPublishHook.createServer(CxfPublishHoo
> >>k.j
> >>
> >> >ava:106) at
> >>
> >> org.apache.cxf.dosgi.dsw.hooks.CxfPublishHook.publishEndpoint(CxfPublish
> >>Hoo
> >>
> >> >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
> >> dkulp@apache.org
> >> http://www.dankulp.com/blog
>
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Problem on JDK 1.6
Posted by Josh Holtzman <jh...@berkeley.edu>.
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 <sb...@progress.com>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" <jholtzman@berkeley.edu
> >
> To: <us...@cxf.apache.org>
> 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 <dk...@apache.org> 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
>>> dkulp@apache.org
>>> http://www.dankulp.com/blog
>>>
>>>
>>
Re: Problem on JDK 1.6
Posted by Sergey Beryozkin <sb...@progress.com>.
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" <jh...@berkeley.edu>
To: <us...@cxf.apache.org>
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 <dk...@apache.org> 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
>> dkulp@apache.org
>> http://www.dankulp.com/blog
>>
>
Re: Problem on JDK 1.6
Posted by Daniel Kulp <dk...@apache.org>.
I'd really like to know why the Stax parser in the JDK cannot parse cxf.xml.
That's not a good sign. :-(
Dan
On Fri September 4 2009 7:03:12 am Josh Holtzman wrote:
> 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 <dk...@apache.org> 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:44
> >9)
> >
> > > 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:6
> >76
> >
> > >) at
> >
> > org.mortbay.jetty.servlet.ServletHandler.updateMappings(ServletHandler.ja
> >va
> >
> > >:1044)
> > >
> > > at
> >
> > org.mortbay.jetty.servlet.ServletHandler.setServletMappings(ServletHandle
> >r.
> >
> > >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(Con
> >te
> >
> > >xtClassLoaderUtils.java:60) at
> >
> > org.ops4j.pax.web.service.internal.JettyServerImpl.addServlet(JettyServer
> >Im
> >
> > >pl.java:131)
> > >
> > > at
> >
> > org.ops4j.pax.web.service.internal.ServerControllerImpl$Started.addServle
> >t(
> >
> > >ServerControllerImpl.java:236) at
> >
> > org.ops4j.pax.web.service.internal.ServerControllerImpl.addServlet(Server
> >Co
> >
> > >ntrollerImpl.java:93) at
> >
> > org.ops4j.pax.web.service.internal.HttpServiceStarted.registerServlet(Htt
> >pS
> >
> > >erviceStarted.java:144)
> > >
> > > at
> >
> > org.ops4j.pax.web.service.internal.HttpServiceProxy.registerServlet(HttpS
> >er
> >
> > >viceProxy.java:53) at
> >
> > org.apache.cxf.dosgi.dsw.handlers.HttpServiceConfigurationTypeHandler.cre
> >at
> >
> > >eServer(HttpServiceConfigurationTypeHandler.java:96)
> > >
> > > at
> >
> > org.apache.cxf.dosgi.dsw.hooks.ServiceHookUtils.createServer(ServiceHookU
> >ti
> >
> > >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(CxfPublishH
> >oo
> >
> > >k.java:80)
> > >
> > > at
> >
> > org.apache.cxf.dosgi.dsw.Activator.checkExistingServices(Activator.java:1
> >51
> >
> > >) 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
> > dkulp@apache.org
> > http://www.dankulp.com/blog
>
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Problem on JDK 1.6
Posted by Josh Holtzman <jh...@berkeley.edu>.
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 <dk...@apache.org> 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
> dkulp@apache.org
> http://www.dankulp.com/blog
>
Re: Problem on JDK 1.6
Posted by Daniel Kulp <dk...@apache.org>.
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
dkulp@apache.org
http://www.dankulp.com/blog