You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Stephane Nicoll <st...@gmail.com> on 2010/11/01 18:13:41 UTC
Re: cxf 2.3 and Jetty 7
Any idea where I should look ?
On Wed, Oct 27, 2010 at 10:33 AM, Stephane Nicoll <stephane.nicoll@gmail.com
> wrote:
> A plain old maven2 module with Spring 2.5. No OSGI.
>
> The thing I really don't understand is what does trigger the actual startup
> of Jetty. Looking at the samples, it should be located in the processing of
> the namespace somehow but if I copy/paste the CherrServer.xml in my project,
> jetty does not start.
>
> Thanks,
> S.
>
>
> On Wed, Oct 27, 2010 at 9:48 AM, Willem Jiang <wi...@gmail.com>wrote:
>
>> Are you deploying the example into an OSGi platform?
>> If so there may be some issue, I will have a look at it if I get some
>> time tomorrow.
>>
>> Willem
>>
>> On 10/27/10, Stephane Nicoll <st...@gmail.com> wrote:
>> > Hi there,
>> >
>> > I started from the base and thought the samples would answer my original
>> > issue. I downloaded the official apache-cxf 2.3.0 distribution from
>> > apache.org, had a look and found all kinds of reference to
>> > "org.mortbay.jetty". If I try to run these samples, I am getting an
>> obvious
>> > ClassNotFoundException since Jett7 is used.
>> >
>> > However, jax_rs\basic_https is working fine and I copy/pasted the
>> > cherryServer.xml in my project but jetty does not seem to start.
>> >
>> > What am I missing? Especially since the same config works just fine with
>> > 2.2.11 (and Jetty 6)
>> >
>> > S.
>> >
>> > On Wed, Oct 20, 2010 at 10:41 AM, Willem Jiang
>> > <wi...@gmail.com>wrote:
>> >
>> >> There is no other different configuration on the jetty7 to start the
>> >> embedded server.
>> >> Can you take a look at the CXF 2.3.0 system tests, we didn't face that
>> >> kind
>> >> of issue before?
>> >>
>> >> BTW, what's address that your service was published?
>> >>
>> >>
>> >> On 10/20/10 4:14 PM, Stephane Nicoll wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> We are trying to upgrade our application from 2.2.10 to 2.3.0 and
>> we're
>> >>> facing an issue with embedded Jetty7
>> >>>
>> >>> We have a set of unit tests starting CXF with an embedded jetty. First
>> we
>> >>> had to rename some classes since the move to eclipse but the real
>> issue
>> >>> is
>> >>> that while CXF states it has deployed our Web Service, all the unit
>> tests
>> >>> are failing with a ConnectionException now.
>> >>>
>> >>> Do you have a working setup somewhere of embedded jetty with unit
>> tests
>> >>> and
>> >>> cxf 2.3? I had a look to the doc but it does not seem up to date in
>> that
>> >>> area.
>> >>>
>> >>> Thanks,
>> >>> S.
>> >>>
>> >>>
>> >>
>> >> --
>> >> Willem
>> >> ----------------------------------
>> >> Open Source Integration: http://www.fusesource.com
>> >> Blog: http://willemjiang.blogspot.com (English)
>> >> http://jnn.javaeye.com (Chinese)
>> >> Twitter: http://twitter.com/willemjiang
>> >>
>> >
>>
>
>
Re: cxf 2.3 and Jetty 7
Posted by Daniel Kulp <dk...@apache.org>.
On Friday 12 November 2010 5:51:38 am Stephane Nicoll wrote:
> On Fri, Nov 12, 2010 at 10:43 AM, Willem Jiang
<wi...@gmail.com>wrote:
> > The SoapTransportFactory will try to locat the real TransportFactory by
> > checking the address.
> > You can find the code from SoapTransportFactory.getDestination() method.
> >
> > Can you just set the break point on the JettyHTTPTransportFactory?
>
> Here is more information about this. In SoapTransportFactory#getDestination
>
> * bi [BindingInfo http://schemas.xmlsoap.org/wsdl/soap/]
> * address = http://localhost:7171/MathWebService
> * transId= http://schemas.xmlsoap.org/soap/http
>
> Which leads to a call on
> DestinationFactoryManagerImpl#getDestinationFactory with the
> "http://cxf.apache.org/transports/http" namespace. The problem is that
> these are my destination factories:
............
> No Jetty in there and the returned factory is
> obviously org.apache.cxf.transport.servlet.ServletTransportFactory@b20090
>
> I don't understand what is happening. I have the http-jetty jar in my
> classpath and I also explicitely added the following in my spring config
> file:
> <import resource="classpath*:/META-INF/cxf/cxf-extension-http-jetty.xml"/>
>
> Can we use wildcards for this thing? Maybe I am loading another
> configuration file that registers the same transportId with another
> protocol? The imports of my project on CXF are:
>
> <import resource="classpath*:META-INF/cxf/cxf-servlet.xml"/>
That right there is the issue. Why are you pulling in META-INF/cxf/cxf-
servlet.xml? That's where the servlet destination is specified.
Dan
> <import resource="classpath*:META-INF/cxf/cxf.xml"/>
> <import resource="classpath*:META-INF/cxf/cxf-extension-*.xml"/>
>
> HTH,
> S.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: cxf 2.3 and Jetty 7
Posted by Stephane Nicoll <st...@gmail.com>.
On Fri, Nov 12, 2010 at 10:43 AM, Willem Jiang <wi...@gmail.com>wrote:
>
> On 11/12/10 5:21 PM, Stephane Nicoll wrote:
>
>> Hi Dan,
>>
>> Thanks for the tip. There is indeed a difference between CXF 2.2.11 and
>> CXF
>> 2.3.0 with the exact same configuration (I just flip the cxf version in my
>> pom and rerun my simple unit test with embedded Jetty).
>>
>> The destinationFactory is not the same (see
>> org.apache.cxf.endpoint.AbstractEndpointFactory):
>>
>> * CXF 2.2.11:
>> org.apache.cxf.transport.http_jetty.JettyHTTPTransportFactory
>> * CXF 2.3: org.apache.cxf.binding.soap.SoapTransportFactory
>>
>
> The SoapTransportFactory will try to locat the real TransportFactory by
> checking the address.
> You can find the code from SoapTransportFactory.getDestination() method.
>
> Can you just set the break point on the JettyHTTPTransportFactory?
Nice. Will do.
In the meantime, I have found that overriding the JettyHTTPTransportFactory
bean configuration with the one from CXF 2.2.11 fixes my issue !
I have reported the problem now I have found a way to workaround it:
https://issues.apache.org/jira/browse/CXF-3119
<https://issues.apache.org/jira/browse/CXF-3119>Thanks!
S.
RE: cxf 2.3 and Jetty 7
Posted by Sven Zethelius <sv...@expedia.com>.
I don't know if this is the cause, but I recently noticed something with regard to the ConduitInitiatorManager that may be related (this was in 2.2.10, but didn't see a relevant change in 2.3.0). The load order of the various TransportFactory beans isn't well guaranteed, and not depends-on to the ConduitInitiatorManager and DestinationFactoryManager, and the way the Spring map is injected into it may lead to flaky initialization order. The order I was seeing was that the CondiutInitiator's were calling the registerConduitInitiator from their @PostConstruct methods, and then after, the ConduitInitiatorManagerImpl was getting the Spring map injected, which ended up clearing the "last one in wins" order of the registerConduitInitiator, and since no other registrations happened, the ClientOnlyHTTPTransportFactory was sitting in the first position for the namespaces that the JettyHttpTransportFactory was supposed to be overriding.
It looks like DestinationFactoryManagerImpl follows the same pattern. What could be happening here is that the JettyHttpTransportFactory is registering before the DestinationFactoryManagerImpl is initialized, then the DestinationFactoryManagerImpl gets initialized, then the SoapTransportFactory got initialized.
-----Original Message-----
From: Stephane Nicoll [mailto:stephane.nicoll@gmail.com]
Sent: Friday, November 12, 2010 2:52 AM
To: users@cxf.apache.org
Subject: Re: cxf 2.3 and Jetty 7
On Fri, Nov 12, 2010 at 10:43 AM, Willem Jiang <wi...@gmail.com>wrote:
>
>
> The SoapTransportFactory will try to locat the real TransportFactory by
> checking the address.
> You can find the code from SoapTransportFactory.getDestination() method.
>
> Can you just set the break point on the JettyHTTPTransportFactory?
Here is more information about this. In SoapTransportFactory#getDestination
* bi [BindingInfo http://schemas.xmlsoap.org/wsdl/soap/]
* address = http://localhost:7171/MathWebService
* transId= http://schemas.xmlsoap.org/soap/http
Which leads to a call on DestinationFactoryManagerImpl#getDestinationFactory
with the "http://cxf.apache.org/transports/http" namespace. The problem is
that these are my destination factories:
- [0] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3059}
http://www.w3.org/2003/05/soap/bindings/HTTP/ ->
org.apache.cxf.binding.soap.SoapTransportFactory@12284af
- [1] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3067}
http://schemas.xmlsoap.org/soap/http ->
org.apache.cxf.binding.soap.SoapTransportFactory@12284af
- [2] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3075}
http://schemas.xmlsoap.org/wsdl/soap12/ ->
org.apache.cxf.binding.soap.SoapTransportFactory@12284af
- [3] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3083}
http://www.w3.org/2010/soapjms/ ->
org.apache.cxf.binding.soap.SoapTransportFactory@12284af
- [4] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3091}
http://schemas.xmlsoap.org/wsdl/http ->
org.apache.cxf.transport.servlet.ServletTransportFactory@b20090
- [5] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3100}
http://schemas.xmlsoap.org/wsdl/soap/http ->
org.apache.cxf.binding.soap.SoapTransportFactory@12284af
- [6] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3108}
http://cxf.apache.org/transports/http ->
org.apache.cxf.transport.servlet.ServletTransportFactory@b20090
- [7] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3116}
http://schemas.xmlsoap.org/soap/ ->
org.apache.cxf.binding.soap.SoapTransportFactory@12284af
- [8] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3124}
http://cxf.apache.org/transports/http/configuration ->
org.apache.cxf.transport.servlet.ServletTransportFactory@b20090
- [9] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3132}
http://schemas.xmlsoap.org/wsdl/http/ ->
org.apache.cxf.transport.servlet.ServletTransportFactory@b20090
- [10] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3140}
http://schemas.xmlsoap.org/soap/http/ ->
org.apache.cxf.binding.soap.SoapTransportFactory@12284af
- [11] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3148}
http://schemas.xmlsoap.org/wsdl/soap/ ->
org.apache.cxf.binding.soap.SoapTransportFactory@12284af
No Jetty in there and the returned factory is
obviously org.apache.cxf.transport.servlet.ServletTransportFactory@b20090
I don't understand what is happening. I have the http-jetty jar in my
classpath and I also explicitely added the following in my spring config
file:
<import resource="classpath*:/META-INF/cxf/cxf-extension-http-jetty.xml"/>
Can we use wildcards for this thing? Maybe I am loading another
configuration file that registers the same transportId with another
protocol? The imports of my project on CXF are:
<import resource="classpath*:META-INF/cxf/cxf-servlet.xml"/>
<import resource="classpath*:META-INF/cxf/cxf.xml"/>
<import resource="classpath*:META-INF/cxf/cxf-extension-*.xml"/>
HTH,
S.
Re: cxf 2.3 and Jetty 7
Posted by Daniel Kulp <dk...@apache.org>.
What seems to be the issue is that the BusExtensionPostProcessor isn't being
properly registered or called. If you look in there in the
postProcessBeforeInitialization call, it SHOULD be calling getBus() which then
would register a SpringBeanLocator which is what is used when you call
bus.getExtension(....) to find the appropriate Spring bean.
Can you put a breakpoint in there and make sure it's properly being hit and
registered? I'm almost wondering if there is a second Bus being created
someplace and that second bus is being picked up in some places, but that one
isn't getting the SpringBeanLocator set.
Hmm... I wondering if the line:
bus = (Bus)context.getBean(Bus.DEFAULT_BUS_ID);
should be changed to something like
context.getBeanNamesForType(Bus.class)
to make sure all the "Bus" beans are grabbed.
Anyway, if you could either try that or provide a debuggable test case, that
would be great.
Dan
On Monday 22 November 2010 12:43:44 pm Stephane Nicoll wrote:
> Yes, the lazy init in the Spring beans since 2.3.0 does seem to
> introduce a set of regressions. For instance,
> this is the declaration of the faulty bean:
>
> <bean id="org.apache.cxf.phase.PhaseManager"
> class="org.apache.cxf.phase.PhaseManagerImpl"
> lazy-init="true"/>
>
> The difference with other extensions is that PhaseManagerImpl does NOT
> need the bus so it has not constructor argument. What happens is the
> lazy init does not force the object to be created and it's not added
> as an extension. If I copy/paste the bean above in my project with
> lazy-init to false, I don't have the NPE anymore but something else:
>
> "Could not find conduit initiator for transport
> http://schemas.xmlsoap.org/soap/http"
>
> Looking at it a bit deeper it seems again an initialization issue.
>
> I have tried the workaround you are suggesting and I got this
>
> org.apache.cxf.transport.http_jetty.JettyHTTPServerEngineFactory':
> Cannot resolve reference to bean 'cxf' while setting constructor
> argument; nested exception is
> org.springframework.beans.factory.NoSuchBeanDefinitionException: No
> bean named 'cxf' is defined
>
> Are these issues tracked somewhere in Jira. I initially thought that I
> was the only one having them because of my setup but given the
> workaround provided in your link, it seems something need to be fixed
> in CXF itself.
>
> Thanks,
> Stéphane
>
> On Mon, Nov 22, 2010 at 3:46 PM, Marco Zapletal
>
> <ma...@gmail.com> wrote:
> > On 22.11.2010 14:57, Stephane Nicoll wrote:
> >> On Mon, Nov 15, 2010 at 1:53 AM, Willem
Jiang<wi...@gmail.com>wrote:
> >>> On 11/12/10 6:51 PM, Stephane Nicoll wrote:
> >>>> On Fri, Nov 12, 2010 at 10:43 AM, Willem Jiang<willem.jiang@gmail.com
> >>>>
> >>>>> wrote:
> >>>> If you put the cxf-servlet here, The ServletTransportFactory will
> >>>> replace
> >>>
> >>> all registered transportIds with itself, that could explain why you
> >>> can't find the JettyTransportFactory here.
> >>>
> >>> If you are using the servlet transport, please don't include other http
> >>> related transport.
> >>
> >> Okay this works better but now I am getting another weird issue in
> >> another test. I got a NullPointerException on the PhaseManager. This is
> >> the code in ClientImpl:
> >>
> >> PhaseManager pm = bus.getExtension(PhaseManager.class);
> >>
> >> The returned pm instance is null which leads to a NPE latter
> >> (setupInterceptorChain). I searched where this phase manager was defined
> >> and it is in cxf.xml which I obviously import.
> >>
> >> I tried to build a sample that could run with CXF without our extensions
> >> but it's quite hard so if you can help me debugging this I would
> >> appreciate it.
> >
> > this seems to be similar to the problem I had. Willem posted a workaround
> > on the camel mailing list.
> >
> > http://camel.465427.n5.nabble.com/camel-cxf-exception-when-parsing-cxf-sc
> > hemaLocation-element-td3253254i20.html
> >
> > regards,
> > marco
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: cxf 2.3 and Jetty 7
Posted by Stephane Nicoll <st...@gmail.com>.
Yes, the lazy init in the Spring beans since 2.3.0 does seem to
introduce a set of regressions. For instance,
this is the declaration of the faulty bean:
<bean id="org.apache.cxf.phase.PhaseManager"
class="org.apache.cxf.phase.PhaseManagerImpl"
lazy-init="true"/>
The difference with other extensions is that PhaseManagerImpl does NOT
need the bus so it has not constructor argument. What happens is the
lazy init does not force the object to be created and it's not added
as an extension. If I copy/paste the bean above in my project with
lazy-init to false, I don't have the NPE anymore but something else:
"Could not find conduit initiator for transport
http://schemas.xmlsoap.org/soap/http"
Looking at it a bit deeper it seems again an initialization issue.
I have tried the workaround you are suggesting and I got this
org.apache.cxf.transport.http_jetty.JettyHTTPServerEngineFactory':
Cannot resolve reference to bean 'cxf' while setting constructor
argument; nested exception is
org.springframework.beans.factory.NoSuchBeanDefinitionException: No
bean named 'cxf' is defined
Are these issues tracked somewhere in Jira. I initially thought that I
was the only one having them because of my setup but given the
workaround provided in your link, it seems something need to be fixed
in CXF itself.
Thanks,
Stéphane
On Mon, Nov 22, 2010 at 3:46 PM, Marco Zapletal
<ma...@gmail.com> wrote:
>
> On 22.11.2010 14:57, Stephane Nicoll wrote:
>>
>> On Mon, Nov 15, 2010 at 1:53 AM, Willem Jiang<wi...@gmail.com>wrote:
>>
>>> On 11/12/10 6:51 PM, Stephane Nicoll wrote:
>>>
>>>> On Fri, Nov 12, 2010 at 10:43 AM, Willem Jiang<willem.jiang@gmail.com
>>>>>
>>>>> wrote:
>>>>
>>>> If you put the cxf-servlet here, The ServletTransportFactory will replace
>>>
>>> all registered transportIds with itself, that could explain why you can't
>>> find the JettyTransportFactory here.
>>>
>>> If you are using the servlet transport, please don't include other http
>>> related transport.
>>
>>
>> Okay this works better but now I am getting another weird issue in another
>> test. I got a NullPointerException on the PhaseManager. This is the code in
>> ClientImpl:
>>
>> PhaseManager pm = bus.getExtension(PhaseManager.class);
>>
>> The returned pm instance is null which leads to a NPE latter
>> (setupInterceptorChain). I searched where this phase manager was defined and
>> it is in cxf.xml which I obviously import.
>>
>> I tried to build a sample that could run with CXF without our extensions but
>> it's quite hard so if you can help me debugging this I would appreciate it.
>>
>
> this seems to be similar to the problem I had. Willem posted a workaround on the camel mailing list.
>
> http://camel.465427.n5.nabble.com/camel-cxf-exception-when-parsing-cxf-schemaLocation-element-td3253254i20.html
>
> regards,
> marco
>
Re: cxf 2.3 and Jetty 7
Posted by Marco Zapletal <ma...@gmail.com>.
On 22.11.2010 14:57, Stephane Nicoll wrote:
> On Mon, Nov 15, 2010 at 1:53 AM, Willem Jiang<wi...@gmail.com>wrote:
>
>> On 11/12/10 6:51 PM, Stephane Nicoll wrote:
>>
>>> On Fri, Nov 12, 2010 at 10:43 AM, Willem Jiang<willem.jiang@gmail.com
>>>> wrote:
>>>
>>> If you put the cxf-servlet here, The ServletTransportFactory will replace
>> all registered transportIds with itself, that could explain why you can't
>> find the JettyTransportFactory here.
>>
>> If you are using the servlet transport, please don't include other http
>> related transport.
>
>
> Okay this works better but now I am getting another weird issue in another
> test. I got a NullPointerException on the PhaseManager. This is the code in
> ClientImpl:
>
> PhaseManager pm = bus.getExtension(PhaseManager.class);
>
> The returned pm instance is null which leads to a NPE latter
> (setupInterceptorChain). I searched where this phase manager was defined and
> it is in cxf.xml which I obviously import.
>
> I tried to build a sample that could run with CXF without our extensions but
> it's quite hard so if you can help me debugging this I would appreciate it.
>
this seems to be similar to the problem I had. Willem posted a
workaround on the camel mailing list.
http://camel.465427.n5.nabble.com/camel-cxf-exception-when-parsing-cxf-schemaLocation-element-td3253254i20.html
regards,
marco
Re: cxf 2.3 and Jetty 7
Posted by Stephane Nicoll <st...@gmail.com>.
On Mon, Nov 15, 2010 at 1:53 AM, Willem Jiang <wi...@gmail.com>wrote:
> On 11/12/10 6:51 PM, Stephane Nicoll wrote:
>
>> On Fri, Nov 12, 2010 at 10:43 AM, Willem Jiang<willem.jiang@gmail.com
>> >wrote:
>>
>> If you put the cxf-servlet here, The ServletTransportFactory will replace
> all registered transportIds with itself, that could explain why you can't
> find the JettyTransportFactory here.
>
> If you are using the servlet transport, please don't include other http
> related transport.
Okay this works better but now I am getting another weird issue in another
test. I got a NullPointerException on the PhaseManager. This is the code in
ClientImpl:
PhaseManager pm = bus.getExtension(PhaseManager.class);
The returned pm instance is null which leads to a NPE latter
(setupInterceptorChain). I searched where this phase manager was defined and
it is in cxf.xml which I obviously import.
I tried to build a sample that could run with CXF without our extensions but
it's quite hard so if you can help me debugging this I would appreciate it.
Thanks,
S.
>
>
> <import resource="classpath*:META-INF/cxf/cxf.xml"/>
>> <import resource="classpath*:META-INF/cxf/cxf-extension-*.xml"/>
>>
>> HTH,
>> S.
>>
>>
>
> --
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
>
SAML how to
Posted by Gary Gregory <GG...@seagullsoftware.com>.
Hi All:
Is there any CXF documentation or examples for using SAML?
Thank you,
Gary Gregory
Senior Software Engineer
Rocket Software
3340 Peachtree Road, Suite 820 . Atlanta, GA 30326 . USA
Email: ggregory@seagullsoftware.com
Web: seagull.rocketsoftware.com
Re: cxf 2.3 and Jetty 7
Posted by Stephane Nicoll <st...@gmail.com>.
On Mon, Nov 15, 2010 at 1:53 AM, Willem Jiang <wi...@gmail.com>wrote:
> On 11/12/10 6:51 PM, Stephane Nicoll wrote:
>
>> On Fri, Nov 12, 2010 at 10:43 AM, Willem Jiang<willem.jiang@gmail.com
>> >wrote:
>>
>>
>> I don't understand what is happening. I have the http-jetty jar in my
>> classpath and I also explicitely added the following in my spring config
>> file:
>> <import resource="classpath*:/META-INF/cxf/cxf-extension-http-jetty.xml"/>
>>
>> Can we use wildcards for this thing? Maybe I am loading another
>> configuration file that registers the same transportId with another
>> protocol? The imports of my project on CXF are:
>>
>> <import resource="classpath*:META-INF/cxf/cxf-servlet.xml"/>
>>
>
> If you put the cxf-servlet here, The ServletTransportFactory will replace
> all registered transportIds with itself, that could explain why you can't
> find the JettyTransportFactory here.
>
> If you are using the servlet transport, please don't include other http
> related transport.
OK, thanks. Can you please clarify how the CXF spring config file should be
used please? I mean, if there are things that override themselves, it needs
to be known.
I will try this and report the success on the issue I created.
Thanks,
Stéphane
>
>
> <import resource="classpath*:META-INF/cxf/cxf.xml"/>
>> <import resource="classpath*:META-INF/cxf/cxf-extension-*.xml"/>
>>
>> HTH,
>> S.
>>
>>
>
> --
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
>
Re: cxf 2.3 and Jetty 7
Posted by Willem Jiang <wi...@gmail.com>.
On 11/12/10 6:51 PM, Stephane Nicoll wrote:
> On Fri, Nov 12, 2010 at 10:43 AM, Willem Jiang<wi...@gmail.com>wrote:
>
>>
>>
>> The SoapTransportFactory will try to locat the real TransportFactory by
>> checking the address.
>> You can find the code from SoapTransportFactory.getDestination() method.
>>
>> Can you just set the break point on the JettyHTTPTransportFactory?
>
>
> Here is more information about this. In SoapTransportFactory#getDestination
>
> * bi [BindingInfo http://schemas.xmlsoap.org/wsdl/soap/]
> * address = http://localhost:7171/MathWebService
> * transId= http://schemas.xmlsoap.org/soap/http
>
> Which leads to a call on DestinationFactoryManagerImpl#getDestinationFactory
> with the "http://cxf.apache.org/transports/http" namespace. The problem is
> that these are my destination factories:
>
>
> - [0] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3059}
> http://www.w3.org/2003/05/soap/bindings/HTTP/ ->
> org.apache.cxf.binding.soap.SoapTransportFactory@12284af
> - [1] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3067}
> http://schemas.xmlsoap.org/soap/http ->
> org.apache.cxf.binding.soap.SoapTransportFactory@12284af
> - [2] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3075}
> http://schemas.xmlsoap.org/wsdl/soap12/ ->
> org.apache.cxf.binding.soap.SoapTransportFactory@12284af
> - [3] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3083}
> http://www.w3.org/2010/soapjms/ ->
> org.apache.cxf.binding.soap.SoapTransportFactory@12284af
> - [4] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3091}
> http://schemas.xmlsoap.org/wsdl/http ->
> org.apache.cxf.transport.servlet.ServletTransportFactory@b20090
> - [5] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3100}
> http://schemas.xmlsoap.org/wsdl/soap/http ->
> org.apache.cxf.binding.soap.SoapTransportFactory@12284af
> - [6] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3108}
> http://cxf.apache.org/transports/http ->
> org.apache.cxf.transport.servlet.ServletTransportFactory@b20090
> - [7] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3116}
> http://schemas.xmlsoap.org/soap/ ->
> org.apache.cxf.binding.soap.SoapTransportFactory@12284af
> - [8] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3124}
> http://cxf.apache.org/transports/http/configuration ->
> org.apache.cxf.transport.servlet.ServletTransportFactory@b20090
> - [9] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3132}
> http://schemas.xmlsoap.org/wsdl/http/ ->
> org.apache.cxf.transport.servlet.ServletTransportFactory@b20090
> - [10] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3140}
> http://schemas.xmlsoap.org/soap/http/ ->
> org.apache.cxf.binding.soap.SoapTransportFactory@12284af
> - [11] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3148}
> http://schemas.xmlsoap.org/wsdl/soap/ ->
> org.apache.cxf.binding.soap.SoapTransportFactory@12284af
>
> No Jetty in there and the returned factory is
> obviously org.apache.cxf.transport.servlet.ServletTransportFactory@b20090
>
> I don't understand what is happening. I have the http-jetty jar in my
> classpath and I also explicitely added the following in my spring config
> file:
> <import resource="classpath*:/META-INF/cxf/cxf-extension-http-jetty.xml"/>
>
> Can we use wildcards for this thing? Maybe I am loading another
> configuration file that registers the same transportId with another
> protocol? The imports of my project on CXF are:
>
> <import resource="classpath*:META-INF/cxf/cxf-servlet.xml"/>
If you put the cxf-servlet here, The ServletTransportFactory will
replace all registered transportIds with itself, that could explain why
you can't find the JettyTransportFactory here.
If you are using the servlet transport, please don't include other http
related transport.
> <import resource="classpath*:META-INF/cxf/cxf.xml"/>
> <import resource="classpath*:META-INF/cxf/cxf-extension-*.xml"/>
>
> HTH,
> S.
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Re: cxf 2.3 and Jetty 7
Posted by Stephane Nicoll <st...@gmail.com>.
On Fri, Nov 12, 2010 at 10:43 AM, Willem Jiang <wi...@gmail.com>wrote:
>
>
> The SoapTransportFactory will try to locat the real TransportFactory by
> checking the address.
> You can find the code from SoapTransportFactory.getDestination() method.
>
> Can you just set the break point on the JettyHTTPTransportFactory?
Here is more information about this. In SoapTransportFactory#getDestination
* bi [BindingInfo http://schemas.xmlsoap.org/wsdl/soap/]
* address = http://localhost:7171/MathWebService
* transId= http://schemas.xmlsoap.org/soap/http
Which leads to a call on DestinationFactoryManagerImpl#getDestinationFactory
with the "http://cxf.apache.org/transports/http" namespace. The problem is
that these are my destination factories:
- [0] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3059}
http://www.w3.org/2003/05/soap/bindings/HTTP/ ->
org.apache.cxf.binding.soap.SoapTransportFactory@12284af
- [1] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3067}
http://schemas.xmlsoap.org/soap/http ->
org.apache.cxf.binding.soap.SoapTransportFactory@12284af
- [2] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3075}
http://schemas.xmlsoap.org/wsdl/soap12/ ->
org.apache.cxf.binding.soap.SoapTransportFactory@12284af
- [3] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3083}
http://www.w3.org/2010/soapjms/ ->
org.apache.cxf.binding.soap.SoapTransportFactory@12284af
- [4] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3091}
http://schemas.xmlsoap.org/wsdl/http ->
org.apache.cxf.transport.servlet.ServletTransportFactory@b20090
- [5] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3100}
http://schemas.xmlsoap.org/wsdl/soap/http ->
org.apache.cxf.binding.soap.SoapTransportFactory@12284af
- [6] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3108}
http://cxf.apache.org/transports/http ->
org.apache.cxf.transport.servlet.ServletTransportFactory@b20090
- [7] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3116}
http://schemas.xmlsoap.org/soap/ ->
org.apache.cxf.binding.soap.SoapTransportFactory@12284af
- [8] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3124}
http://cxf.apache.org/transports/http/configuration ->
org.apache.cxf.transport.servlet.ServletTransportFactory@b20090
- [9] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3132}
http://schemas.xmlsoap.org/wsdl/http/ ->
org.apache.cxf.transport.servlet.ServletTransportFactory@b20090
- [10] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3140}
http://schemas.xmlsoap.org/soap/http/ ->
org.apache.cxf.binding.soap.SoapTransportFactory@12284af
- [11] = {java.util.concurrent.ConcurrentHashMap$WriteThroughEntry@3148}
http://schemas.xmlsoap.org/wsdl/soap/ ->
org.apache.cxf.binding.soap.SoapTransportFactory@12284af
No Jetty in there and the returned factory is
obviously org.apache.cxf.transport.servlet.ServletTransportFactory@b20090
I don't understand what is happening. I have the http-jetty jar in my
classpath and I also explicitely added the following in my spring config
file:
<import resource="classpath*:/META-INF/cxf/cxf-extension-http-jetty.xml"/>
Can we use wildcards for this thing? Maybe I am loading another
configuration file that registers the same transportId with another
protocol? The imports of my project on CXF are:
<import resource="classpath*:META-INF/cxf/cxf-servlet.xml"/>
<import resource="classpath*:META-INF/cxf/cxf.xml"/>
<import resource="classpath*:META-INF/cxf/cxf-extension-*.xml"/>
HTH,
S.
Re: cxf 2.3 and Jetty 7
Posted by Willem Jiang <wi...@gmail.com>.
On 11/12/10 5:21 PM, Stephane Nicoll wrote:
> Hi Dan,
>
> Thanks for the tip. There is indeed a difference between CXF 2.2.11 and CXF
> 2.3.0 with the exact same configuration (I just flip the cxf version in my
> pom and rerun my simple unit test with embedded Jetty).
>
> The destinationFactory is not the same (see
> org.apache.cxf.endpoint.AbstractEndpointFactory):
>
> * CXF 2.2.11: org.apache.cxf.transport.http_jetty.JettyHTTPTransportFactory
> * CXF 2.3: org.apache.cxf.binding.soap.SoapTransportFactory
The SoapTransportFactory will try to locat the real TransportFactory by
checking the address.
You can find the code from SoapTransportFactory.getDestination() method.
Can you just set the break point on the JettyHTTPTransportFactory?
>
> I have tried to debug when the destination factory gets injected but found
> nothing. The setter is not called (according to my debugger) and the
> protected field does not seem to be set anywhere. It feels like it's set by
> reflection or something like that.
>
> Anyway, since the destination factory is not the proper one, CXF deploys my
> web service as if I was in a running servlet container. The next step for me
> would be to understand why the JettyHTTPTransportFactory is not set anymore.
>
> Any thoughts?
>
> Thanks,
> S.
>
> On Thu, Nov 4, 2010 at 4:02 AM, Daniel Kulp<dk...@apache.org> wrote:
>
>> On Monday 01 November 2010 1:13:41 pm Stephane Nicoll wrote:
>>> Any idea where I should look ?
>>>
>>
>> Well, it really shouldn't startup until an endpoint is actually published
>> on
>> the given port. As parrt of the publish step, a listener/callback is set
>> onto the Destination at which point the JettyDestination creates a Jetty
>> handler thing for it and creates the Jetty server for the port and starts
>> it
>> up. Thus, trace through from the Jetty Destination subclass.
>>
>> Dan
>>
>>
>>> On Wed, Oct 27, 2010 at 10:33 AM, Stephane Nicoll
>>> <stephane.nicoll@gmail.com
>>>
>>>> wrote:
>>>>
>>>> A plain old maven2 module with Spring 2.5. No OSGI.
>>>>
>>>> The thing I really don't understand is what does trigger the actual
>>>> startup of Jetty. Looking at the samples, it should be located in the
>>>> processing of the namespace somehow but if I copy/paste the
>>>> CherrServer.xml in my project, jetty does not start.
>>>>
>>>> Thanks,
>>>> S.
>>>>
>>>> On Wed, Oct 27, 2010 at 9:48 AM, Willem Jiang
>> <wi...@gmail.com>wrote:
>>>>> Are you deploying the example into an OSGi platform?
>>>>> If so there may be some issue, I will have a look at it if I get some
>>>>> time tomorrow.
>>>>>
>>>>> Willem
>>>>>
>>>>> On 10/27/10, Stephane Nicoll<st...@gmail.com> wrote:
>>>>>> Hi there,
>>>>>>
>>>>>> I started from the base and thought the samples would answer my
>>>>>> original issue. I downloaded the official apache-cxf 2.3.0
>>>>>> distribution from apache.org, had a look and found all kinds of
>>>>>> reference to
>>>>>> "org.mortbay.jetty". If I try to run these samples, I am getting an
>>>>>
>>>>> obvious
>>>>>
>>>>>> ClassNotFoundException since Jett7 is used.
>>>>>>
>>>>>> However, jax_rs\basic_https is working fine and I copy/pasted the
>>>>>> cherryServer.xml in my project but jetty does not seem to start.
>>>>>>
>>>>>> What am I missing? Especially since the same config works just fine
>>>>>> with 2.2.11 (and Jetty 6)
>>>>>>
>>>>>> S.
>>>>>>
>>>>>> On Wed, Oct 20, 2010 at 10:41 AM, Willem Jiang
>>>>>>
>>>>>> <wi...@gmail.com>wrote:
>>>>>>> There is no other different configuration on the jetty7 to start
>> the
>>>>>>> embedded server.
>>>>>>> Can you take a look at the CXF 2.3.0 system tests, we didn't face
>>>>>>> that kind
>>>>>>> of issue before?
>>>>>>>
>>>>>>> BTW, what's address that your service was published?
>>>>>>>
>>>>>>> On 10/20/10 4:14 PM, Stephane Nicoll wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> We are trying to upgrade our application from 2.2.10 to 2.3.0 and
>>>>>
>>>>> we're
>>>>>
>>>>>>>> facing an issue with embedded Jetty7
>>>>>>>>
>>>>>>>> We have a set of unit tests starting CXF with an embedded jetty.
>>>>>>>> First
>>>>>
>>>>> we
>>>>>
>>>>>>>> had to rename some classes since the move to eclipse but the real
>>>>>
>>>>> issue
>>>>>
>>>>>>>> is
>>>>>>>> that while CXF states it has deployed our Web Service, all the
>> unit
>>>>>
>>>>> tests
>>>>>
>>>>>>>> are failing with a ConnectionException now.
>>>>>>>>
>>>>>>>> Do you have a working setup somewhere of embedded jetty with unit
>>>>>
>>>>> tests
>>>>>
>>>>>>>> and
>>>>>>>> cxf 2.3? I had a look to the doc but it does not seem up to date
>> in
>>>>>
>>>>> that
>>>>>
>>>>>>>> area.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> S.
>>>>>>>
>>>>>>> --
>>>>>>> Willem
>>>>>>> ----------------------------------
>>>>>>> Open Source Integration: http://www.fusesource.com
>>>>>>> Blog: http://willemjiang.blogspot.com (English)
>>>>>>>
>>>>>>> http://jnn.javaeye.com (Chinese)
>>>>>>>
>>>>>>> Twitter: http://twitter.com/willemjiang
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://dankulp.com/blog
>>
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Re: cxf 2.3 and Jetty 7
Posted by Stephane Nicoll <st...@gmail.com>.
Hi Dan,
Thanks for the tip. There is indeed a difference between CXF 2.2.11 and CXF
2.3.0 with the exact same configuration (I just flip the cxf version in my
pom and rerun my simple unit test with embedded Jetty).
The destinationFactory is not the same (see
org.apache.cxf.endpoint.AbstractEndpointFactory):
* CXF 2.2.11: org.apache.cxf.transport.http_jetty.JettyHTTPTransportFactory
* CXF 2.3: org.apache.cxf.binding.soap.SoapTransportFactory
I have tried to debug when the destination factory gets injected but found
nothing. The setter is not called (according to my debugger) and the
protected field does not seem to be set anywhere. It feels like it's set by
reflection or something like that.
Anyway, since the destination factory is not the proper one, CXF deploys my
web service as if I was in a running servlet container. The next step for me
would be to understand why the JettyHTTPTransportFactory is not set anymore.
Any thoughts?
Thanks,
S.
On Thu, Nov 4, 2010 at 4:02 AM, Daniel Kulp <dk...@apache.org> wrote:
> On Monday 01 November 2010 1:13:41 pm Stephane Nicoll wrote:
> > Any idea where I should look ?
> >
>
> Well, it really shouldn't startup until an endpoint is actually published
> on
> the given port. As parrt of the publish step, a listener/callback is set
> onto the Destination at which point the JettyDestination creates a Jetty
> handler thing for it and creates the Jetty server for the port and starts
> it
> up. Thus, trace through from the Jetty Destination subclass.
>
> Dan
>
>
> > On Wed, Oct 27, 2010 at 10:33 AM, Stephane Nicoll
> > <stephane.nicoll@gmail.com
> >
> > > wrote:
> > >
> > > A plain old maven2 module with Spring 2.5. No OSGI.
> > >
> > > The thing I really don't understand is what does trigger the actual
> > > startup of Jetty. Looking at the samples, it should be located in the
> > > processing of the namespace somehow but if I copy/paste the
> > > CherrServer.xml in my project, jetty does not start.
> > >
> > > Thanks,
> > > S.
> > >
> > > On Wed, Oct 27, 2010 at 9:48 AM, Willem Jiang
> <wi...@gmail.com>wrote:
> > >> Are you deploying the example into an OSGi platform?
> > >> If so there may be some issue, I will have a look at it if I get some
> > >> time tomorrow.
> > >>
> > >> Willem
> > >>
> > >> On 10/27/10, Stephane Nicoll <st...@gmail.com> wrote:
> > >> > Hi there,
> > >> >
> > >> > I started from the base and thought the samples would answer my
> > >> > original issue. I downloaded the official apache-cxf 2.3.0
> > >> > distribution from apache.org, had a look and found all kinds of
> > >> > reference to
> > >> > "org.mortbay.jetty". If I try to run these samples, I am getting an
> > >>
> > >> obvious
> > >>
> > >> > ClassNotFoundException since Jett7 is used.
> > >> >
> > >> > However, jax_rs\basic_https is working fine and I copy/pasted the
> > >> > cherryServer.xml in my project but jetty does not seem to start.
> > >> >
> > >> > What am I missing? Especially since the same config works just fine
> > >> > with 2.2.11 (and Jetty 6)
> > >> >
> > >> > S.
> > >> >
> > >> > On Wed, Oct 20, 2010 at 10:41 AM, Willem Jiang
> > >> >
> > >> > <wi...@gmail.com>wrote:
> > >> >> There is no other different configuration on the jetty7 to start
> the
> > >> >> embedded server.
> > >> >> Can you take a look at the CXF 2.3.0 system tests, we didn't face
> > >> >> that kind
> > >> >> of issue before?
> > >> >>
> > >> >> BTW, what's address that your service was published?
> > >> >>
> > >> >> On 10/20/10 4:14 PM, Stephane Nicoll wrote:
> > >> >>> Hi,
> > >> >>>
> > >> >>> We are trying to upgrade our application from 2.2.10 to 2.3.0 and
> > >>
> > >> we're
> > >>
> > >> >>> facing an issue with embedded Jetty7
> > >> >>>
> > >> >>> We have a set of unit tests starting CXF with an embedded jetty.
> > >> >>> First
> > >>
> > >> we
> > >>
> > >> >>> had to rename some classes since the move to eclipse but the real
> > >>
> > >> issue
> > >>
> > >> >>> is
> > >> >>> that while CXF states it has deployed our Web Service, all the
> unit
> > >>
> > >> tests
> > >>
> > >> >>> are failing with a ConnectionException now.
> > >> >>>
> > >> >>> Do you have a working setup somewhere of embedded jetty with unit
> > >>
> > >> tests
> > >>
> > >> >>> and
> > >> >>> cxf 2.3? I had a look to the doc but it does not seem up to date
> in
> > >>
> > >> that
> > >>
> > >> >>> area.
> > >> >>>
> > >> >>> Thanks,
> > >> >>> S.
> > >> >>
> > >> >> --
> > >> >> Willem
> > >> >> ----------------------------------
> > >> >> Open Source Integration: http://www.fusesource.com
> > >> >> Blog: http://willemjiang.blogspot.com (English)
> > >> >>
> > >> >> http://jnn.javaeye.com (Chinese)
> > >> >>
> > >> >> Twitter: http://twitter.com/willemjiang
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
Re: cxf 2.3 and Jetty 7
Posted by Daniel Kulp <dk...@apache.org>.
On Monday 01 November 2010 1:13:41 pm Stephane Nicoll wrote:
> Any idea where I should look ?
>
Well, it really shouldn't startup until an endpoint is actually published on
the given port. As parrt of the publish step, a listener/callback is set
onto the Destination at which point the JettyDestination creates a Jetty
handler thing for it and creates the Jetty server for the port and starts it
up. Thus, trace through from the Jetty Destination subclass.
Dan
> On Wed, Oct 27, 2010 at 10:33 AM, Stephane Nicoll
> <stephane.nicoll@gmail.com
>
> > wrote:
> >
> > A plain old maven2 module with Spring 2.5. No OSGI.
> >
> > The thing I really don't understand is what does trigger the actual
> > startup of Jetty. Looking at the samples, it should be located in the
> > processing of the namespace somehow but if I copy/paste the
> > CherrServer.xml in my project, jetty does not start.
> >
> > Thanks,
> > S.
> >
> > On Wed, Oct 27, 2010 at 9:48 AM, Willem Jiang
<wi...@gmail.com>wrote:
> >> Are you deploying the example into an OSGi platform?
> >> If so there may be some issue, I will have a look at it if I get some
> >> time tomorrow.
> >>
> >> Willem
> >>
> >> On 10/27/10, Stephane Nicoll <st...@gmail.com> wrote:
> >> > Hi there,
> >> >
> >> > I started from the base and thought the samples would answer my
> >> > original issue. I downloaded the official apache-cxf 2.3.0
> >> > distribution from apache.org, had a look and found all kinds of
> >> > reference to
> >> > "org.mortbay.jetty". If I try to run these samples, I am getting an
> >>
> >> obvious
> >>
> >> > ClassNotFoundException since Jett7 is used.
> >> >
> >> > However, jax_rs\basic_https is working fine and I copy/pasted the
> >> > cherryServer.xml in my project but jetty does not seem to start.
> >> >
> >> > What am I missing? Especially since the same config works just fine
> >> > with 2.2.11 (and Jetty 6)
> >> >
> >> > S.
> >> >
> >> > On Wed, Oct 20, 2010 at 10:41 AM, Willem Jiang
> >> >
> >> > <wi...@gmail.com>wrote:
> >> >> There is no other different configuration on the jetty7 to start the
> >> >> embedded server.
> >> >> Can you take a look at the CXF 2.3.0 system tests, we didn't face
> >> >> that kind
> >> >> of issue before?
> >> >>
> >> >> BTW, what's address that your service was published?
> >> >>
> >> >> On 10/20/10 4:14 PM, Stephane Nicoll wrote:
> >> >>> Hi,
> >> >>>
> >> >>> We are trying to upgrade our application from 2.2.10 to 2.3.0 and
> >>
> >> we're
> >>
> >> >>> facing an issue with embedded Jetty7
> >> >>>
> >> >>> We have a set of unit tests starting CXF with an embedded jetty.
> >> >>> First
> >>
> >> we
> >>
> >> >>> had to rename some classes since the move to eclipse but the real
> >>
> >> issue
> >>
> >> >>> is
> >> >>> that while CXF states it has deployed our Web Service, all the unit
> >>
> >> tests
> >>
> >> >>> are failing with a ConnectionException now.
> >> >>>
> >> >>> Do you have a working setup somewhere of embedded jetty with unit
> >>
> >> tests
> >>
> >> >>> and
> >> >>> cxf 2.3? I had a look to the doc but it does not seem up to date in
> >>
> >> that
> >>
> >> >>> area.
> >> >>>
> >> >>> Thanks,
> >> >>> S.
> >> >>
> >> >> --
> >> >> Willem
> >> >> ----------------------------------
> >> >> Open Source Integration: http://www.fusesource.com
> >> >> Blog: http://willemjiang.blogspot.com (English)
> >> >>
> >> >> http://jnn.javaeye.com (Chinese)
> >> >>
> >> >> Twitter: http://twitter.com/willemjiang
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog