Re: cxf-2.0.5 snapshot fails with scope=session
On Friday 28 March 2008, Daniel Kulp wrote: Did you by any chance modify your 2.0.4 lib directory to include the spring aop stuff (and cglib)? If so, you will need to do the same for 2.0.5. If I replace the 2.0.5 spring jars with the everything spring jar and add cglib-nodeps, then your sample works fine with 2.0.5 and 2.0.4. Thus, my gut feeling says your 2.0.4 lib dir has those, but that's not something we included by default. Dan Hi Dan, you are right. As I said I used as a guide http://www.nabble.com/Share-object-in-request-scope-on-ws-server-td14611572.html especially the following quote It turns out that my earlier problems were due to subtle version mismatches among Spring components. What worked for me is to use the latest available version of spring-aop (2.0.8) and match the other components to that version. In addition, cglib 2.1_3 and asm 1.5.3 have to be in the classpath. Sorry for that but I have forgotten it in the midst of numerous trials and errors. So I suppose the trick is spring-aop-2.0.8.jar and the cglib? May I ask what's the reason apache-cxf does not bundle them? .bill
Re: scope=session client side configuraion
On Friday 28 March 2008, Daniel Kulp wrote:
Hmm... not sure what phase you get if you don't specify one. That might
be why it's not working.
I would suggest doing:
public static class MyInterceptor
extends AbstractPhaseInterceptorMessage {
public MyInterceptor() {
super(Phase.SETUP);
}
public void handleMessage(Message message) throws Fault {
logger.info(Hi there);
message.put(Message.MAINTAIN_SESSION, true);
}
}
Hi Dan,
This works beautifully. Thanks a lot. I can now get rid of
the JaxWS requirement client side.
Thanks again.
.bill
RE: Error during build !!
Hi, I am able to solve that problem... It was due to some goof up that I did with the set of WSDL files under testutils. Apologies for bugging the group for such a mistake from my side :( Now that particular testcase execution is thru but now getting another one... Expecting prompt reply on this too ;) .. Thanks ! Regards, Harbhanu PS: Error information for testcase failure... Running org.apache.cxf.tools.wsdlto.jaxws.CodeGenBugTest 2008-03-31 12:34:29.365::INFO: Logging to STDERR via org.mortbay.log.StdErrLog 2008-03-31 12:34:29.427::INFO: jetty-6.1.6 2008-03-31 12:34:29.662::INFO: Started [EMAIL PROTECTED]:8585 Tests run: 49, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 217.141 sec FAILURE! testCatalog2(org.apache.cxf.tools.wsdlto.jaxws.CodeGenBugTest) Time elapsed: 63.046 sec ERROR! org.apache.cxf.tools.common.ToolException: java.net.ConnectException: Connection timed out: connect at org.apache.cxf.tools.validator.internal.WSDL11Validator.getWSDLDoc(WSDL11Val idator.java:80) at org.apache.cxf.tools.validator.internal.WSDL11Validator.isValid(WSDL11Valida tor.java:95) at org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuilder.val idate(JAXWSDefinitionBuilder.jav :198) at org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuilder.val idate(JAXWSDefinitionBuilder.jav :61) at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer. java:128) at org.apache.cxf.tools.wsdlto.jaxws.CodeGenBugTest.testCatalog2(CodeGenBugTest .java:852) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunn er.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner. java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterR unner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java: 75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClass MethodsRunner.java:66) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner .java:35) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner. java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterR unner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62 ) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(Ab stractDirectoryTestSuite.java:13 ) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractD irectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireB ooter.java:290) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818 ) Caused by: java.net.ConnectException: Connection timed out: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.Socket.connect(Socket.java:520) at java.net.Socket.connect(Socket.java:470) at sun.net.NetworkClient.doConnect(NetworkClient.java:157) at sun.net.www.http.HttpClient.openServer(HttpClient.java:388) at sun.net.www.http.HttpClient.openServer(HttpClient.java:523) at sun.net.www.http.HttpClient.init(HttpClient.java:231) at sun.net.www.http.HttpClient.New(HttpClient.java:304) at sun.net.www.http.HttpClient.New(HttpClient.java:321) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnecti on.java:813) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.j ava:765) at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:6 90) at
Unsubscribe
Peter Liljenberg TeliaSonera AB Software Architect, TSS-IT Channel Technologies Cell: +46 (0)703 790 793 e-mail: [EMAIL PROTECTED] - smime.p7s Description: S/MIME cryptographic signature
[no subject]
Hello, I'm working on project with CXF and I try to keep the inheritance between exceptions in my WSDL but it doesn't work. It works well with data objects but when I generate the WSDL of my service with java2wsdl (2.0.4 and 2.0.5) or java2ws (2.1) I lose the inheritance between exceptions. Do you know, please, how to do for keeping inheritance between exceptions? If it's impossible to do it, can I be able to do it in the future CXF version? Thank you in advance, GUEIDAO Eric
Problem with CXF inheritance exception
Hello, I'm working on project with CXF and I try to keep the inheritance between exceptions in my WSDL but it doesn't work. It works well with data objects but when I generate the WSDL of my service with java2wsdl (2.0.4 and 2.0.5) or java2ws (2.1) I lose the inheritance between exceptions. Do you know, please, how to do for keeping inheritance between exceptions? If it's impossible to do it, can I be able to do it in the future CXF version? Thank you in advance, GUEIDAO Eric
Re: [CXF] Deployment errors
dkulp wrote:
On Friday 28 March 2008, Cencio wrote:
2) I can't retrieve the wsdl.. i i look at
http://localhost:8080/ese5/prova?wsdl it respond with
soap:Envelope
soap:Body
soap:Fault
faultcodesoap:Server/faultcode
faultstringNo such operation: a/faultstring
/soap:Fault
/soap:Body
/soap:Envelope
What i miss?
That's bizzare. Are you sure the URL is correct? Is there a stack trace
in the server logs?
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
INFO: Creating Service {http://www.rivenditore.org/Ordine}OrdineService from
WSDL: webapps/ese5/WEB-INF/ordini.wsdl
28-mar-2008 17.06.05 org.apache.cxf.endpoint.ServerImpl initDestination
INFO: Setting the server's publish address to be prova
28-mar-2008 17.06.05 org.apache.cxf.interceptor.AttachmentInInterceptor
handleMessage
INFO: AttachmentInInterceptor skipped in HTTP GET method
28-mar-2008 17.06.05 org.apache.cxf.interceptor.StaxInInterceptor
handleMessage
INFO: StaxInInterceptor skipped.
28-mar-2008 17.06.05
org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor handleMessage
INFO: ReadHeadersInterceptor skipped in HTTP GET method
28-mar-2008 17.06.05 org.apache.cxf.phase.PhaseInterceptorChain doIntercept
INFO: Interceptor has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: No such operation: a
at
org.apache.cxf.interceptor.URIMappingInterceptor.handleMessage(URIMappingInterceptor.java:77)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:208)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:77)
at
org.apache.cxf.transport.servlet.ServletDestination.doMessage(ServletDestination.java:79)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:264)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
at
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:170)
at
org.apache.cxf.transport.servlet.AbstractCXFServlet.doGet(AbstractCXFServlet.java:152)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
at java.lang.Thread.run(Thread.java:595)
This is the stack trace. Yes, the url is correct. Pointing to
http://localhost:8080/ese5/ it gives me the list of exposed Endpoints (only
one for me) and http://localhost:8080/ese5/prova?wsdl gives me the previous
error. Invoking the service's operations (http://localhost:8080/ese5/prova)
works nice..
Thx for your help,
Lorenzo
--
View this message in context:
http://www.nabble.com/-CXF--Deployment-errors-tp16352989p16392858.html
Sent from the cxf-user mailing list archive at Nabble.com.
Rest services with CXF 2.04
Hi, i try to do a Rest service that output XML/json with CXF 2.0.4 and i do it from the sample code 'restful_http_binding' and it works very well. but my need is to do a rest service mapped on a servlet because i don't want to open a new port I try the cxfServlet but as far as I know the Epoint.publish() method does not allow rest services and it is not possible to use JaxWsServerFactoryBean.setBindingId(HttpBindingFactory.HTTP_BINDING_ID); is there a solution with cxf 2.0.4 to do rest service and to mapp it on an existing jetty or tomcat port. Thanks David
Re: Problem with CXF inheritance exception
I believe you'd get the very same result with Metro (try it [1])--CXF is performing according to spec. If you're unhappy with JAX-WS' design on this issue, sending comments to the JSR[2] over the matter would probably be the best solution. Regards, Glen [1] http://www.jroller.com/gmazza/date/20070929 [2] http://jcp.org/en/jsr/detail?id=224 Am Montag, den 31.03.2008, 09:55 +0200 schrieb Eric Gueidao: Hello, I'm working on project with CXF and I try to keep the inheritance between exceptions in my WSDL but it doesn't work. It works well with data objects but when I generate the WSDL of my service with java2wsdl (2.0.4 and 2.0.5) or java2ws (2.1) I lose the inheritance between exceptions. Do you know, please, how to do for keeping inheritance between exceptions? If it's impossible to do it, can I be able to do it in the future CXF version? Thank you in advance, GUEIDAO Eric
Re: cxf-2.0.5 snapshot fails with scope=session
Vassilis Virvilis wrote: So I suppose the trick is spring-aop-2.0.8.jar and the cglib? May I ask what's the reason apache-cxf does not bundle them? Because it doesn't need them. They are needed in your case because of the aop:scoped-proxy/, but nothing in the default configuration of CXF requires them to be there. In my services I use the bundle spring.jar rather than the individual spring-*.jar files, which achieves the same effect. Ian -- Ian Roberts | Department of Computer Science [EMAIL PROTECTED] | University of Sheffield, UK
Re: re[jira] stful uri binding value not set to input parameter bean property
Hi Tam
If it's a blocker for you and you know a java JSON library which handles this
case then there's a fairly easy workaround. One can create a custom
MessageBodyWriter (copy and paste of the existing JSON provider with minor
updates), in your case it can be a CustomJsonWriter, which would delegate to
the library which just works, and then it can be registered with the runtime,
have a look please on how Barry F. did a BadgerFishJSonProvider in system jaxrs
tests...
Cheers, Sergey
Yea, Jettison issue. There was a discussion about this on the jettison
list:
http://archive.jettison.codehaus.org/dev/27326848.1205101828701.JavaMail.haus-jira%40codehaus01.managed.contegix.com
and JIRA:
http://jira.codehaus.org/browse/JETTISON-36
Dan
On Thursday 27 March 2008, Sergey Beryozkin wrote:
Hi Tam
I'm afraid I don't know what the issue is here. Looks like it's either
the problem of missing some JAXB annotation... or more likely the
problem of Jettison...
Does someone know, is it possible to fix this issue at the JAXB level
? Cheers, Sergey
Hi Sergey
I have run into another problem! I am making a GET request to a
service and it is returning me some JSON content. The content I am
getting is: {telephoneNo:{code:161,number:2382907}}
the content I want is:
{telephoneNo:{code:0161,number:2382907}}
I have tried adding an @XmlElement(type = String.class) annotation
to the Field of the Object returned by the service but that makes no
difference. If I add a non numeric char to the code field value
(0161S) the value is returned in quotes, so it looks like it is
determining the value type from the value rather than the Field or
annotation?! Is this a bug or is there something I'm not setting
somewhere?
Cheers, Tam
Sergey Beryozkin wrote:
Hi Tam
Thanks for that, I have now got it up and running. You also have
to add the
@XmlRootElement annotation to the object returned by the service
otherwise
you get a NullPointerException.
The exception is quite poor all-right at the moment. In this case
and exception saying no MessageBodyWriter was found has to be
generated. I actually have a minor patch I did on weekends to
improve on some of the things in this area, including the support
for a standard
WebApplicationException.
Is it possible to specify the @ProduceMime type in the Spring
context
file.
You can do
@GET
@ProduceMime(application/xml, application/json)
and then, depending on the value of the Accept type the approproate
MessageBodyWriter will be selected. You can also debug the formats
like this :
GET /yourResource?_contentType=application/xml
or
GET /yourResource?_contentType=xml
etc, with xml in this case defaulting to application/xml. More
shortcuts like 'xml' can be easily added to a system query handler
dealing with this query...
Cheers, Sergey
Hi Sergey
Thanks for that, I have now got it up and running. You also have
to add the
@XmlRootElement annotation to the object returned by the service
otherwise
you get a NullPointerException.
Is it possible to specify the @ProduceMime type in the Spring
context file.
At the moment if i want a service to return different mime types
it seems like i need multiple implementations of the method with
different annotations.
Cheers, Tam
Sergey Beryozkin wrote:
Hi Tam,
I'm sorry, but I've never got to updating the documentaion but
I've created a JIRA to have the docs updated asap, I'll try to
update them in the next few days...
In meantime have a look please at a basic jaxrs demo, the only
difference
with what the documentation says is that
different annotations are used, for ex @GET instead of
@HttpMethod(Get),
@Path instead of @UriTemplate and @PathParam instead of
@UriParam...
Cheers, Sergey
- Original Message -
From: tam.sayers [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, March 25, 2008 11:05 AM
Subject: Re: re[jira] stful uri binding value not set to input
parameter bean property
Hi Sergey
Thanks for the reply. The version of the jax-rs implementation
in the apache-cxf-2.1-incubator-20080321.032844-42.zip seems to
be different than
the one described in
http://cwiki.apache.org/CXF20DOC/jax-rs-jsr-311.html.
Do you know if there is any documentation anywhere for the newer
version?
Tam
Sergey Beryozkin wrote:
Hi
Please try the same with the current JAX-RS implementation in
CXF. I'm not qute sure why this does not work for the CXF HTTP
binding, but one
thing is that
this binding can be considered depecated...unless someone can
confirm they're going to mantain it...
Cheers, Sergey
I have tried calling the following service using the cxf 2.0.4
and 2.1
code
and when using both the accountNumber is not set to the
GetForAccount bean.
When debugging through the code I can see that
the
Re: Error during build !!
Did you have a full internet connection (no proxy required) while doing the build? There is an issue in the validator tests that requires a host name to be resolved and a connection established. We've fixed that on trunk and I think for 2.0.5, although Benson mentioned the other day that there are still failures if the internet isn't available. Dan On Monday 31 March 2008, harbhanu wrote: Hi, I am able to solve that problem... It was due to some goof up that I did with the set of WSDL files under testutils. Apologies for bugging the group for such a mistake from my side :( Now that particular testcase execution is thru but now getting another one... Expecting prompt reply on this too ;) .. Thanks ! Regards, Harbhanu PS: Error information for testcase failure... Running org.apache.cxf.tools.wsdlto.jaxws.CodeGenBugTest 2008-03-31 12:34:29.365::INFO: Logging to STDERR via org.mortbay.log.StdErrLog 2008-03-31 12:34:29.427::INFO: jetty-6.1.6 2008-03-31 12:34:29.662::INFO: Started [EMAIL PROTECTED]:8585 Tests run: 49, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 217.141 sec FAILURE! testCatalog2(org.apache.cxf.tools.wsdlto.jaxws.CodeGenBugTest) Time elapsed: 63.046 sec ERROR! org.apache.cxf.tools.common.ToolException: java.net.ConnectException: Connection timed out: connect at org.apache.cxf.tools.validator.internal.WSDL11Validator.getWSDLDoc(WSD L11Val idator.java:80) at org.apache.cxf.tools.validator.internal.WSDL11Validator.isValid(WSDL11 Valida tor.java:95) at org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuild er.val idate(JAXWSDefinitionBuilder.jav :198) at org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuild er.val idate(JAXWSDefinitionBuilder.jav :61) at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaCont ainer. java:128) at org.apache.cxf.tools.wsdlto.jaxws.CodeGenBugTest.testCatalog2(CodeGenB ugTest .java:852) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j ava:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess orImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMeth odRunn er.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodR unner. java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAnd AfterR unner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner .java: 75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java: 45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(Tes tClass MethodsRunner.java:66) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethods Runner .java:35) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassR unner. java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAnd AfterR unner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52 ) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.j ava:62 ) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTest Set(Ab stractDirectoryTestSuite.java:13 ) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Abs tractD irectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j ava:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess orImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Sur efireB ooter.java:290) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.ja va:818 ) Caused by: java.net.ConnectException: Connection timed out: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.Socket.connect(Socket.java:520) at java.net.Socket.connect(Socket.java:470) at sun.net.NetworkClient.doConnect(NetworkClient.java:157) at sun.net.www.http.HttpClient.openServer(HttpClient.java:388) at sun.net.www.http.HttpClient.openServer(HttpClient.java:523) at
Re: Problem with CXF inheritance exception
As Glen mentioned, this is completely per spec. You can work around it SLIGHTLY by refactoring your exceptions to store all their data in JAXB specified java beans (grabbed via getFaultInfo()) that implement the same heiarchy. That said, when you run wsdl2java on the wsdl to generate code from it, that heiarchy would not be honored in the exceptions themselves. In anycase, this is all per spec. Dan On Monday 31 March 2008, Eric Gueidao wrote: Hello, I'm working on project with CXF and I try to keep the inheritance between exceptions in my WSDL but it doesn't work. It works well with data objects but when I generate the WSDL of my service with java2wsdl (2.0.4 and 2.0.5) or java2ws (2.1) I lose the inheritance between exceptions. Do you know, please, how to do for keeping inheritance between exceptions? If it's impossible to do it, can I be able to do it in the future CXF version? Thank you in advance, GUEIDAO Eric -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Error during build !!
I *may* have been caught out by the servicemix upgrade. On Mon, Mar 31, 2008 at 9:30 AM, Daniel Kulp [EMAIL PROTECTED] wrote: Did you have a full internet connection (no proxy required) while doing the build? There is an issue in the validator tests that requires a host name to be resolved and a connection established. We've fixed that on trunk and I think for 2.0.5, although Benson mentioned the other day that there are still failures if the internet isn't available. Dan On Monday 31 March 2008, harbhanu wrote: Hi, I am able to solve that problem... It was due to some goof up that I did with the set of WSDL files under testutils. Apologies for bugging the group for such a mistake from my side :( Now that particular testcase execution is thru but now getting another one... Expecting prompt reply on this too ;) .. Thanks ! Regards, Harbhanu PS: Error information for testcase failure... Running org.apache.cxf.tools.wsdlto.jaxws.CodeGenBugTest 2008-03-31 12:34:29.365::INFO: Logging to STDERR via org.mortbay.log.StdErrLog 2008-03-31 12:34:29.427::INFO: jetty-6.1.6 2008-03-31 12:34:29.662::INFO: Started [EMAIL PROTECTED]:8585 Tests run: 49, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 217.141 sec FAILURE! testCatalog2(org.apache.cxf.tools.wsdlto.jaxws.CodeGenBugTest) Time elapsed: 63.046 sec ERROR! org.apache.cxf.tools.common.ToolException: java.net.ConnectException: Connection timed out: connect at org.apache.cxf.tools.validator.internal.WSDL11Validator.getWSDLDoc(WSD L11Val idator.java:80) at org.apache.cxf.tools.validator.internal.WSDL11Validator.isValid(WSDL11 Valida tor.java:95) at org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuild er.val idate(JAXWSDefinitionBuilder.jav :198) at org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuild er.val idate(JAXWSDefinitionBuilder.jav :61) at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaCont ainer. java:128) at org.apache.cxf.tools.wsdlto.jaxws.CodeGenBugTest.testCatalog2(CodeGenB ugTest .java:852) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j ava:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess orImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMeth odRunn er.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodR unner. java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAnd AfterR unner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner .java: 75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java: 45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(Tes tClass MethodsRunner.java:66) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethods Runner .java:35) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassR unner. java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAnd AfterR unner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52 ) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.j ava:62 ) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTest Set(Ab stractDirectoryTestSuite.java:13 ) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Abs tractD irectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j ava:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess orImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Sur efireB ooter.java:290) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.ja va:818 ) Caused by: java.net.ConnectException: Connection timed out: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.Socket.connect(Socket.java:520) at java.net.Socket.connect(Socket.java:470) at
JAX-WS with soap-header and soap-body parameters
hi all, while testing a wsdl-first JAX-WS, classes generated using cxf 2.0.5 snapshot (behaviour was the same with cxf 2.0.2 and 2.0.4) with wsdl2java -all -exsh true, i'm getting following error within the generated sample-server: INFO: Application has thrown exception, unwinding now org.apache.cxf.interceptor.Fault: wrong number of arguments while invoking public java.lang.String net.aaa.Service1SoapImpl.removeAccount(java.lang.String,net.aaa.AuthHeader) with params [ddd]. at org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:109) how to make it work? regards, andré ps: snippets from wsdl: snipp s:element name=AuthHeader type=tns:AuthHeader / s:complexType name=AuthHeader s:sequence s:element minOccurs=0 maxOccurs=1 name=Username type=s:string / s:element minOccurs=0 maxOccurs=1 name=Password type=s:string / /s:sequence s:anyAttribute / /s:complexType s:element name=RemoveAccount s:complexType s:sequence s:element minOccurs=0 maxOccurs=1 name=username type=s:string / /s:sequence /s:complexType /s:element s:element name=RemoveAccountResponse s:complexType s:sequence s:element minOccurs=0 maxOccurs=1 name=RemoveAccountResult type=s:string / /s:sequence /s:complexType /s:element snipp snipp wsdl:message name=RemoveAccountSoapIn wsdl:part name=parameters element=tns:RemoveAccount / /wsdl:message wsdl:message name=RemoveAccountSoapOut wsdl:part name=parameters element=tns:RemoveAccountResponse / /wsdl:message wsdl:message name=RemoveAccountAuthHeader wsdl:part name=AuthHeader element=tns:AuthHeader / /wsdl:message snipp snipp wsdl:portType name=Service1Soap .. wsdl:operation name=RemoveAccount wsdl:input message=tns:RemoveAccountSoapIn / wsdl:output message=tns:RemoveAccountSoapOut / /wsdl:operation .. /wsdl:portType snipp snipp wsdl:binding name=Service1Soap type=tns:Service1Soap soap:binding transport=http://schemas.xmlsoap.org/soap/http; / .. wsdl:operation name=RemoveAccount soap12:operation soapAction=http://aaa.net/RemoveAccount; style=document / wsdl:input soap12:body use=literal / soap12:header message=tns:RemoveAccountAuthHeader part=AuthHeader use=literal / /wsdl:input wsdl:output soap12:body use=literal / /wsdl:output /wsdl:operation .. /wsdl:binding snipp Version Info: /** * This class was generated by Apache CXF (incubator) 2.0.5-incubator-SNAPSHOT * Mon Mar 31 16:34:26 CEST 2008 * Generated source version: 2.0.5-incubator-SNAPSHOT * */
RE: Error inAbstractHTTPDestination.setHeaders,AbstractHTTPDestination.setHeaders
Sorry for the delay on this, but I'm pretty certain that CXF has a bug. I discovered that Siteminder does indeed blank out the password in the Basic Authorization header, once the user is authenticated via Sitemeinder, for security purposes, however there is *still* a colon character, therefore this fulfills the RFC-2617 spec, which allows for a zero-length password. I quote the BNF from the spec: http://www.rfc.net/rfc2617.html#p5 To receive authorization, the client sends the userid and password, separated by a single colon (:) character, within a base64 [7] encoded string in the credentials. basic-credentials = base64-user-pass base64-user-pass = base64 [4] encoding of user-pass, except not limited to 76 char/line user-pass = userid : password userid = *TEXT excluding : password= *TEXT As you can see, zero-length passwords are permitted. The fix is a one-liner, in org.apache.cxf.transport.http.AbstractHTTPDestination, line 137 (snapshot 2008-01-30) Change the line from: String password = authInfo[1]; ...to: String password = (authInfo.length1?authInfo[1]:); I took the liberty of creating a Jira entry for this bug: https://issues.apache.org/jira/browse/CXF-1495 Thanks, -Chris Wolf -Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] Sent: Friday, March 21, 2008 8:43 PM To: cxf-user@incubator.apache.org Subject: RE: Error inAbstractHTTPDestination.setHeaders,AbstractHTTPDestination.setHeaders I've been looking at our Basic Authentication recently--the error messages have been cryptic in many cases, not providing acceptable feedback. In your case below, we should have a precise error message about an invalid format in the Authorization header field--not just an NPE of course. If you could submit a JIRA for this it would be appreciated, else I'll try to remember. I don't think we should make an exception for Siteminder though, because that might open up a security hole. Also, Section two of RFC 2617[1] states: To receive authorization, the client sends the userid and password, separated by a single colon (:) character, within a base64 [7] encoded string in the credentials. Apparently both username and password are always needed. I don't know Siteminder but I would think they would have an option to always supply a password in order to be RFC 2617 compliant. If not, please let them know about it. Thanks, Glen [1] http://www.faqs.org/rfcs/rfc2617.html Am Freitag, den 21.03.2008, 11:30 -0400 schrieb Wolf, Chris (IT): Glen, Thanks again for your help. I downloaded the source and looked at it before going through the laborious task of setting up for remote debugging. I can see the the issue is the code in AbstractHTTPDestination always assumes the value of the Authorization header will always be a base64 encoded username:password value -- in my case, we use Siteminder authentication, so sometimes the value of the Authorization header is just the base64 encoded username -- without a colon and password, i.e. no :passw, which exactly explains this array index out of bounds exception. The workaround is, I'm going to tell my users to log out of Siteminder and re-authenticate, such that the Authorization header always has both pieces in the value. I would like to present a patch for the case where the Authorization header value does not contain a colon character, even for Basic type of authentication, but I'm not sure special accomodation would be made for Siteminder, unelss the RFC for Basic authentication says the Authorization header may contain just an encoded username in certain circumstances. -Chris -Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] Sent: Friday, March 21, 2008 7:12 AM To: cxf-user@incubator.apache.org Subject: Re: Error in AbstractHTTPDestination.setHeaders,AbstractHTTPDestination.setHeaders Am Freitag, den 21.03.2008, 01:27 -0400 schrieb Wolf, Chris (IT): If I run my service inside a Tomcat-5.5 runtime configured in Eclipse-3.2, all works fine. I run the very same code, deployed on Tomcat-5.5 on Linux, I get this error. If anyone can suggest something short of debuggin the CXF source, that would be great. I am using 2.0.4. If nobody else can answer your question, time to debug the CXF source: http://www.jroller.com/gmazza/date/20071212 Step #5 would probably be most important for you. Glen 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. 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
WSDL First Development Cycle - specifically wsdl:port address question
I'm looking for suggestions for a best practice in how we accomplish moving our CXF code through the various parts of our development lifecycle - i.e. development, test, and production. We have divided these responsibilities among three hosts - ws-dev, ws-tst, and ws (production). We also prefer WSDL first development and are supplying our own wsdl to CXF. The problem we have is that we have to either change the wsdl as we move through the various stages to reflect the new host, or add ports for each in the original wsdl like so: wsdl:service name=PersonService wsdl:port name=PersonPortStg binding=tns:PersonBinding soap:address location=https://ws-tst/services/personService/PersonSOAP; / /wsdl:port wsdl:port name=PersonPortDev binding=tns:PersonBinding soap:address location=https://ws-dev/services/personService/PersonSOAP; / /wsdl:port wsdl:port name=PersonPortProd binding=tns:PersonBinding soap:address location=https://ws/services/personService/PersonSOAP; / /wsdl:port wsdl:port name=PersonPortLocal binding=tns:PersonBinding soap:address location=http://localhost:8080/personService/PersonSOAP; / /wsdl:port /wsdl:service We are early enough in the process that we can change our practice without much pain right now, but soon we will have to live with what we have. We are really interested in what others are doing to handle this issue. Thanks in advance, Brent -- View this message in context: http://www.nabble.com/WSDL-First-Development-Cycle---specifically-wsdl%3Aport-address-question-tp16399116p16399116.html Sent from the cxf-user mailing list archive at Nabble.com.
