Re: Supressing generation of xs:extension against inheritance
Thanks for the suggestions. I guess I'll live with the xs:extensions for now (I guess they don't really affect the actual XML structure, save element ordering). Phil :n. On Thu, 2008-01-31 at 17:06 -0500, Benson Margulies wrote: On Thu, 2008-01-31 at 17:01 -0500, Daniel Kulp wrote: Honestly, looking at the jaxb spec, I don't see anything that would allow that.Thats something you may want to ask on the jaxb lists: https://jaxb.dev.java.net/servlets/ProjectMailingListList There might be some hidden flag or something that could be used to set it. I don't really know. (sort of) As per the blog posting I wrote at dssheep.blogspot.com, you could consider the following methodology: 1) Use your current classes as sacrificial. 2) Edit the XSD until you like it. 3) Regenerate new classes. The new classes will be redundant, but will that really hurt? You could also whip up a set of facade wrappers that delegate your interfaces to them.
Re: CXF on WebLogic 9.2
Hello,
I've had a similar problem before and I think you can fix it with a
prefer-web-inf-classes
element in your weblogic.xml. See here:
http://e-docs.bea.com/wls/docs92/webapp/weblogic_xml.html
To set this on a server wide basis see here:
http://e-docs.bea.com/wls/docs92/programming/classloading.html
Hope this helps,
Barry
On Jan 31, 2008 9:07 PM, Daniel Kulp [EMAIL PROTECTED] wrote:
FYI: for 2.0.4, we specifically switched to the geronimo version as it
does NOT have the QName class in it like the stax-api version that we
used in 2.0.3 does. Thus, the problem should be reduced.
Dan
On Thursday 31 January 2008, William Zhu wrote:
on CXF2.0.4, it's geronimo-stax-api_1.0_spec-1.0.jar.
chengas123 [EMAIL PROTECTED] wrote:
Haha. I would have realized that was the same .jar
The only one included in 2.0.4 is stax-utils-20060502.jar
YI (William) ZHU wrote:
actually, it's stax-api-1.0.1.jar.
(on CXF 2.0.2 and CXF 2.0.3)
chengas123 wrote:
I downloaded apache-cxf-2.0.4-incubator.tar.gz and could not find
any file name stax-api.jar in the lib directory.
YI (William) ZHU wrote:
stax-api jar file is in \{CXF-home}\lib
unpackage it, you will find the javax.xml.namespace.QName class.
delete it, and re-package the file.
try it.
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
Re: cxf RESTful samples - addCustomer (by http POST) doesn't work
Hi, I had this problem too with the latest snapshot. I added a @ConsumeMime(text/xml) to the method and it seemed to fix it. Barry On Feb 1, 2008 11:37 AM, sedo [EMAIL PROTECTED] wrote: I write my own sample according to restful_http_binding But when using Client and addCustomer(Customer c) method, it throws something like this: (same thing when I add addCustomer method to the client in cxf sample): pls help :-/ org.apache.cxf.phase.PhaseInterceptorChain doIntercept INFO: Interceptor has thrown exception, unwinding now org.apache.cxf.interceptor.Fault: Could not send Message. at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage (MessageSenderInterceptor.java:64) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept( PhaseInterceptorChain.java:207) at org.apache.cxf.binding.http.interceptor.DatabindingOutSetupInterceptor.handleMessage (DatabindingOutSetupInterceptor.java:91) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept( PhaseInterceptorChain.java:207) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:254) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:205) at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135) at $Proxy25.addPerson(Unknown Source) at sk.posam.ws.restwebservice.client.Client.main(Client.java:43) Caused by: java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(Unknown Source) at java.io.BufferedInputStream.fill(Unknown Source) at java.io.BufferedInputStream.read1(Unknown Source) at java.io.BufferedInputStream.read(Unknown Source) at sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source) at sun.net.www.http.HttpClient.parseHTTP(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) at java.net.HttpURLConnection.getResponseCode(Unknown Source) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse (HTTPConduit.java:1863) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close( HTTPConduit.java:1791) at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66) at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:575) at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage (MessageSenderInterceptor.java:62) ... 9 more Exception in thread main javax.xml.ws.http.HTTPException at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:147) at $Proxy25.addPerson(Unknown Source) at sk.posam.ws.restwebservice.client.Client.main(Client.java:43) Caused by: org.apache.cxf.interceptor.Fault: Could not send Message. at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage (MessageSenderInterceptor.java:64) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept( PhaseInterceptorChain.java:207) at org.apache.cxf.binding.http.interceptor.DatabindingOutSetupInterceptor.handleMessage (DatabindingOutSetupInterceptor.java:91) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept( PhaseInterceptorChain.java:207) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:254) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:205) at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135) ... 2 more Caused by: java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(Unknown Source) at java.io.BufferedInputStream.fill(Unknown Source) at java.io.BufferedInputStream.read1(Unknown Source) at java.io.BufferedInputStream.read(Unknown Source) at sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source) at sun.net.www.http.HttpClient.parseHTTP(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) at java.net.HttpURLConnection.getResponseCode(Unknown Source) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse (HTTPConduit.java:1863) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close( HTTPConduit.java:1791) at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66) at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:575) at
Re: Different bevaviour in 2.0.4
Ah maybe that's better info. Going back to the default bindings (commenting out the Aegis stuff) I get: Testcase: test5SoapRemoting (com.surgex.mafaddresslookup.service.AddressLookupServiceIntegrationTest ): Caused an ERROR [junit] Marshalling Error: java.util.Map is not known to this context [junit] javax.xml.ws.soap.SOAPFaultException: Marshalling Error: java.util.Map is not known to this context [junit] at org.apache.cxf.jaxws.JaxWsClientProxy.invoke (JaxWsClientProxy.java:175) [junit] at $Proxy30.lookupUK(Unknown Source) [junit] at com.surgex.addresslookup.service.AddressLookupServiceIntegrationTest.exe cuteTests(AddressLookupServiceIntegrationTest.java:216) [junit] at com.surgex.addresslookup.service.AddressLookupServiceIntegrationTest.tes t5SoapRemoting(AddressLookupServiceIntegrationTest.java:158) [junit] at org.springframework.test.ConditionalTestCase.runBare (ConditionalTestCase.java:76) [junit] Caused by: org.apache.cxf.interceptor.Fault: Marshalling Error: java.util.Map is not known to this context [junit] at org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall (JAXBEncoderDecoder.java:207) [junit] at org.apache.cxf.jaxb.io.DataWriterImpl.write (DataWriterImpl.java:63) [junit] at org.apache.cxf.interceptor.AbstractOutDatabindingInterceptor.writeParts( AbstractOutDatabindingInterceptor.java:84) [junit] at org.apache.cxf.interceptor.BareOutInterceptor.handleMessage (BareOutInterceptor.java:68) [junit] at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept (PhaseInterceptorChain.java:208) [junit] at org.apache.cxf.endpoint.ClientImpl.invoke (ClientImpl.java:276) [junit] at org.apache.cxf.endpoint.ClientImpl.invoke (ClientImpl.java:222) [junit] at org.apache.cxf.frontend.ClientProxy.invokeSync (ClientProxy.java:73) [junit] at org.apache.cxf.jaxws.JaxWsClientProxy.invoke (JaxWsClientProxy.java:135) [junit] Caused by: javax.xml.bind.MarshalException [junit] - with linked exception: [junit] [javax.xml.bind.JAXBException: java.util.Map is not known to this context] [junit] at com.sun.xml.bind.v2.runtime.MarshallerImpl.write (MarshallerImpl.java:295) [junit] at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal (MarshallerImpl.java:221) [junit] at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal (AbstractMarshallerImpl.java:70) [junit] at org.apache.cxf.jaxb.JAXBEncoderDecoder.writeObject (JAXBEncoderDecoder.java:360) [junit] at org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall (JAXBEncoderDecoder.java:187) [junit] Caused by: javax.xml.bind.JAXBException: java.util.Map is not known to this context [junit] at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError (XMLSerializer.java:223) [junit] at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError (XMLSerializer.java:238) [junit] at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl $1.serializeBody(ElementBeanInfoImpl.java:85) [junit] at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl $1.serializeBody(ElementBeanInfoImpl.java:127) [junit] at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeBody (ElementBeanInfoImpl.java:244) [junit] at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot (ElementBeanInfoImpl.java:251) [junit] at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot (ElementBeanInfoImpl.java:33) [junit] at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot (XMLSerializer.java:461) [junit] at com.sun.xml.bind.v2.runtime.MarshallerImpl.write (MarshallerImpl.java:292) [junit] Caused by: javax.xml.bind.JAXBException: java.util.Map is not known to this context [junit] at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getBeanInfo (JAXBContextImpl.java:538) [junit] at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl $1.serializeBody(ElementBeanInfoImpl.java:82) [junit] Test com.surgex.addresslookup.service.AddressLookupServiceIntegrationTest FAILED On 1 Feb 2008, at 11:25, Frederic Soulier wrote: Hi Dan A bit more info that can help. I'm using Spring 2.5.1 and Aegis Data binding. CXF is on both side of the wire. The Spring config I use to set up the client side is as follows: ?xml version=1.0 encoding=UTF-8? beans xmlns=http://www.springframework.org/schema/beans; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:jaxws=http://cxf.apache.org/jaxws; xsi:schemaLocation=http://www.springframework.org/schema/beans http://www.springframework.org/schema/ beans/spring-beans-2.0.xsd http://cxf.apache.org/jaxws http://cxf.apache.org/schema/jaxws.xsd; bean id=soapProxy class=com.surgex.addresslookup.service.IAddressLookupService factory-bean=clientFactory factory-method=create/ bean id=clientFactory
org.apache.cxf.binding.soap.SoapFault: http://schemas.xmlsoap.org/wsdl/, the namespace on the definitions element, is not a valid SOAP version.
Hello everyone,'m using cxf 2.0.4-incubator (is this the latest one?) I expose a java class as a web-service, doing something like: wsServerFactoryBean = new ServerFactoryBean(); wsServerFactoryBean.setAddress(address); wsServerFactoryBean.setServiceClass(serviceClass); wsServerFactoryBean.setServiceBean(delegate.getFcInterface(itfName)); wsServerFactoryBean.create(); So, if I look at the appropriate URL, I can infact see the generated WSDL: ?xml version=1.0 encoding=utf-8?wsdl:definitions xmlns:ns1= http://schemas.xmlsoap.org/soap/http; xmlns:soap= http://schemas.xmlsoap.org/wsdl/soap/; xmlns:tns= http://bf.fractal.objectweb.org/; xmlns:wsdl= http://schemas.xmlsoap.org/wsdl/; xmlns:xsd= http://www.w3.org/2001/XMLSchema; name=ComplexService targetNamespace= http://bf.fractal.objectweb.org/; wsdl:types xs:schema xmlns=http://bf.fractal.objectweb.org/; xmlns:xs= http://www.w3.org/2001/XMLSchema; attributeFormDefault=unqualified elementFormDefault=unqualified targetNamespace= http://bf.fractal.objectweb.org/; xs:complexType name=product xs:sequence xs:element name=id type=xs:int/ xs:element minOccurs=0 name=name type=xs:string/ /xs:sequence /xs:complexType xs:element name=print type=print/ xs:complexType name=print xs:sequence/ /xs:complexType xs:element name=printResponse type=printResponse/ xs:complexType name=printResponse xs:sequence/ /xs:complexType xs:element name=getProduct type=getProduct/ xs:complexType name=getProduct xs:sequence/ /xs:complexType xs:element name=getProductResponse type=getProductResponse/ xs:complexType name=getProductResponse xs:sequence xs:element minOccurs=0 name=return type=product/ /xs:sequence /xs:complexType xs:element name=printAndAnswer type=printAndAnswer/ xs:complexType name=printAndAnswer xs:sequence/ /xs:complexType xs:element name=printAndAnswerResponse type=printAndAnswerResponse/ xs:complexType name=printAndAnswerResponse xs:sequence xs:element minOccurs=0 name=return type=xs:string/ /xs:sequence /xs:complexType /xs:schema /wsdl:types wsdl:message name=printAndAnswer wsdl:part element=tns:printAndAnswer name=parameters /wsdl:part /wsdl:message wsdl:message name=getProductResponse wsdl:part element=tns:getProductResponse name=parameters /wsdl:part /wsdl:message wsdl:message name=printAndAnswerResponse wsdl:part element=tns:printAndAnswerResponse name=parameters /wsdl:part /wsdl:message wsdl:message name=getProduct wsdl:part element=tns:getProduct name=parameters /wsdl:part /wsdl:message wsdl:message name=printResponse wsdl:part element=tns:printResponse name=parameters /wsdl:part /wsdl:message wsdl:message name=print wsdl:part element=tns:print name=parameters /wsdl:part /wsdl:message wsdl:portType name=ComplexServicePortType wsdl:operation name=print wsdl:input message=tns:print name=print /wsdl:input wsdl:output message=tns:printResponse name=printResponse /wsdl:output /wsdl:operation wsdl:operation name=getProduct wsdl:input message=tns:getProduct name=getProduct /wsdl:input wsdl:output message=tns:getProductResponse name=getProductResponse /wsdl:output /wsdl:operation wsdl:operation name=printAndAnswer wsdl:input message=tns:printAndAnswer name=printAndAnswer /wsdl:input wsdl:output message=tns:printAndAnswerResponse name=printAndAnswerResponse /wsdl:output /wsdl:operation /wsdl:portType wsdl:binding name=ComplexServiceSoapBinding type=tns:ComplexServicePortType soap:binding style=document transport= http://schemas.xmlsoap.org/soap/http/ wsdl:operation name=print soap:operation soapAction= style=document/ wsdl:input name=print soap:body use=literal/ /wsdl:input wsdl:output name=printResponse soap:body use=literal/ /wsdl:output /wsdl:operation wsdl:operation name=getProduct soap:operation soapAction= style=document/ wsdl:input name=getProduct soap:body use=literal/ /wsdl:input wsdl:output name=getProductResponse soap:body use=literal/ /wsdl:output /wsdl:operation wsdl:operation name=printAndAnswer soap:operation soapAction= style=document/ wsdl:input name=printAndAnswer soap:body use=literal/ /wsdl:input wsdl:output name=printAndAnswerResponse soap:body use=literal/ /wsdl:output /wsdl:operation /wsdl:binding wsdl:service name=ComplexService wsdl:port binding=tns:ComplexServiceSoapBinding name=ComplexServicePort soap:address location=http://localhost:8080/ComplexService?wsdl/ /wsdl:port /wsdl:service /wsdl:definitions On the client-side, i create the client: dcf =
Re: org.apache.cxf.binding.soap.SoapFault: http://schemas.xmlsoap.org/wsdl/, the namespace on the definitions element, is not a valid SOAP version.
So far, this jira issue: https://issues.apache.org/jira/browse/CXF-1117 is the only one that might be somehow related with my problem..but still i've no idea on how to solve this issue. On Feb 1, 2008 4:30 PM, Valerio Schiavoni [EMAIL PROTECTED] wrote: Hello everyone,'m using cxf 2.0.4-incubator (is this the latest one?) I expose a java class as a web-service, doing something like: wsServerFactoryBean = new ServerFactoryBean(); wsServerFactoryBean.setAddress(address); wsServerFactoryBean.setServiceClass(serviceClass); wsServerFactoryBean.setServiceBean(delegate.getFcInterface(itfName)); wsServerFactoryBean.create(); So, if I look at the appropriate URL, I can infact see the generated WSDL: ?xml version=1.0 encoding=utf-8?wsdl:definitions xmlns:ns1= http://schemas.xmlsoap.org/soap/http; xmlns:soap= http://schemas.xmlsoap.org/wsdl/soap/; xmlns:tns= http://bf.fractal.objectweb.org/; xmlns:wsdl= http://schemas.xmlsoap.org/wsdl/; xmlns:xsd= http://www.w3.org/2001/XMLSchema; name=ComplexService targetNamespace= http://bf.fractal.objectweb.org/; wsdl:types xs:schema xmlns=http://bf.fractal.objectweb.org/; xmlns:xs= http://www.w3.org/2001/XMLSchema; attributeFormDefault=unqualified elementFormDefault=unqualified targetNamespace= http://bf.fractal.objectweb.org/; xs:complexType name=product xs:sequence xs:element name=id type=xs:int/ xs:element minOccurs=0 name=name type=xs:string/ /xs:sequence /xs:complexType xs:element name=print type=print/ xs:complexType name=print xs:sequence/ /xs:complexType xs:element name=printResponse type=printResponse/ xs:complexType name=printResponse xs:sequence/ /xs:complexType xs:element name=getProduct type=getProduct/ xs:complexType name=getProduct xs:sequence/ /xs:complexType xs:element name=getProductResponse type=getProductResponse/ xs:complexType name=getProductResponse xs:sequence xs:element minOccurs=0 name=return type=product/ /xs:sequence /xs:complexType xs:element name=printAndAnswer type=printAndAnswer/ xs:complexType name=printAndAnswer xs:sequence/ /xs:complexType xs:element name=printAndAnswerResponse type=printAndAnswerResponse/ xs:complexType name=printAndAnswerResponse xs:sequence xs:element minOccurs=0 name=return type=xs:string/ /xs:sequence /xs:complexType /xs:schema /wsdl:types wsdl:message name=printAndAnswer wsdl:part element=tns:printAndAnswer name=parameters /wsdl:part /wsdl:message wsdl:message name=getProductResponse wsdl:part element=tns:getProductResponse name=parameters /wsdl:part /wsdl:message wsdl:message name=printAndAnswerResponse wsdl:part element=tns:printAndAnswerResponse name=parameters /wsdl:part /wsdl:message wsdl:message name=getProduct wsdl:part element=tns:getProduct name=parameters /wsdl:part /wsdl:message wsdl:message name=printResponse wsdl:part element=tns:printResponse name=parameters /wsdl:part /wsdl:message wsdl:message name=print wsdl:part element=tns:print name=parameters /wsdl:part /wsdl:message wsdl:portType name=ComplexServicePortType wsdl:operation name=print wsdl:input message=tns:print name=print /wsdl:input wsdl:output message=tns:printResponse name=printResponse /wsdl:output /wsdl:operation wsdl:operation name=getProduct wsdl:input message=tns:getProduct name=getProduct /wsdl:input wsdl:output message=tns:getProductResponse name=getProductResponse /wsdl:output /wsdl:operation wsdl:operation name=printAndAnswer wsdl:input message=tns:printAndAnswer name=printAndAnswer /wsdl:input wsdl:output message=tns:printAndAnswerResponse name=printAndAnswerResponse /wsdl:output /wsdl:operation /wsdl:portType wsdl:binding name=ComplexServiceSoapBinding type=tns:ComplexServicePortType soap:binding style=document transport= http://schemas.xmlsoap.org/soap/http/ wsdl:operation name=print soap:operation soapAction= style=document/ wsdl:input name=print soap:body use=literal/ /wsdl:input wsdl:output name=printResponse soap:body use=literal/ /wsdl:output /wsdl:operation wsdl:operation name=getProduct soap:operation soapAction= style=document/ wsdl:input name=getProduct soap:body use=literal/ /wsdl:input wsdl:output name=getProductResponse soap:body use=literal/ /wsdl:output /wsdl:operation wsdl:operation name=printAndAnswer soap:operation soapAction= style=document/ wsdl:input name=printAndAnswer soap:body use=literal/ /wsdl:input wsdl:output name=printAndAnswerResponse
Re: Leaving CXF for Glasshfish Metro
Being a selfish soul, I'd like to see a Dynamic Client example. I saw one on this forum and sort of used that code to create my own but it throws an exception creating an instance of DynamicClientFactory as in, DynamicClientFactory dcf = DynamicClientFactory.newInstance(); The exception provides zero info and there's nothing in the log (on Tomcat 6) By the way I'm trying to invoke a service that I wrote in my XFire days. Using Dynamic Client in XFire it works fine. Any help greatly appreciated. Oh, I'm also trying to build with Maven as i did when using XFire, but I cannot get it to work even when pointing to the CXF artifacts. dkulp wrote: OK. Let's flip this around a bit... Describe the type of example that would (or would have) helped you do what you wanted to do. We can work to get one in place. CXF has a bunch of samples already that cover a large variety of different configuations and samples. Knowing where they are deficient can help us get them improved. Dan On Thursday 31 January 2008, Phil Gibbs wrote: Well, I have to agree. The docs seem to be the last thing that a developer thinks about - because it's so obvious right? CXF, like a lot of software, badly needs some end to end examples at the very least. Currently, it's very lacking, as was XFire! Mayank Thakore-2 wrote: well, i have spent a lot of time getting cxf to work. but migrating from xfire, our code reduced from about 1200 lines to 200 lines. and i find cxf to be very extensible but it's not just coincidence that someone was talking about a book on cxf just today... Regards Mayank On Jan 23, 2008 8:36 PM, jonathan doklovic [EMAIL PROTECTED] wrote: The point being that since this is a users list (not a dev list) I thought I'd share my user experience in hopes that it could help the future of the project. If all anyone hears about a project is how great it is and never hears why people choose not to use it, then it never progresses. I was never able to get CXF working properly simply because of the lack of simple docs and end-to-end examples. Maybe it's just that I don't get it or something, but I feel there are probably a lot of me's out there that struggle with getting things up and running. - Jonathan On Wed, 2008-01-23 at 14:47 +, Sergey Beryozkin wrote: After spending about 2 weeks trying to get a very simple service to return JSON in CXF, I found the Glassfish Metro project and it's jaxws-json plugin. What's the point of this post ? Say to the world that you're not happpy with CXF ? Or tell everyone that you could've commited a patch after spending 2 days on it but just didn't get enough time :-) ? Cheers, Sergey - Original Message - From: jonathan doklovic [EMAIL PROTECTED] To: cxfuser cxf-user@incubator.apache.org Sent: Wednesday, January 23, 2008 2:37 PM Subject: Leaving CXF for Glasshfish Metro Hi, After spending about 2 weeks trying to get a very simple service to return JSON in CXF, I found the Glassfish Metro project and it's jaxws-json plugin. I gave it a shot and after 2 hours had my service up and running. Not only that, but the plugin generates pretty api docs at the endpoint for me as well as generates a javascript client on the fly. It was just too easy to make me stick with CXF. I think CXF is probably a good framework, but the docs and examples are in pieces and without real life end-to-end tutorials, it's really hard to get things working. - Jonathan IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog -- View this message in context: http://www.nabble.com/Leaving-CXF-for-Glasshfish-Metro-tp15043303p15231888.html Sent from the cxf-user mailing list archive at Nabble.com.
CXF deploying in Tomcat checkPermission issue
Hi,
Having this issue while deploying CXF in Tomcat which has
SecurityManager enabled and can't turn off.
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'helloWorld': Invocation of init method failed; nested
exception is java.security.AccessControlException: access denied
(javax.xml.ws.WebServicePermission publishEndpoint) Caused by:
java.security.AccessControlException: access denied
(javax.xml.ws.WebServicePermission publishEndpoint)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.
java:264)
at
java.security.AccessController.checkPermission(AccessController.java:427
)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at
org.apache.cxf.jaxws.EndpointImpl.checkPublishPermission(EndpointImpl.ja
va:349)
The EndpointImpl.checkPublishPermission :
protected void checkPublishPermission() {
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
sm.checkPermission(PUBLISH_PERMISSION);
} else if
(Boolean.getBoolean(CHECK_PUBLISH_ENDPOINT_PERMISSON_PROPERTY)) {
AccessController.checkPermission(PUBLISH_PERMISSION);
Where:
private static final WebServicePermission PUBLISH_PERMISSION =
new WebServicePermission(publishEndpoint);
thanx
-yogen
NOTICE: If received in error, please destroy and notify sender. Sender does not
intend to waive confidentiality or privilege. Use of this email is prohibited
when received in error.
HttpSession and Endpoints
I am using CXFServlet in tomcat, and intend to load balance instances of them with apache mod_jk, and want to use sticky sessions. I figure I have to create a session somewhere, as I do not see a session created (JSESSIONID ?) automatically. For reasons not worth going into, I do not need the session for state, beyond making sure that the sticky-ness works on the load-balancer. I have tried getting the HttpServletRequest in an interceptor (USER_LOGICAL phase) and creating an HttpSession if there is none, and it seems to work. The problem is that I have a few soap endpoints at different URLs, and the session seems to be created for each endpoint, so calls to Service /Foo gets on session and /Bar another. This causes my sticky session load balancer to send /Foo to one of the load balanced CXFServlet and /Bar to another . Is there some way to create the Session so that it is valid for all the service endpoints? Is setting the Session in an interceptor a bad idea?
Re: CXF deploying in Tomcat checkPermission issue
Unfortunately, this is completely required per the jaxws spec. We HAVE
to call the check permissions on the SecurityManager when an
Endpoint.publish(..) call is made.
You really have two options:
1) Configure the SecurityManager to allow the PUBLISH_PERMISSION check to
succeed. I think tomcat has some configs to allow you to keep the SM
in place, but configured to allow publish.
2) Switch from using jaxws:endpoint to jaxws:server in your spring config
file. jaxws:server doesn't use the JAXWS Endpoint apis (It create the
CXF internal representation that the JAXWS Endpoing thing more or less
wrappers) so it may not be affected by that check.
Dan
On Friday 01 February 2008, Yadav, Yogendra (IT) wrote:
Hi,
Having this issue while deploying CXF in Tomcat which has
SecurityManager enabled and can't turn off.
org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'helloWorld': Invocation of init method
failed; nested exception is java.security.AccessControlException:
access denied (javax.xml.ws.WebServicePermission publishEndpoint)
Caused by: java.security.AccessControlException: access denied
(javax.xml.ws.WebServicePermission publishEndpoint)
at
java.security.AccessControlContext.checkPermission(AccessControlContex
t. java:264)
at
java.security.AccessController.checkPermission(AccessController.java:4
27 )
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at
org.apache.cxf.jaxws.EndpointImpl.checkPublishPermission(EndpointImpl.
ja va:349)
The EndpointImpl.checkPublishPermission :
protected void checkPublishPermission() {
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
sm.checkPermission(PUBLISH_PERMISSION);
} else if
(Boolean.getBoolean(CHECK_PUBLISH_ENDPOINT_PERMISSON_PROPERTY)) {
AccessController.checkPermission(PUBLISH_PERMISSION);
Where:
private static final WebServicePermission PUBLISH_PERMISSION =
new WebServicePermission(publishEndpoint);
thanx
-yogen
NOTICE: If received in error, please destroy and notify sender. Sender
does not intend to waive confidentiality or privilege. Use of this
email is prohibited when received in error.
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
Re: HttpSession and Endpoints
On Friday 01 February 2008, Chris Campbell wrote: I am using CXFServlet in tomcat, and intend to load balance instances of them with apache mod_jk, and want to use sticky sessions. I figure I have to create a session somewhere, as I do not see a session created (JSESSIONID ?) automatically. For reasons not worth going into, I do not need the session for state, beyond making sure that the sticky-ness works on the load-balancer. I have tried getting the HttpServletRequest in an interceptor (USER_LOGICAL phase) and creating an HttpSession if there is none, and it seems to work. The problem is that I have a few soap endpoints at different URLs, and the session seems to be created for each endpoint, so calls to Service /Foo gets on session and /Bar another. This causes my sticky session load balancer to send /Foo to one of the load balanced CXFServlet and /Bar to another . Is there some way to create the Session so that it is valid for all the service endpoints? Is setting the Session in an interceptor a bad idea? That should be completely fine assuming that works with tomcat. This really is a tomcat question which I don't really know much about. I would assume if all the endpoints are on the CXFServlet instance they would have properly shared the session. If they are in separate wars, maybe not. I don't know know enough about the servlet spec to know what the rules are around that. -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: org.apache.cxf.binding.soap.SoapFault: http://schemas.xmlsoap.org/wsdl/, the namespace on the definitions element, is not a valid SOAP version.
What is the address that you are sending into: wsServerFactoryBean.setAddress(address); If you look at the wsdl, I see: soap:address location=http://localhost:8080/ComplexService?wsdl/ which is very bizzarre. It shouldn't have the ?wsdl on it. Can you double check the address to make sure it doesn't have the ?wsdl? Thanks! Dan On Friday 01 February 2008, Valerio Schiavoni wrote: Hello everyone,'m using cxf 2.0.4-incubator (is this the latest one?) I expose a java class as a web-service, doing something like: wsServerFactoryBean = new ServerFactoryBean(); wsServerFactoryBean.setAddress(address); wsServerFactoryBean.setServiceClass(serviceClass); wsServerFactoryBean.setServiceBean(delegate.getFcInterface(itfName)); wsServerFactoryBean.create(); So, if I look at the appropriate URL, I can infact see the generated WSDL: ?xml version=1.0 encoding=utf-8?wsdl:definitions xmlns:ns1= http://schemas.xmlsoap.org/soap/http; xmlns:soap= http://schemas.xmlsoap.org/wsdl/soap/; xmlns:tns= http://bf.fractal.objectweb.org/; xmlns:wsdl= http://schemas.xmlsoap.org/wsdl/; xmlns:xsd= http://www.w3.org/2001/XMLSchema; name=ComplexService targetNamespace= http://bf.fractal.objectweb.org/; wsdl:types xs:schema xmlns=http://bf.fractal.objectweb.org/; xmlns:xs= http://www.w3.org/2001/XMLSchema; attributeFormDefault=unqualified elementFormDefault=unqualified targetNamespace= http://bf.fractal.objectweb.org/; xs:complexType name=product xs:sequence xs:element name=id type=xs:int/ xs:element minOccurs=0 name=name type=xs:string/ /xs:sequence /xs:complexType xs:element name=print type=print/ xs:complexType name=print xs:sequence/ /xs:complexType xs:element name=printResponse type=printResponse/ xs:complexType name=printResponse xs:sequence/ /xs:complexType xs:element name=getProduct type=getProduct/ xs:complexType name=getProduct xs:sequence/ /xs:complexType xs:element name=getProductResponse type=getProductResponse/ xs:complexType name=getProductResponse xs:sequence xs:element minOccurs=0 name=return type=product/ /xs:sequence /xs:complexType xs:element name=printAndAnswer type=printAndAnswer/ xs:complexType name=printAndAnswer xs:sequence/ /xs:complexType xs:element name=printAndAnswerResponse type=printAndAnswerResponse/ xs:complexType name=printAndAnswerResponse xs:sequence xs:element minOccurs=0 name=return type=xs:string/ /xs:sequence /xs:complexType /xs:schema /wsdl:types wsdl:message name=printAndAnswer wsdl:part element=tns:printAndAnswer name=parameters /wsdl:part /wsdl:message wsdl:message name=getProductResponse wsdl:part element=tns:getProductResponse name=parameters /wsdl:part /wsdl:message wsdl:message name=printAndAnswerResponse wsdl:part element=tns:printAndAnswerResponse name=parameters /wsdl:part /wsdl:message wsdl:message name=getProduct wsdl:part element=tns:getProduct name=parameters /wsdl:part /wsdl:message wsdl:message name=printResponse wsdl:part element=tns:printResponse name=parameters /wsdl:part /wsdl:message wsdl:message name=print wsdl:part element=tns:print name=parameters /wsdl:part /wsdl:message wsdl:portType name=ComplexServicePortType wsdl:operation name=print wsdl:input message=tns:print name=print /wsdl:input wsdl:output message=tns:printResponse name=printResponse /wsdl:output /wsdl:operation wsdl:operation name=getProduct wsdl:input message=tns:getProduct name=getProduct /wsdl:input wsdl:output message=tns:getProductResponse name=getProductResponse /wsdl:output /wsdl:operation wsdl:operation name=printAndAnswer wsdl:input message=tns:printAndAnswer name=printAndAnswer /wsdl:input wsdl:output message=tns:printAndAnswerResponse name=printAndAnswerResponse /wsdl:output /wsdl:operation /wsdl:portType wsdl:binding name=ComplexServiceSoapBinding type=tns:ComplexServicePortType soap:binding style=document transport= http://schemas.xmlsoap.org/soap/http/ wsdl:operation name=print soap:operation soapAction= style=document/ wsdl:input name=print soap:body use=literal/ /wsdl:input wsdl:output name=printResponse soap:body use=literal/ /wsdl:output /wsdl:operation wsdl:operation name=getProduct soap:operation soapAction= style=document/ wsdl:input name=getProduct soap:body use=literal/ /wsdl:input wsdl:output name=getProductResponse soap:body use=literal/ /wsdl:output /wsdl:operation wsdl:operation name=printAndAnswer soap:operation soapAction= style=document/
Re: Different bevaviour in 2.0.4
Well, JAXB doesn't support maps, which I assume is one of the reasons for using Aegis instead of JAXB. :-) Dan On Friday 01 February 2008, Frederic Soulier wrote: Ah maybe that's better info. Going back to the default bindings (commenting out the Aegis stuff) I get: Testcase: test5SoapRemoting (com.surgex.mafaddresslookup.service.AddressLookupServiceIntegrationTe st ): Caused an ERROR [junit] Marshalling Error: java.util.Map is not known to this context [junit] javax.xml.ws.soap.SOAPFaultException: Marshalling Error: java.util.Map is not known to this context [junit] at org.apache.cxf.jaxws.JaxWsClientProxy.invoke (JaxWsClientProxy.java:175) [junit] at $Proxy30.lookupUK(Unknown Source) [junit] at com.surgex.addresslookup.service.AddressLookupServiceIntegrationTest.e xe cuteTests(AddressLookupServiceIntegrationTest.java:216) [junit] at com.surgex.addresslookup.service.AddressLookupServiceIntegrationTest.t es t5SoapRemoting(AddressLookupServiceIntegrationTest.java:158) [junit] at org.springframework.test.ConditionalTestCase.runBare (ConditionalTestCase.java:76) [junit] Caused by: org.apache.cxf.interceptor.Fault: Marshalling Error: java.util.Map is not known to this context [junit] at org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall (JAXBEncoderDecoder.java:207) [junit] at org.apache.cxf.jaxb.io.DataWriterImpl.write (DataWriterImpl.java:63) [junit] at org.apache.cxf.interceptor.AbstractOutDatabindingInterceptor.writePart s( AbstractOutDatabindingInterceptor.java:84) [junit] at org.apache.cxf.interceptor.BareOutInterceptor.handleMessage (BareOutInterceptor.java:68) [junit] at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept (PhaseInterceptorChain.java:208) [junit] at org.apache.cxf.endpoint.ClientImpl.invoke (ClientImpl.java:276) [junit] at org.apache.cxf.endpoint.ClientImpl.invoke (ClientImpl.java:222) [junit] at org.apache.cxf.frontend.ClientProxy.invokeSync (ClientProxy.java:73) [junit] at org.apache.cxf.jaxws.JaxWsClientProxy.invoke (JaxWsClientProxy.java:135) [junit] Caused by: javax.xml.bind.MarshalException [junit] - with linked exception: [junit] [javax.xml.bind.JAXBException: java.util.Map is not known to this context] [junit] at com.sun.xml.bind.v2.runtime.MarshallerImpl.write (MarshallerImpl.java:295) [junit] at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal (MarshallerImpl.java:221) [junit] at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal (AbstractMarshallerImpl.java:70) [junit] at org.apache.cxf.jaxb.JAXBEncoderDecoder.writeObject (JAXBEncoderDecoder.java:360) [junit] at org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall (JAXBEncoderDecoder.java:187) [junit] Caused by: javax.xml.bind.JAXBException: java.util.Map is not known to this context [junit] at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError (XMLSerializer.java:223) [junit] at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError (XMLSerializer.java:238) [junit] at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl $1.serializeBody(ElementBeanInfoImpl.java:85) [junit] at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl $1.serializeBody(ElementBeanInfoImpl.java:127) [junit] at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeBody (ElementBeanInfoImpl.java:244) [junit] at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot (ElementBeanInfoImpl.java:251) [junit] at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot (ElementBeanInfoImpl.java:33) [junit] at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot (XMLSerializer.java:461) [junit] at com.sun.xml.bind.v2.runtime.MarshallerImpl.write (MarshallerImpl.java:292) [junit] Caused by: javax.xml.bind.JAXBException: java.util.Map is not known to this context [junit] at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getBeanInfo (JAXBContextImpl.java:538) [junit] at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl $1.serializeBody(ElementBeanInfoImpl.java:82) [junit] Test com.surgex.addresslookup.service.AddressLookupServiceIntegrationTest FAILED On 1 Feb 2008, at 11:25, Frederic Soulier wrote: Hi Dan A bit more info that can help. I'm using Spring 2.5.1 and Aegis Data binding. CXF is on both side of the wire. The Spring config I use to set up the client side is as follows: ?xml version=1.0 encoding=UTF-8? beans xmlns=http://www.springframework.org/schema/beans; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:jaxws=http://cxf.apache.org/jaxws; xsi:schemaLocation=http://www.springframework.org/schema/beans http://www.springframework.org/schema/ beans/spring-beans-2.0.xsd http://cxf.apache.org/jaxws
Re: Different bevaviour in 2.0.4
In your spring config, can you add: cxf:bus cxf:features cxf:logging/ /cxf:features /cxf:bus You'll probably need to add: http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd to the schemaLocation. This should make it log the incoming/outgoing soap messages to the normal logging place. (default would be to the console).I'd be curious to see the difference between the 2.0.3 and 2.0.4 messages. Dan On Friday 01 February 2008, Frederic Soulier wrote: Hi Dan A bit more info that can help. I'm using Spring 2.5.1 and Aegis Data binding. CXF is on both side of the wire. The Spring config I use to set up the client side is as follows: ?xml version=1.0 encoding=UTF-8? beans xmlns=http://www.springframework.org/schema/beans; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:jaxws=http://cxf.apache.org/jaxws; xsi:schemaLocation=http://www.springframework.org/schema/beans http://www.springframework.org/schema/ beans/spring-beans-2.0.xsd http://cxf.apache.org/jaxws http://cxf.apache.org/schema/jaxws.xsd; bean id=soapProxy class=com.surgex.addresslookup.service.IAddressLookupService factory-bean=clientFactory factory-method=create/ bean id=clientFactory class=org.apache.cxf.jaxws.JaxWsProxyFactoryBean property name=serviceClass value=com.surgex.addresslookup.service.IAddressLookupService/ property name=address value= http://192.168.10.60:9520/ remoting/soap/AddressLookupService/ property name=serviceFactory ref bean=jaxws-and-aegis-service-factory/ /property /bean !-- Aegis is a fast StAX based data-binding that makes developing code first services -- !-- as simply as possible. It is able to handle most classes and create intelligent -- !-- schemas for them. -- !-- http://cwiki.apache.org/CXF20DOC/aegis- databinding.html -- bean id=aegisBean class=org.apache.cxf.aegis.databinding.AegisDatabinding/ bean id='jaxws-and-aegis-service-factory' class=org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean property name=dataBinding ref=aegisBean/ property name=serviceConfigurations list bean class=org.apache.cxf.jaxws.support.JaxWsServiceConfiguration/ bean class=org.apache.cxf.aegis.databinding.AegisServiceConfiguration/ bean class=org.apache.cxf.service.factory.DefaultServiceConfiguration/ /list /property /bean /beans What do you mean by wire trace? Happy to provide more info though if I can get it. Thx. On 1 Feb 2008, at 02:57, Daniel Kulp wrote: Hmm... That's really not good. Is there any chance you can get a wire trace of the test with both 2.0.3 and 2.0.4? Is it CXF on both sides of the wire? There were some updates to the fault handling/mapping to make it honor the elementFormDefault flags of the schemas. Thus, the fault messages don't match the schema, there could be problems. Dan On Thursday 31 January 2008, Frederic Soulier wrote: Hi I've been using 2.0.3 with good success and I decided to upgrade to 2.0.4 this morning. I'm having problem running my tests which are failing now with: Testcase: test5SoapRemoting (com.surgex.addresslookup.service.AddressLookupServiceIntegrationTe st ) : Caused an ERROR [junit] null while invoking public com.surgex.addresslookup.model.UKAddress[] com.surgex.addresslookup.service.impl.AddressLookupServiceImpl.look up U K( com.surgex.commons.remoting.model.Credential,java.lang.String,java. ut i l. Map,boolean) throws com.surgex.commons.remoting.exceptions.RemotingException,com.surgex .c o mm ons.remoting.exceptions.InvalidArgumentException,com.surgex.commons .r e mo ting.exceptions.UnauthorisedAccessException with params [null, null, null, null]. [junit] javax.xml.ws.soap.SOAPFaultException: null while invoking public com.surgex.addresslookup.model.UKAddress[] com.surgex.addresslookup.service.impl.AddressLookupServiceImpl.look up U K( com.surgex.commons.remoting.model.Credential,java.lang.String,java. ut i l. Map,boolean) throws com.surgex.commons.remoting.exceptions.RemotingException,com.surgex .c o mm ons.remoting.exceptions.InvalidArgumentException,com.surgex.commons .r e mo ting.exceptions.UnauthorisedAccessException with params [null, null, null, null]. [junit] at org.apache.cxf.jaxws.JaxWsClientProxy.invoke (JaxWsClientProxy.java:175) [junit] at $Proxy21.lookupUK(Unknown Source) [junit] at com.surgex.addresslookup.service.AddressLookupServiceIntegrationTes t. e xe
Re: How to make java package names the target name spaces ?
I guess I'm confused. The default for both JAXWS and JAXB IS to map the package name into a namespace. Thus, that's exactly what it should be doing. Dan On Thursday 31 January 2008, Chiang Seng Chang wrote: Hi, I am developing using the Java first approach (using jaxb data binding), and the wsdl is auto generated by the cxf servlet at http://localhost/SomeService?wsdl Short of annotating each class with @XmlType(namespace=http://x.y.z;), is there a setting which inform the servlet to use the source java classes' package names as the targetNamespaces when generating the wsdl? Thank you. -c p.s. Using java package names as targetNamespaces seems to be the default behavior when using aegis data binding. p.p.s. I have tried the @XmlSchema in package-info.java approach, but it was not picked-up by the servlet (probably only works using java2wsdl). -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: HttpSession and Endpoints
The problem is that I get a different session for different endpoints, maybe its how I set the client up? I do set the client up in java code rather than with xml config, so maybe I am doing something wrong there. Is it possible that each service interface is getting a different http-conduit? Daniel Kulp wrote: On Friday 01 February 2008, Chris Campbell wrote: I am using CXFServlet in tomcat, and intend to load balance instances of them with apache mod_jk, and want to use sticky sessions. I figure I have to create a session somewhere, as I do not see a session created (JSESSIONID ?) automatically. For reasons not worth going into, I do not need the session for state, beyond making sure that the sticky-ness works on the load-balancer. I have tried getting the HttpServletRequest in an interceptor (USER_LOGICAL phase) and creating an HttpSession if there is none, and it seems to work. The problem is that I have a few soap endpoints at different URLs, and the session seems to be created for each endpoint, so calls to Service /Foo gets on session and /Bar another. This causes my sticky session load balancer to send /Foo to one of the load balanced CXFServlet and /Bar to another . Is there some way to create the Session so that it is valid for all the service endpoints? Is setting the Session in an interceptor a bad idea? That should be completely fine assuming that works with tomcat. This really is a tomcat question which I don't really know much about. I would assume if all the endpoints are on the CXFServlet instance they would have properly shared the session. If they are in separate wars, maybe not. I don't know know enough about the servlet spec to know what the rules are around that.
Re: Leaving CXF for Glasshfish Metro
AFAIK you just have trouble to create the DynamicClientFactory instance, which mainly create the CXF bus instance. I think you can try out to deploy the basic simples into your Tomcat6. May be it will show you the key of the issue. You can download the CXF kit here[1] , and try the $CXF_HOME\samples\wsdl_first [1]http://cwiki.apache.org/CXF/download.html Willem. Phil Gibbs wrote: Being a selfish soul, I'd like to see a Dynamic Client example. I saw one on this forum and sort of used that code to create my own but it throws an exception creating an instance of DynamicClientFactory as in, DynamicClientFactory dcf = DynamicClientFactory.newInstance(); The exception provides zero info and there's nothing in the log (on Tomcat 6) By the way I'm trying to invoke a service that I wrote in my XFire days. Using Dynamic Client in XFire it works fine. Any help greatly appreciated. Oh, I'm also trying to build with Maven as i did when using XFire, but I cannot get it to work even when pointing to the CXF artifacts. dkulp wrote: OK. Let's flip this around a bit... Describe the type of example that would (or would have) helped you do what you wanted to do. We can work to get one in place. CXF has a bunch of samples already that cover a large variety of different configuations and samples. Knowing where they are deficient can help us get them improved. Dan On Thursday 31 January 2008, Phil Gibbs wrote: Well, I have to agree. The docs seem to be the last thing that a developer thinks about - because it's so obvious right? CXF, like a lot of software, badly needs some end to end examples at the very least. Currently, it's very lacking, as was XFire! Mayank Thakore-2 wrote: well, i have spent a lot of time getting cxf to work. but migrating from xfire, our code reduced from about 1200 lines to 200 lines. and i find cxf to be very extensible but it's not just coincidence that someone was talking about a book on cxf just today... Regards Mayank On Jan 23, 2008 8:36 PM, jonathan doklovic [EMAIL PROTECTED] wrote: The point being that since this is a users list (not a dev list) I thought I'd share my user experience in hopes that it could help the future of the project. If all anyone hears about a project is how great it is and never hears why people choose not to use it, then it never progresses. I was never able to get CXF working properly simply because of the lack of simple docs and end-to-end examples. Maybe it's just that I don't get it or something, but I feel there are probably a lot of me's out there that struggle with getting things up and running. - Jonathan On Wed, 2008-01-23 at 14:47 +, Sergey Beryozkin wrote: After spending about 2 weeks trying to get a very simple service to return JSON in CXF, I found the Glassfish Metro project and it's jaxws-json plugin. What's the point of this post ? Say to the world that you're not happpy with CXF ? Or tell everyone that you could've commited a patch after spending 2 days on it but just didn't get enough time :-) ? Cheers, Sergey - Original Message - From: jonathan doklovic [EMAIL PROTECTED] To: cxfuser cxf-user@incubator.apache.org Sent: Wednesday, January 23, 2008 2:37 PM Subject: Leaving CXF for Glasshfish Metro Hi, After spending about 2 weeks trying to get a very simple service to return JSON in CXF, I found the Glassfish Metro project and it's jaxws-json plugin. I gave it a shot and after 2 hours had my service up and running. Not only that, but the plugin generates pretty api docs at the endpoint for me as well as generates a javascript client on the fly. It was just too easy to make me stick with CXF. I think CXF is probably a good framework, but the docs and examples are in pieces and without real life end-to-end tutorials, it's really hard to get things working. - Jonathan IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: HttpSession and Endpoints
Oh. Yea. That would definitely do it. Good catch. Each client proxy holds it's own conduit and thus the cookie for the session is stored there is unique for each proxy. Most likely, you will need to do some cookie management your self. Grab the protocol headers from the response headers and set them in the request headers for all the proxies. You can use the org.apache.cxf.transport.http.Cookie class to help with the parsing/setting. Dan On Friday 01 February 2008, Chris Campbell wrote: The problem is that I get a different session for different endpoints, maybe its how I set the client up? I do set the client up in java code rather than with xml config, so maybe I am doing something wrong there. Is it possible that each service interface is getting a different http-conduit? Daniel Kulp wrote: On Friday 01 February 2008, Chris Campbell wrote: I am using CXFServlet in tomcat, and intend to load balance instances of them with apache mod_jk, and want to use sticky sessions. I figure I have to create a session somewhere, as I do not see a session created (JSESSIONID ?) automatically. For reasons not worth going into, I do not need the session for state, beyond making sure that the sticky-ness works on the load-balancer. I have tried getting the HttpServletRequest in an interceptor (USER_LOGICAL phase) and creating an HttpSession if there is none, and it seems to work. The problem is that I have a few soap endpoints at different URLs, and the session seems to be created for each endpoint, so calls to Service /Foo gets on session and /Bar another. This causes my sticky session load balancer to send /Foo to one of the load balanced CXFServlet and /Bar to another . Is there some way to create the Session so that it is valid for all the service endpoints? Is setting the Session in an interceptor a bad idea? That should be completely fine assuming that works with tomcat. This really is a tomcat question which I don't really know much about. I would assume if all the endpoints are on the CXFServlet instance they would have properly shared the session. If they are in separate wars, maybe not. I don't know know enough about the servlet spec to know what the rules are around that. -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: HttpSession and Endpoints
Yes , CXF do not share the http conduit between the different client proxy. If you want to share the session between the client proxy, I am afraid you need to hack the CXF http conduit code to handle the cookie in you application code. Willem. Chris Campbell wrote: The problem is that I get a different session for different endpoints, maybe its how I set the client up? I do set the client up in java code rather than with xml config, so maybe I am doing something wrong there. Is it possible that each service interface is getting a different http-conduit? Daniel Kulp wrote: On Friday 01 February 2008, Chris Campbell wrote: I am using CXFServlet in tomcat, and intend to load balance instances of them with apache mod_jk, and want to use sticky sessions. I figure I have to create a session somewhere, as I do not see a session created (JSESSIONID ?) automatically. For reasons not worth going into, I do not need the session for state, beyond making sure that the sticky-ness works on the load-balancer. I have tried getting the HttpServletRequest in an interceptor (USER_LOGICAL phase) and creating an HttpSession if there is none, and it seems to work. The problem is that I have a few soap endpoints at different URLs, and the session seems to be created for each endpoint, so calls to Service /Foo gets on session and /Bar another. This causes my sticky session load balancer to send /Foo to one of the load balanced CXFServlet and /Bar to another . Is there some way to create the Session so that it is valid for all the service endpoints? Is setting the Session in an interceptor a bad idea? That should be completely fine assuming that works with tomcat. This really is a tomcat question which I don't really know much about. I would assume if all the endpoints are on the CXFServlet instance they would have properly shared the session. If they are in separate wars, maybe not. I don't know know enough about the servlet spec to know what the rules are around that.
Re: HttpSession and Endpoints
That would have to be on the client side, correct? I think I would need to have a client side inInterceptor to do that. I tend to load the proxies as needed, is there a way to probe the bus to get any other loaded proxies so that a lazily instantiated proxy can get a previously acquired session cookie from another? Maybe the inInterceptor can just stash away the first session cookie acquired, and an outInterceptor can apply it to any request. Any thoughts as to what the best practice would be? I guess a feature request would be to be able to share an http-conduit between proxies. I kind of think of the http-conduit as an http client, is that bad analogy? Thanks for the insight, definitely narrowing in on a solution. Daniel Kulp wrote: Oh. Yea. That would definitely do it. Good catch. Each client proxy holds it's own conduit and thus the cookie for the session is stored there is unique for each proxy. Most likely, you will need to do some cookie management your self. Grab the protocol headers from the response headers and set them in the request headers for all the proxies. You can use the org.apache.cxf.transport.http.Cookie class to help with the parsing/setting. Dan On Friday 01 February 2008, Chris Campbell wrote: The problem is that I get a different session for different endpoints, maybe its how I set the client up? I do set the client up in java code rather than with xml config, so maybe I am doing something wrong there. Is it possible that each service interface is getting a different http-conduit? Daniel Kulp wrote: On Friday 01 February 2008, Chris Campbell wrote: I am using CXFServlet in tomcat, and intend to load balance instances of them with apache mod_jk, and want to use sticky sessions. I figure I have to create a session somewhere, as I do not see a session created (JSESSIONID ?) automatically. For reasons not worth going into, I do not need the session for state, beyond making sure that the sticky-ness works on the load-balancer. I have tried getting the HttpServletRequest in an interceptor (USER_LOGICAL phase) and creating an HttpSession if there is none, and it seems to work. The problem is that I have a few soap endpoints at different URLs, and the session seems to be created for each endpoint, so calls to Service /Foo gets on session and /Bar another. This causes my sticky session load balancer to send /Foo to one of the load balanced CXFServlet and /Bar to another . Is there some way to create the Session so that it is valid for all the service endpoints? Is setting the Session in an interceptor a bad idea? That should be completely fine assuming that works with tomcat. This really is a tomcat question which I don't really know much about. I would assume if all the endpoints are on the CXFServlet instance they would have properly shared the session. If they are in separate wars, maybe not. I don't know know enough about the servlet spec to know what the rules are around that.
Re: Leaving CXF for Glasshfish Metro
I found some great cxf related documentation at this page when checking request context recently: http://open.iona.com/docs/framework/2.0/jaxws/index.html?url=http://open.iona.com/docs/framework/2.0/jaxws/JAXWSContextsService.html this kind of stuff will help! On 2/1/08, Daniel Kulp [EMAIL PROTECTED] wrote: OK. Let's flip this around a bit... Describe the type of example that would (or would have) helped you do what you wanted to do. We can work to get one in place. CXF has a bunch of samples already that cover a large variety of different configuations and samples. Knowing where they are deficient can help us get them improved. Dan On Thursday 31 January 2008, Phil Gibbs wrote: Well, I have to agree. The docs seem to be the last thing that a developer thinks about - because it's so obvious right? CXF, like a lot of software, badly needs some end to end examples at the very least. Currently, it's very lacking, as was XFire! Mayank Thakore-2 wrote: well, i have spent a lot of time getting cxf to work. but migrating from xfire, our code reduced from about 1200 lines to 200 lines. and i find cxf to be very extensible but it's not just coincidence that someone was talking about a book on cxf just today... Regards Mayank On Jan 23, 2008 8:36 PM, jonathan doklovic [EMAIL PROTECTED] wrote: The point being that since this is a users list (not a dev list) I thought I'd share my user experience in hopes that it could help the future of the project. If all anyone hears about a project is how great it is and never hears why people choose not to use it, then it never progresses. I was never able to get CXF working properly simply because of the lack of simple docs and end-to-end examples. Maybe it's just that I don't get it or something, but I feel there are probably a lot of me's out there that struggle with getting things up and running. - Jonathan On Wed, 2008-01-23 at 14:47 +, Sergey Beryozkin wrote: After spending about 2 weeks trying to get a very simple service to return JSON in CXF, I found the Glassfish Metro project and it's jaxws-json plugin. What's the point of this post ? Say to the world that you're not happpy with CXF ? Or tell everyone that you could've commited a patch after spending 2 days on it but just didn't get enough time :-) ? Cheers, Sergey - Original Message - From: jonathan doklovic [EMAIL PROTECTED] To: cxfuser cxf-user@incubator.apache.org Sent: Wednesday, January 23, 2008 2:37 PM Subject: Leaving CXF for Glasshfish Metro Hi, After spending about 2 weeks trying to get a very simple service to return JSON in CXF, I found the Glassfish Metro project and it's jaxws-json plugin. I gave it a shot and after 2 hours had my service up and running. Not only that, but the plugin generates pretty api docs at the endpoint for me as well as generates a javascript client on the fly. It was just too easy to make me stick with CXF. I think CXF is probably a good framework, but the docs and examples are in pieces and without real life end-to-end tutorials, it's really hard to get things working. - Jonathan IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
