You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Joe Sunday <su...@csh.rit.edu> on 2007/09/01 00:12:53 UTC
Re: Schema for namespace 'http://localhost/Service already contains type 'foo
Thanks a bunch.
One more question.. Is there a way to keep cookies automatically on a
session?
The remote end is sending a Set-Cookie: header on the first request,
but it doesn't get sent back in future requests.
I thought this was right from some googling, but it doesn't seem to
work..
((BindingProvider)client).getRequestContext().put
(BindingProvider.SESSION_MAINTAIN_PROPERTY, true);
--Joe
On Aug 31, 2007, at 2:17 PM, Daniel Kulp wrote:
>
> Just FYI: I can reproduce this. I'm working on a fix now.
>
> Dan
>
>
>
> On Friday 31 August 2007, Joe Sunday wrote:
>> Actually, in the end, I did switch back to jaxb and option 2 to
>> change Foo to something else. The aegis binding was having some other
>> issues with multiple namespaces in the wsdl files it generated I need
>> to distill into a test case (It works with more or less the same
>> structure in XFire though)
>>
>> I'm still having an issue with combining interfaces using CXF though
>> that's problematic on the client side.
>>
>> If I do the CoreService, AppService, and PublicService as defined
>> below, XFire could take PublicService and a JDK proxy object and
>> construct all the correct methods. On the server, I can create an
>> abstract fake class and pass it as the implementorClass which seems
>> to work:
>> @WebService(endpointInterface="package.PublicService", ...)
>> public abstract class PublicServiceFake implements PublicService { }
>>
>> On the client, if I try to create a client based on PublicService, it
>> finds and can invoke the methods on CoreService, but throws an error
>> it can't find information on methodOne when I try to invoke it.
>> (Sorry, don't have the stack trace in front of me right now.. I can
>> recreate it sometime later today) All the methods on all interfaces
>> are annotated with @WebMethod and @WebParam annotations.
>>
>> If I do "AppService extends CoreService" and then configure an
>> AppService, I get the same result. If I then do "PublicService
>> extends AppService" (instead of "PublicService extends CoreService,
>> AppService), it works on the client but seems clunky that it can't
>> properly find all the WebMethod functions on the multiple direct
>> child interface case. In some cases, we have PublicService extending
>> 3 or more child interfaces depending on the app, but it only finds
>> methods in the first child interface.
>>
>> This is in both 2.0.1 and yesterday's 2.1 snapshot.
>>
>> --Joe
>>
>> On Aug 31, 2007, at 1:00 PM, Daniel Kulp wrote:
>>> Other options would be:
>>>
>>> 1) add @WebMethod(name = "fooOperation") to the operation (to
>>> generate the wrapper element with that name
>>>
>>> 2) change/remove the @XmlRootElement annotation in the "Foo" class
>>> to make it not generate a Foo element. (may need to combine with
>>> 3)
>>>
>>> 3) add @WebResult annotation with a name set to "FooResult" or
>>> something
>>> to give it a unique name.
>>>
>>> Dan
>>>
>>> On Thursday 30 August 2007, Joe Sunday wrote:
>>>> As an update to this after spending some more time trying to unwind
>>>> it...
>>>>
>>>> It appears the problem was actually due to a method in one of my
>>>> interfaces:
>>>> Foo foo(...)
>>>>
>>>> JAXB would collide the Foo type and the foo method. Setting up an
>>>> Aegis binding instead seems to have cleared it up.
>>>>
>>>> --Joe
>>>>
>>>> On Aug 30, 2007, at 2:44 AM, Joe Sunday wrote:
>>>>> I'm trying to migrate an existing framework from Xfire over to CXF
>>>>> (2.0.1 and tonight's 2.1 snapshot), and I can't get it to play
>>>>> nice.
>>>>>
>>>>> There's a core framework that exports a web service interface of a
>>>>> few methods. We have an additional application that builds on top
>>>>> of that with it's own interface:
>>>>>
>>>>> @WebService(...)
>>>>> public interface CoreService {
>>>>> @WebMethod(...)
>>>>> Foo foo(...)
>>>>> }
>>>>>
>>>>> @WebService(...)
>>>>> public interface AppService {
>>>>> @WebMethod
>>>>> ServiceResult methodOne(...)
>>>>>
>>>>> @WebMethod
>>>>> ServiceResult methodTwo(...)
>>>>> }
>>>>>
>>>>> Then we aggregate them together with a new interface that we
>>>>> actually want exported:
>>>>> @WebService(name = "MyService", targetNamespace =
>>>>> "http://localhost/ Service")
>>>>> public interface PublicService extends CoreService, AppService {
>>>>> }
>>>>>
>>>>> Actually implementing methodXXX is handled by a JDK proxy class
>>>>> created by a factory in Spring that implements PublicService and
>>>>> the InvocationHandler maps them back to the right implementation.
>>>>> There is no actual Impl class to speak of.
>>>>>
>>>>> If I setup my endpoint like this:
>>>>> <jaxws:endpoint
>>>>> id="helloWorld"
>>>>> implementor="#publicServiceProxy"
>>>>> address="/SnapManager" />
>>>>>
>>>>> I get this during startup:
>>>>> org.springframework.beans.factory.BeanCreationException: Error
>>>>> creating bean with name 'helloWorld': Invocation of init method
>>>>> failed; nested except
>>>>> ion is java.lang.RuntimeException: Schema for namespace 'http://
>>>>> localhost/Service' already contains type 'foo
>>>>> Caused by:
>>>>> java.lang.RuntimeException: Schema for namespace
>>>>> 'http://localhost/ Service' already contains type 'foo
>>>>> at org.apache.ws.commons.schema.XmlSchema.addType
>>>>> (XmlSchema.java:229)
>>>>> at
>>>>> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create
>>>>> Wr ap pedMessageSchema(ReflectionServiceFactoryBean.java:660) at
>>>>> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create
>>>>> Wr ap pedSchema(ReflectionServiceFactoryBean.java:511)
>>>>> at
>>>>> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initia
>>>>> li ze WrappedSchema(ReflectionServiceFactoryBean.java:430)
>>>>> at
>>>>> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildS
>>>>> er vi ceFromClass(ReflectionServiceFactoryBean.java:240)
>>>>> at
>>>>> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initia
>>>>> li ze ServiceModel(ReflectionServiceFactoryBean.java:264)
>>>>> at
>>>>> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create
>>>>> (ReflectionServiceFactoryBean.java:143)
>>>>> at
>>>>> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create
>>>>> (JaxWsServiceFactoryBean.java:89)
>>>>> at
>>>>> org.apache.cxf.frontend.AbstractEndpointFactory.createEndpoint
>>>>> (AbstractEndpointFactory.java:82)
>>>>> at org.apache.cxf.frontend.ServerFactoryBean.create
>>>>> (ServerFactoryBean.java:107)
>>>>> at org.apache.cxf.jaxws.JaxWsServerFactoryBean.create
>>>>> (JaxWsServerFactoryBean.java:147)
>>>>> at org.apache.cxf.jaxws.EndpointImpl.getServer
>>>>> (EndpointImpl.java:287)
>>>>> at org.apache.cxf.jaxws.EndpointImpl.doPublish
>>>>> (EndpointImpl.java:227)
>>>>> at org.apache.cxf.jaxws.EndpointImpl.publish
>>>>> (EndpointImpl.java:179)
>>>>> at org.apache.cxf.jaxws.EndpointImpl.publish
>>>>> (EndpointImpl.java:340)
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>>>>> Method) at sun.reflect.NativeMethodAccessorImpl.invoke
>>>>> (NativeMethodAccessorImpl.java:39)
>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke
>>>>> (DelegatingMethodAccessorImpl.java:25)
>>>>> at java.lang.reflect.Method.invoke(Method.java:585)
>>>>>
>>>>> I tried giving it a class to find the annotations on as well
>>>>> (though I didn't need this in XFire, it just read off the
>>>>> Interface correctly):
>>>>> @WebService(endpointInterface = "com.myapp.PublicService")
>>>>> public abstract class PublicServiceFake implements PublicService {
>>>>> }
>>>>>
>>>>> and pointing the endpoint to it in Spring:
>>>>> implementorClass="com.myapp.SnapManagerServiceFake"
>>>>>
>>>>> with the same result. If I remove the "implements PublicService"
>>>>> part, it'll startup, but then the generated wsdl doesn't actually
>>>>> have any methods in it.
>>>>>
>>>>> In XFire, my config looked like this (publicServiceProxy:
>>>>>
>>>>> <bean name="xfire.annotationServiceFactory"
>>>>> class="org.codehaus.xfire.annotations.AnnotationServiceFactory">
>>>>> <constructor-arg index="0">
>>>>> <bean
>>>>> class="org.codehaus.xfire.annotations.jsr181.Jsr181WebAnnotations"
>>>>> /> </constructor-arg>
>>>>> <constructor-arg index="1" ref="xfire.transportManager" />
>>>>> </bean>
>>>>>
>>>>> <bean name="myService"
>>>>> class="org.codehaus.xfire.spring.remoting.XFireExporter">
>>>>> <property name="serviceBean" ref="publicServiceProxy" />
>>>>> <property name="serviceInterface"
>>>>> value="com.myapp.PublicService" />
>>>>> <property name="serviceFactory"
>>>>> ref="xfire.annotationServiceFactory"/>
>>>>> <property name="xfire" ref="xfire"/>
>>>>> <property name="properties"> <!-- This property is needed to
>>>>> allow eclipse tools to properly validate the WSDL file -->
>>>>> <map>
>>>>> <entry>
>>>>> <key>
>>>>> <value>wsdlBuilder.generateImports</value>
>>>>> </key>
>>>>> <value>true</value>
>>>>> </entry>
>>>>> </map>
>>>>> </property>
>>>>> </bean>
>>>>> --Joe
>>>
>>> --
>>> J. Daniel Kulp
>>> Principal Engineer
>>> IONA
>>> P: 781-902-8727 C: 508-380-7194
>>> daniel.kulp@iona.com
>>> http://www.dankulp.com/blog
>
>
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194
> daniel.kulp@iona.com
> http://www.dankulp.com/blog
Re: Broken SESSION_MAINTAIN_PROPERTY against non-jaxws servers
Posted by Willem Jiang <ni...@iona.com>.
Hi Joe,
Yes, CXF leverage the Jetty's session support to implement the session
maintaining. But I am not sure it just tracks the JSESSIONID.
You can create a JIRA [1] and attach the patch with it.
[1] http://issues.apache.org/jira/browse/CXF
Willem.
Joe Sunday wrote:
> As a followup, I've got a patch for 2.0.1 that tracks all cookies if
> SESSION_MAINTAIN_PROPERTY is set. I just need to clean it up a bit and
> let me know where to send it.
>
> It doesn't follow all the RFC rules for host / domain / path security,
> but then again neither does the current code, and I'm not sure it
> matters in this case anyway.
>
> --Joe
>
> On Sep 1, 2007, at 1:06 AM, Joe Sunday wrote:
>
>> It looks like CXF only tracks JSESSIONID and throws away any other
>> cookies.
>>
>> There's a bunch of non-java based services out there that use other
>> session cookies. If SESSION_MAINTAIN_PROPERTY is set, it should track
>> all the cookies on the session, not just JSESSIONID.
>>
>> --Joe
>
Re: Broken SESSION_MAINTAIN_PROPERTY against non-jaxws servers
Posted by Joe Sunday <su...@csh.rit.edu>.
As a followup, I've got a patch for 2.0.1 that tracks all cookies if
SESSION_MAINTAIN_PROPERTY is set. I just need to clean it up a bit
and let me know where to send it.
It doesn't follow all the RFC rules for host / domain / path
security, but then again neither does the current code, and I'm not
sure it matters in this case anyway.
--Joe
On Sep 1, 2007, at 1:06 AM, Joe Sunday wrote:
> It looks like CXF only tracks JSESSIONID and throws away any other
> cookies.
>
> There's a bunch of non-java based services out there that use other
> session cookies. If SESSION_MAINTAIN_PROPERTY is set, it should
> track all the cookies on the session, not just JSESSIONID.
>
> --Joe
Broken SESSION_MAINTAIN_PROPERTY against non-jaxws servers
Posted by Joe Sunday <su...@csh.rit.edu>.
It looks like CXF only tracks JSESSIONID and throws away any other
cookies.
There's a bunch of non-java based services out there that use other
session cookies. If SESSION_MAINTAIN_PROPERTY is set, it should track
all the cookies on the session, not just JSESSIONID.
--Joe
On Aug 31, 2007, at 6:12 PM, Joe Sunday wrote:
> Thanks a bunch.
>
> One more question.. Is there a way to keep cookies automatically on
> a session?
>
> The remote end is sending a Set-Cookie: header on the first
> request, but it doesn't get sent back in future requests.
> I thought this was right from some googling, but it doesn't seem to
> work..
> ((BindingProvider)client).getRequestContext().put
> (BindingProvider.SESSION_MAINTAIN_PROPERTY, true);
>
> --Joe
>
> On Aug 31, 2007, at 2:17 PM, Daniel Kulp wrote: