Restful Declarative security?
Hi all, Just a general question - I'm using the JAX-RS implementation in CXF 2.1 for writing services and I have a requirement to secure certain aspects of the service. For example - I want everyone to be able to read a user but only certain people to update to a user. In a Restful these two calls would both be passed to the same url (update a POST, read a GET) Almost all security solutions I know simply protect URL's and can't protect a url for POST's but not for GET's. Has anyone else come across this problem? Any solutions/ workarounds? Obviously I could protect the calls programmatically but this seems a step backwards. Thanks, Barry
cxf 2.0.4, spring 2.5, hibernate 3.2.5.ga and lazy loading
Hello all, I'm trying to learn how I can use cxf the best. To do that, I have created a simple webservice that looks up a user by username and password. Bound to this user are a couple of domains that this user is allowed to log in for. These domains are being lazy loaded by hibernate. When the service is run I get an exception that hibernate is not bound to the session. I've tried a number of ways to add transactions to the configuration, but I could not get it to work. Has anyone an example for me how I should put everything together? Thx in advance. -- View this message in context: http://www.nabble.com/cxf-2.0.4%2C-spring-2.5%2C-hibernate-3.2.5.ga-and-lazy-loading-tp15560510p15560510.html Sent from the cxf-user mailing list archive at Nabble.com.
RE: Restful Declarative security?
Hi Barry, I have recently noticed that it would be a nice extension to ACEGI to support REST in this fashion. I personally think that URL pattern-based RBAC ACL would work really nicely with ACEGI and REST. ACEGI doesn't provide the ability to specify ACL based on the type of HTTP operation involved. This means that ACEGI doesn't naturally support REST out of the box, if you care about modification versus view semantics (which you do). The syntax ACEGI uses to specify the RBAC ACL patterns would need to be overhauled a bit to support this in an ergonomic fashion. It seems like this would be a very nice and very reusable little project though :-) Cheers, Donal -Original Message- From: Barry Fitzgerald [mailto:[EMAIL PROTECTED] Sent: 19 February 2008 10:24 To: cxf-user@incubator.apache.org Subject: Restful Declarative security? Hi all, Just a general question - I'm using the JAX-RS implementation in CXF 2.1 for writing services and I have a requirement to secure certain aspects of the service. For example - I want everyone to be able to read a user but only certain people to update to a user. In a Restful these two calls would both be passed to the same url (update a POST, read a GET) Almost all security solutions I know simply protect URL's and can't protect a url for POST's but not for GET's. Has anyone else come across this problem? Any solutions/ workarounds? Obviously I could protect the calls programmatically but this seems a step backwards. Thanks, Barry IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Creating a REST service from a schema
Hi, I'm interested in using the jax-rs support in CXF. From the examples I've seen it appears that I'm required to take that Java first approach and let JAXB take care of the Java to XML mapping. Is this correct? I prefer the XML first approach and would like to build a RESTful service which either can use my already generated XMLBeans classes (prefered option) or generate JAXB java binding classes from my schema. Is this possible? The important things here for me are to have the schema dictate what the XML looks like and to have it as a REST service. If its not possible using JAX-RS, does CXF have an alternative method to achieve the desired results? Thanks, Brad.
RE: Restful Declarative security?
Hi again Barry, While I haven't tried this myself yet I imagine that an alternate feasible approach would be to use the ACEGI AOP support for annotations to allow you to associate roles with the JAX-RS implementation classes. ACEGI can be used to do a certain level of Authentication and authorization at the Servlet Filter level, limited to specifying Roles for a given RESt resource as mentioned in my post below. However ACEGI can also can be used to provide authorization level support for implementation code via its use of AOP and annotations (see the ACEGI docs for the Aspect-J and AOP-Alliance AOP implementations). This approach would possibly allow you to achieve what you want without needing to extend ACEGI. Maybe have a look at: http://www.acegisecurity.org/ Personally I'm not a huge fan of deployment specific annotations being embedded directly in code though, I would prefer the approach mentioned in my first mail. Security Roles are usually deployment specific data and supplying the actual values via annotations has operational consequences in terms of deployment, administration, and ease of modification. Obviously whether something is appropriate depends on many factors, and it might be okay for you. Cheers, Donal -Original Message- From: Arundel, Donal [mailto:[EMAIL PROTECTED] Sent: 19 February 2008 12:50 To: cxf-user@incubator.apache.org Subject: RE: Restful Declarative security? Hi Barry, I have recently noticed that it would be a nice extension to ACEGI to support REST in this fashion. I personally think that URL pattern-based RBAC ACL would work really nicely with ACEGI and REST. ACEGI doesn't provide the ability to specify ACL based on the type of HTTP operation involved. This means that ACEGI doesn't naturally support REST out of the box, if you care about modification versus view semantics (which you do). The syntax ACEGI uses to specify the RBAC ACL patterns would need to be overhauled a bit to support this in an ergonomic fashion. It seems like this would be a very nice and very reusable little project though :-) Cheers, Donal -Original Message- From: Barry Fitzgerald [mailto:[EMAIL PROTECTED] Sent: 19 February 2008 10:24 To: cxf-user@incubator.apache.org Subject: Restful Declarative security? Hi all, Just a general question - I'm using the JAX-RS implementation in CXF 2.1 for writing services and I have a requirement to secure certain aspects of the service. For example - I want everyone to be able to read a user but only certain people to update to a user. In a Restful these two calls would both be passed to the same url (update a POST, read a GET) Almost all security solutions I know simply protect URL's and can't protect a url for POST's but not for GET's. Has anyone else come across this problem? Any solutions/ workarounds? Obviously I could protect the calls programmatically but this seems a step backwards. Thanks, Barry IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
RE: pb adding Username/Password WS-Security to 'java_first_spring_support' sample
Hi Dominique, no error is being thrown because the UsernameTokenProcessor in WSS4J delegates password validation to the Callback Class for the case of plain-text passwords. Please see the javadoc for org.apache.ws.security.processor.UsernameTokenProcessor#handleUsernameTo ken at: http://ws.apache.org/wss4j/apidocs/index.html Colm. -Original Message- From: Dominique De Vito [mailto:[EMAIL PROTECTED] Sent: 19 February 2008 17:24 To: cxf-user@incubator.apache.org Subject: pb adding Username/Password WS-Security to 'java_first_spring_support' sample Hi, I have just tried to adapt the 'java_first_spring_support' sample to add Username/Password WS-Security. So, I have added to client-beans.xml the following lines : property name=outInterceptors list bean class=org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor/ bean class=org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor ... /list /property The sent XML payload looks like correct according to logged traces. On the server-side, I have my endpoint with security interceptors : jaxws:inInterceptors bean class=org.apache.cxf.interceptor.LoggingInInterceptor/ bean class=org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor constructor-arg map entry key=action value=UsernameToken/ entry key=passwordType value=PasswordText/ entry key=passwordCallbackClass value=demo.spring.servlet.PasswordCallbackClass/ /map /constructor-arg /bean bean class=org.apache.cxf.binding.soap.saaj.SAAJInInterceptor/ /jaxws:inInterceptors And the PasswordCallbackClass is really called according to the traces. My test is the following : on the client-side, I send a wrong password, then, I expect the server-side endpoint not to send me the regular Hello Joe, but some fault. But... the server-side endpoint just returns Hello Joe, acting just like no password authentification was done. Is anyone able to give me some hint to make this example work ? Thanks. Regards, Dominique PS : AFAIK the samples repository into the distrib does not include any example of Username/Password sample. Adding such security samples would be a plus. IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Creating a REST service from a schema
Hi Brad I prefer the XML first approach and would like to build a RESTful service which either can use my already generated XMLBeans classes (prefered option) or generate JAXB java binding classes from my schema. No problems for a JAXB option, it should work just fine. CXF JAXBElementProvider checks if @XMLRootAnnotation is present. Fox XMLBeans, a simple custom provider would need to be added. Perhaps we should have it supported by default. Barry has added a system test showing how to write a JSON BadgerFish JAX-RS Provider (I was actually very surprised to find out BadgerFish is a real thing which lives in the Jettison project) Cheers, Sergey Hi, I'm interested in using the jax-rs support in CXF. From the examples I've seen it appears that I'm required to take that Java first approach and let JAXB take care of the Java to XML mapping. Is this correct? I prefer the XML first approach and would like to build a RESTful service which either can use my already generated XMLBeans classes (prefered option) or generate JAXB java binding classes from my schema. Is this possible? The important things here for me are to have the schema dictate what the XML looks like and to have it as a REST service. If its not possible using JAX-RS, does CXF have an alternative method to achieve the desired results? Thanks, Brad. IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Servlet.service() for servlet CXFServlet exception
Hi thanks again for your insights on the matter. I wish I could be more helpful than just advising you to debug it all yourslef :-) Have a look in the cxf systests module, you'll find jax-rs system tests there. Did you try to run your application in a standalone Tomcat ? Cheers, Sergey - Original Message - From: rm-ramos [EMAIL PROTECTED] To: cxf-user@incubator.apache.org Sent: Tuesday, February 19, 2008 4:31 PM Subject: Re: Servlet.service() for servlet CXFServlet exception Hi Sergey, and thanks again for your insights on the matter. The fact is that is I launch my server from a main() method, using a JAXRSServerFactoryBean as described on the cxf's user manual, everything runs smoothly and I have no problem accessing the data from a web browser, for ex. Don't think the problem (back to JBoss) is the content-type either, been doing some experiments with 'Poster' (the firefox extension) and the results haven't been any different. I couldn't find the sample you talked about, BookServerResourceCreatedSpring. Can you please tell me where to find it? Thanks again, Rui Ramos Hi It seems to be a lower-level CXF issue, ChainInitiationObserver.java:93 shows this code in my snapshot : exchange.put(Bus.class, bus); which is harmlessPerhaps the fact that a content type is set to null causes the problem. Still it's likely that Endpoint which ChainInitiationObserver deals with has not been set up properly... Is there any chance you can try to run your server using a simple main(), without JBoss involved ? For ex, have a look at BookServerResourceCreatedSpring. It runs a server using a /jaxrs_spring resource folder which has beans.xml, so just update it to refer to your web-app folder and try to get resources from a browser. It will help narrow the problem. Cheers, Sergey -- View this message in context: http://www.nabble.com/JAX-RS-%22No-service-found%22-using-Spring-and-JBoss-tp15461660p15561555.html Sent from the cxf-user mailing list archive at Nabble.com. IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Servlet.service() for servlet CXFServlet exception
Hi Sergey, and thanks again for your insights on the matter. The fact is that is I launch my server from a main() method, using a JAXRSServerFactoryBean as described on the cxf's user manual, everything runs smoothly and I have no problem accessing the data from a web browser, for ex. Don't think the problem (back to JBoss) is the content-type either, been doing some experiments with 'Poster' (the firefox extension) and the results haven't been any different. I couldn't find the sample you talked about, BookServerResourceCreatedSpring. Can you please tell me where to find it? Thanks again, Rui Ramos Hi It seems to be a lower-level CXF issue, ChainInitiationObserver.java:93 shows this code in my snapshot : exchange.put(Bus.class, bus); which is harmlessPerhaps the fact that a content type is set to null causes the problem. Still it's likely that Endpoint which ChainInitiationObserver deals with has not been set up properly... Is there any chance you can try to run your server using a simple main(), without JBoss involved ? For ex, have a look at BookServerResourceCreatedSpring. It runs a server using a /jaxrs_spring resource folder which has beans.xml, so just update it to refer to your web-app folder and try to get resources from a browser. It will help narrow the problem. Cheers, Sergey -- View this message in context: http://www.nabble.com/JAX-RS-%22No-service-found%22-using-Spring-and-JBoss-tp15461660p15561555.html Sent from the cxf-user mailing list archive at Nabble.com.
pb adding Username/Password WS-Security to 'java_first_spring_support' sample
Hi, I have just tried to adapt the 'java_first_spring_support' sample to add Username/Password WS-Security. So, I have added to client-beans.xml the following lines : property name=outInterceptors list bean class=org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor/ bean class=org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor ... /list /property The sent XML payload looks like correct according to logged traces. On the server-side, I have my endpoint with security interceptors : jaxws:inInterceptors bean class=org.apache.cxf.interceptor.LoggingInInterceptor/ bean class=org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor constructor-arg map entry key=action value=UsernameToken/ entry key=passwordType value=PasswordText/ entry key=passwordCallbackClass value=demo.spring.servlet.PasswordCallbackClass/ /map /constructor-arg /bean bean class=org.apache.cxf.binding.soap.saaj.SAAJInInterceptor/ /jaxws:inInterceptors And the PasswordCallbackClass is really called according to the traces. My test is the following : on the client-side, I send a wrong password, then, I expect the server-side endpoint not to send me the regular Hello Joe, but some fault. But... the server-side endpoint just returns Hello Joe, acting just like no password authentification was done. Is anyone able to give me some hint to make this example work ? Thanks. Regards, Dominique PS : AFAIK the samples repository into the distrib does not include any example of Username/Password sample. Adding such security samples would be a plus.
Re: pb adding Username/Password WS-Security to 'java_first_spring_support' sample
Hi Colm,
Thanks for your quick response.
That's really a VERY BIG hint.
Sure, the page http://cwiki.apache.org/CXF20DOC/ws-security.html needs a
refresh because the ServerPasswordCallback class just says:
WSPasswordCallback pc = (WSPasswordCallback) callbacks[0];
if (pc.getId().equals(joe) {
// set the password on the callback. This will be compared to the
// password which was sent from the client.
pc.setPassword(password);
}
in case of Password type : plain text
I am going to edit it tomorrow.
Thanks again.
Regards,
Dominique
O hEigeartaigh, Colm a écrit :
Hi Dominique,
no error is being thrown because the UsernameTokenProcessor in WSS4J
delegates password validation to the Callback Class for the case of
plain-text passwords. Please see the javadoc for
org.apache.ws.security.processor.UsernameTokenProcessor#handleUsernameTo
ken
at:
http://ws.apache.org/wss4j/apidocs/index.html
Colm.
-Original Message-
From: Dominique De Vito [mailto:[EMAIL PROTECTED]
Sent: 19 February 2008 17:24
To: cxf-user@incubator.apache.org
Subject: pb adding Username/Password WS-Security to
'java_first_spring_support' sample
Hi,
I have just tried to adapt the 'java_first_spring_support' sample to add
Username/Password WS-Security.
So, I have added to client-beans.xml the following lines :
property name=outInterceptors
list
bean class=org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor/
bean class=org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor
...
/list
/property
The sent XML payload looks like correct according to logged traces.
On the server-side, I have my endpoint with security interceptors :
jaxws:inInterceptors
bean class=org.apache.cxf.interceptor.LoggingInInterceptor/
bean class=org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor
constructor-arg
map
entry key=action value=UsernameToken/
entry key=passwordType value=PasswordText/
entry key=passwordCallbackClass
value=demo.spring.servlet.PasswordCallbackClass/
/map
/constructor-arg
/bean
bean class=org.apache.cxf.binding.soap.saaj.SAAJInInterceptor/
/jaxws:inInterceptors
And the PasswordCallbackClass is really called according to the traces.
My test is the following : on the client-side, I send a wrong password,
then, I expect the server-side endpoint not to send me the regular
Hello Joe, but some fault.
But... the server-side endpoint just returns Hello Joe, acting just
like no password authentification was done.
Is anyone able to give me some hint to make this example work ?
Thanks.
Regards,
Dominique
PS : AFAIK the samples repository into the distrib does not include
any example of Username/Password sample. Adding such security samples
would be a plus.
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Creating a REST service from a schema
Hi Brad, I've tried this with JAX-B generated java classes and it works fine. Drop me a mail if you want further details on how to configure maven etc. Barry On Feb 19, 2008 4:04 PM, Sergey Beryozkin [EMAIL PROTECTED] wrote: Hi Brad I prefer the XML first approach and would like to build a RESTful service which either can use my already generated XMLBeans classes (prefered option) or generate JAXB java binding classes from my schema. No problems for a JAXB option, it should work just fine. CXF JAXBElementProvider checks if @XMLRootAnnotation is present. Fox XMLBeans, a simple custom provider would need to be added. Perhaps we should have it supported by default. Barry has added a system test showing how to write a JSON BadgerFish JAX-RS Provider (I was actually very surprised to find out BadgerFish is a real thing which lives in the Jettison project) Cheers, Sergey Hi, I'm interested in using the jax-rs support in CXF. From the examples I've seen it appears that I'm required to take that Java first approach and let JAXB take care of the Java to XML mapping. Is this correct? I prefer the XML first approach and would like to build a RESTful service which either can use my already generated XMLBeans classes (prefered option) or generate JAXB java binding classes from my schema. Is this possible? The important things here for me are to have the schema dictate what the XML looks like and to have it as a REST service. If its not possible using JAX-RS, does CXF have an alternative method to achieve the desired results? Thanks, Brad. IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
client SSL question
Below is the working copy for client to connecting to a CXF server.
Because I comment out tlsParams.setKeyManagers and
tlsParams.setTrustManagers,
client receives javax.net.ssl.SSLHandshakeException:
HelloWorld ss = new HelloWorld();
HelloWorldPortType port = ss.getHelloWorldPort();
org.apache.cxf.endpoint.Client c = ClientProxy.getClient(port);
HTTPConduit httpConduit = (HTTPConduit) c.getConduit();
TLSClientParameters tlsParams = new TLSClientParameters();
tlsParams.setSecureSocketProtocol(SSL);
//try {
//tlsParams.setKeyManagers();
//tlsParams.setTrustManagers(xxx);
//} catch (IOException e) {
//e.printStackTrace();
//}
httpConduit.setTlsClientParameters(tlsParams);
Caused by: javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: No trusted certificate found
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:150)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1476)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:174)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:168)
at
com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:847)
at
com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:106)
at
com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:495)
at
com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:433)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:815)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1025)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1038)
at
sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:402)
at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:170)
at
sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:836)
at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:230)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleHeadersTrustCaching(HTTPConduit.java:1766)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.onFirstWrite(HTTPConduit.java:1734)
at
org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:42)
at com.ctc.wstx.io.UTF8Writer.flush(UTF8Writer.java:96)
at com.ctc.wstx.sw.BufferingXmlWriter.flush(BufferingXmlWriter.java:214)
at com.ctc.wstx.sw.BaseStreamWriter.flush(BaseStreamWriter.java:311)
... 100 more
Caused by: sun.security.validator.ValidatorException: No trusted certificate
found
at
sun.security.validator.SimpleValidator.buildTrustedChain(SimpleValidator.java:304)
at
sun.security.validator.SimpleValidator.engineValidate(SimpleValidator.java:107)
at sun.security.validator.Validator.validate(Validator.java:203)
at
com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:172)
at
com.sun.net.ssl.internal.ssl.JsseX509TrustManager.checkServerTrusted(SSLContextImpl.java:320)
at
com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:840)
Now I use the same client to connect to NET server, I got different
exception.
Why it's using java.net.PlainSocketImpl to make the connection?
I don't understand why the same client has different path when connecting to
different severs?
Caused by: com.ctc.wstx.exc.WstxIOException: wjcp7meduat1.medpoint.com
at com.ctc.wstx.sw.BaseStreamWriter.flush(BaseStreamWriter.java:313)
at
org.apache.cxf.interceptor.AbstractOutDatabindingInterceptor.writeParts(AbstractOutDatabindingInterceptor.java:73)
... 8 more
Caused by: java.net.UnknownHostException: wjcp7meduat1.medpoint.com
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177)
at java.net.Socket.connect(Socket.java:507)
at sun.net.NetworkClient.doConnect(NetworkClient.java:152)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:365)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:477)
at sun.net.www.protocol.https.HttpsClient.init(HttpsClient.java:278)
at sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:335)
at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:176)
at
sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:744)
at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:162)
at
Re: client SSL question
The correct one goes to Line 170, the other one goes to Line 162 sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:170) sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:162) -- View this message in context: http://www.nabble.com/client-SSL-question-tp15564062p15568885.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: client code to access java_first_jaxws on tomcat
Here's a WSDL-first example I created:
http://www.jroller.com/gmazza/date/20071019
For just a pure client, of an already existing web service:
http://www.jroller.com/gmazza/date/20070929
HTH,
Glen
Am Dienstag, den 19.02.2008, 16:24 -0800 schrieb Daniel Lipofsky:
I am trying to learn CXF, I have installed the java_first_jaxws
sample on Tomcat 5.5 and can see the wsdl at
http://localhost:8080/helloworld/services/hello_world?wsdl
But what I don't understand is how I can run webservices
against that server. Does anyone have client code that will
allow me to test? I tried modifying Client.java like this:
private static final QName SERVICE_NAME
= new QName(http://server.hw.demo/;, HelloWorld);
private static final QName PORT_NAME
= new QName(http://server.hw.demo/;, HelloWorldPort);
public static void main(String args[]) throws Exception {
Service service = Service.create(SERVICE_NAME);
String endpointAddress =
http://localhost:8080/helloworld/services/hello_world?wsdl;;
service.addPort(PORT_NAME, SOAPBinding.SOAP11HTTP_BINDING,
endpointAddress);
HelloWorld hw = service.getPort(HelloWorld.class);
System.out.println(hw.sayHi(World));
}
but all I got was
org.apache.cxf.binding.soap.SoapFault:
http://schemas.xmlsoap.org/wsdl/;,
the namespace on the definitions element, is not a valid SOAP version.
I tried a bunch of variations too with no success.
How does one make this work? (I'd also appreciate
an example for wsdl_first_soap12 or any of the others)
Thanks,
Dan
client code to access java_first_jaxws on tomcat
I am trying to learn CXF, I have installed the java_first_jaxws
sample on Tomcat 5.5 and can see the wsdl at
http://localhost:8080/helloworld/services/hello_world?wsdl
But what I don't understand is how I can run webservices
against that server. Does anyone have client code that will
allow me to test? I tried modifying Client.java like this:
private static final QName SERVICE_NAME
= new QName(http://server.hw.demo/;, HelloWorld);
private static final QName PORT_NAME
= new QName(http://server.hw.demo/;, HelloWorldPort);
public static void main(String args[]) throws Exception {
Service service = Service.create(SERVICE_NAME);
String endpointAddress =
http://localhost:8080/helloworld/services/hello_world?wsdl;;
service.addPort(PORT_NAME, SOAPBinding.SOAP11HTTP_BINDING,
endpointAddress);
HelloWorld hw = service.getPort(HelloWorld.class);
System.out.println(hw.sayHi(World));
}
but all I got was
org.apache.cxf.binding.soap.SoapFault:
http://schemas.xmlsoap.org/wsdl/;,
the namespace on the definitions element, is not a valid SOAP version.
I tried a bunch of variations too with no success.
How does one make this work? (I'd also appreciate
an example for wsdl_first_soap12 or any of the others)
Thanks,
Dan
Re: client code to access java_first_jaxws on tomcat
Hi Dan,
You set the wrong endpointAddress.
http://localhost:8080/helloworld/services/hello_world?wsdl; is the
service wsdl url.
you need to set the endpointAddress to be
http://localhost:8080/helloworld/services/hello_world;
Willem
Daniel Lipofsky wrote:
I am trying to learn CXF, I have installed the java_first_jaxws
sample on Tomcat 5.5 and can see the wsdl at
http://localhost:8080/helloworld/services/hello_world?wsdl
But what I don't understand is how I can run webservices
against that server. Does anyone have client code that will
allow me to test? I tried modifying Client.java like this:
private static final QName SERVICE_NAME
= new QName(http://server.hw.demo/;, HelloWorld);
private static final QName PORT_NAME
= new QName(http://server.hw.demo/;, HelloWorldPort);
public static void main(String args[]) throws Exception {
Service service = Service.create(SERVICE_NAME);
String endpointAddress =
http://localhost:8080/helloworld/services/hello_world?wsdl;;
service.addPort(PORT_NAME, SOAPBinding.SOAP11HTTP_BINDING,
endpointAddress);
HelloWorld hw = service.getPort(HelloWorld.class);
System.out.println(hw.sayHi(World));
}
but all I got was
org.apache.cxf.binding.soap.SoapFault:
http://schemas.xmlsoap.org/wsdl/;,
the namespace on the definitions element, is not a valid SOAP version.
I tried a bunch of variations too with no success.
How does one make this work? (I'd also appreciate
an example for wsdl_first_soap12 or any of the others)
Thanks,
Dan
QUESTION: where is the class file -- org.apache.cxf.jms_greeter.JMSGreeterPortType -- to be found???
Hi I'm new to CXF and attempting to build the jms-queue example (found in the samples folder with the CXF distribution - in my case this example is located in the folder: C:\apache-cxf-2.0.4-incubator\samples\jms_queue). I cannot successfully build the file demo.jms_greeter.server.GreeterJMSImpl.java. This is because there is an import for class org.apache.cxf.jms_greeter.JMSGreeterPortType which cannot be resolved. QUESTION: where is the class file -- org.apache.cxf.jms_greeter.JMSGreeterPortType -- to be found??? Its not clear whether the examples are outdated or whether there is another explanation. (I cannot locate it in any of the jars in the CXF_HOME lib folder) Being new to the technology, these sorts of issues make it difficult to get up to speed quickly with a tool that I would like to begin using productively. Thanks for any help solving this issue. jw
