Handling internal errors via SOAP faults
Hello, I have a general question for WSDL design regarding internal web service errors not the fault of the SOAP client request, such as database unavailable or system down or whatever. For example, let's say I have a simple GetCapital web service that takes a country and returns the name of its capital. One obvious user-instigated error is providing a country name that doesn't exist. Such a wsdl operation might be: wsdl:operation name=GetCapital wsdl:input message=tns:GetCapitalRequest / wsdl:output message=tns:GetCapitalResponse / wsdl:fault message=tns:InvalidCountryNameFault name=InvalidCountryNameFault / /wsdl:operation But what about exceptions due to the internal service-side errors not the fault of the SOAP client request (e.g., database being down, JNDI lookup not functioning, etc.) In this case, do I add an additional wsdl:fault (perhaps InternalServiceErrorFault) to each wsdl:operation or is there a generic error handling mechanism in JAX-WS that would not require me to burden each wsdl:operation with this additional fault? Thanks, Glen
RE: CXF Osgi bundle problem
It's working now with Equinox, thank you :) -- View this message in context: http://www.nabble.com/CXF---Osgi-bundle-problem-tp15880268p15891150.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: Accessing WebService that requires username/password
xbranko wrote: For me the problem is that I do not have access to the server, i.e. I have to do everything from the client side. Also javax.xml.ws.Service class does not have a default constructor, but rather only protected constructor that takes java.net.URL wsdlDocumentLocation and QName serviceName. It internally (in class sun.net.www.protocol.http.HttpURLConnection, method getInputStream, line 1241) tries to fetch the URL, and this is where the problem is. If it's internally using the standard URL mechanism then have you tried registering a java.net.Authenticator to supply the username and password? http://www.javaworld.com/javaworld/javatips/jw-javatip46.html Ian -- Ian Roberts | Department of Computer Science [EMAIL PROTECTED] | University of Sheffield, UK
Re: Nordic charaters problem in SOAP/MQ
WIndows does not have a code page for UTF-8. If you want to display UTF-8, you have either send UTF-16 to the 'W' API or convert to some local code page. On Fri, Mar 7, 2008 at 2:54 AM, mr.andersen [EMAIL PROTECTED] wrote: Problem found and solved! First of all - thanks for the quick responses. I have looked more into kode and the bytes written to my log. And I can conclude that there is no problem with SAAJ (which would wonder me) or CXF. The problem lays in the way bytes are presented onscreen, when nordic characters are displayed. Maybe I should start to tell more about the environment i'm working in: Windows (danish XP version) RAD 7, which by the way uses cp1252 as encoding in the projects) IBM MQ As you proberly know nordic characters is presented as 2 bytes in UTF-8 - for example is aring; - C3 A5. When the that character is written onscreen or I use Wordpad, the cp1252 is taking over and the translation is Atilde;yen;. But if you use ultraedit to see which bytes (short cut: ctrl+h) it is, it's okay. So where is the problem? Well the problem lays in the way IBM have implemented javax.jms.TextMesage. It seams like when a TextMessage is created the dobbelt bytes are converted into dobbelt bytes. So Atilde; is converted to C3 A0 and yen; C2 A5. So the way to solve this is using ByteMessage and luckily CXF gives a way to set the runtime policy in the WSDL (lt;jms:runtimePolicy messageType=binary/gt;) The problem here is that doesn't work in CXF 2.0.1, so I had to take out the conduit and set the messageType by myself. JMSConduit conduit = (JMSConduit)client.getConduit(); conduit.getRuntimePolicy().setMessageType(MessageFormatType.BINARY); -- View this message in context: http://www.nabble.com/Nordic-charaters-problem-in-SOAP-MQ-tp15845741p15891076.html Sent from the cxf-user mailing list archive at Nabble.com.
AW: trying to use ClientProxyFactoryBean but failing
I can´t tell you whats going on, just wanted to mention that it seems that your problem is related to mine, which I originally postet under thread http://www.nabble.com/-2.0.4--Service-unit-tests-fail-after-upgrade-from-2.0.2-to15610639.html Somehow my last response on that thread didn´t make it to the list. What I can say is that this probable issue also happens with CXF 2.0.2. I have put together a simple maven test project that can reproduce the issue. It is available under: http://lando23.net/simple-cxf-test.zip (12,6 KB) The project contains a simple service interface+impl, 1 spring config file and 1 test case. Running 'mvn test' will throw the exception described by Dan Lipofsky. Maybe someone of the CXF crew can have a look at it ;-) Thanks in advance -Ursprüngliche Nachricht- Von: Daniel Lipofsky [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 7. März 2008 01:00 An: cxf-user@incubator.apache.org Betreff: trying to use ClientProxyFactoryBean but failing Can anyone tell me why the first form works but the second doesn't? I am trying to start using the factory stuff but it is failing. What am I doing wrong? Works: TxService txService = new TxService(); TxPortType txPort = txService.getTxPort(); MapString, Object context = ((BindingProvider) txPort).getRequestContext(); context.put(BindingProvider.USERNAME_PROPERTY, me); context.put(BindingProvider.PASSWORD_PROPERTY, hello); context.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, http://localhost/ws/services/Tx;); txPort.getObjects(searchTerms, 0, 0); Fails: ClientProxyFactoryBean factory = new ClientProxyFactoryBean(); factory.setServiceClass(TxPortType.class); factory.setUsername(me); factory.setPassword(hello); factory.setAddress(http://localhost/ws/services/Tx;); TxPortType client = (TxPortType)factory.create(); client.getObjects(searchTerms, 0, 0); Error: org.apache.cxf.interceptor.Fault: Could not send Message. at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingI nterceptor.handleMessage(MessageSenderInterceptor.java:64) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC hain.java:208) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:276) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:222) at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at org.apache.cxf.frontend.ClientProxy.invoke(ClientProxy.java:68) at $Proxy36.getObjects(Unknown Source) at client.WSClient1.download(WSClient1.java:41) at client.WSClient1.main(WSClient1.java:29) Caused by: java.net.HttpRetryException: cannot retry due to server authentication, in streaming mode at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnec tion.java:1012) at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:367) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResp onse(HTTPConduit.java:1863) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTP Conduit.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$MessageSenderEndingI nterceptor.handleMessage(MessageSenderInterceptor.java:62) ... 8 more Thanks, Dan
Re: trying to use ClientProxyFactoryBean but failing
Your error is a bit strange. It looks like it could be one of: 1) The name/password might be wrong or something and the server is re-asking you to authenticate 2) The server might be sending a redirect. You might want to put a wireshark/tcpdump trace on it to see what the server is sending back. That said, you can also try turning off the streaming and turning on the auto redirects. Performance will be slightly lower (has to buffer the full message), but it can then retry the request. TxService txService = new TxService(); TxPortType txPort = txService.getTxPort(); Client client = ClientProxy.getClient(txPort); HTTPConduit httpConduit = (HTTPConduit) client.getConduit(); httpConduit.getClient().setAllowChunking(false); httpConduit.getClient().setAutoRedirect(true); ... Dan On Thursday 06 March 2008, Daniel Lipofsky wrote: Can anyone tell me why the first form works but the second doesn't? I am trying to start using the factory stuff but it is failing. What am I doing wrong? Works: TxService txService = new TxService(); TxPortType txPort = txService.getTxPort(); MapString, Object context = ((BindingProvider) txPort).getRequestContext(); context.put(BindingProvider.USERNAME_PROPERTY, me); context.put(BindingProvider.PASSWORD_PROPERTY, hello); context.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, http://localhost/ws/services/Tx;); txPort.getObjects(searchTerms, 0, 0); Fails: ClientProxyFactoryBean factory = new ClientProxyFactoryBean(); factory.setServiceClass(TxPortType.class); factory.setUsername(me); factory.setPassword(hello); factory.setAddress(http://localhost/ws/services/Tx;); TxPortType client = (TxPortType)factory.create(); client.getObjects(searchTerms, 0, 0); Error: org.apache.cxf.interceptor.Fault: Could not send Message. at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndin gI nterceptor.handleMessage(MessageSenderInterceptor.java:64) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto rC hain.java:208) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:276) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:222) at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at org.apache.cxf.frontend.ClientProxy.invoke(ClientProxy.java:68) at $Proxy36.getObjects(Unknown Source) at client.WSClient1.download(WSClient1.java:41) at client.WSClient1.main(WSClient1.java:29) Caused by: java.net.HttpRetryException: cannot retry due to server authentication, in streaming mode at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConn ec tion.java:1012) at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:367) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleRe sp onse(HTTPConduit.java:1863) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HT TP Conduit.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$MessageSenderEndin gI nterceptor.handleMessage(MessageSenderInterceptor.java:62) ... 8 more Thanks, Dan -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: NullPointerException thrown by CXFServlet
Spring 2.5.2 or 2.0.x? This LOOKS like 2.5.2. Logged as bug: https://issues.apache.org/jira/browse/CXF-1435 Can you try the 2.0.5 snapshots and see if it's fixed? Yea, you would thing Spring 2.5.2 would be backwords compatible, with 2.5.1, but Dan On Thursday 06 March 2008, junker66 wrote: I'm getting the following error while deploying a service in tomcat: Mar 6, 2008 3:09:50 PM org.apache.catalina.core.ApplicationContext log SEVERE: StandardWrapper.Throwable java.lang.NullPointerException at org.springframework.context.support.AbstractRefreshableConfigApplicati onContext.setConfigLocations(AbstractRefreshableConfigApplicationContex t.java:78) at org.springframework.context.support.ClassPathXmlApplicationContext.in it(ClassPathXmlApplicationContext.java:137) at org.apache.cxf.bus.spring.BusApplicationContext.init(BusApplicationC ontext.java:68) at org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory. java:84) at org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory. java:65) at org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory. java:54) at org.apache.cxf.transport.servlet.CXFServlet.loadSpringBus(CXFServlet.j ava:101) at org.apache.cxf.transport.servlet.CXFServlet.loadBus(CXFServlet.java:63 ) at org.apache.cxf.transport.servlet.AbstractCXFServlet.init(AbstractCXFSe rvlet.java:86) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.j ava:1161) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:981 ) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext .java:4058) what could be the issue here? any help is appreciated. thanks, gary -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Accessing WebService that requires username/password
Unfortunately, this is a known issue. :-( Basically, for the SOAP communication, the http:conduit bean things in the config are used to pick up authentication things, ssl certs, etc... so a proper secure connection can be made to protect the data. Unfortunately, the WSDL retrieval part doesn't use the conduits. It just uses a plain old ordinary new URL(address).openConnection().getInputStream() type thing. Dan On Thursday 06 March 2008, xbranko wrote: Yes it does. I was able to use it, by using a locally cached copy (to avoid the authentication problem). Given that the auto generated code uses class javax.xml.ws.Service, during object instantiation the problem is there (see my answers to previous posts). It seems that for authenticated web services, another approach is needed. -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Handling internal errors via SOAP faults
Glen, I have been fighting against this sort of questions from several weeks now, I start a sample project that is on Jira about correct handling, unfortunately I haven't found an answer from someone who know, neither I have found the way to produce correct code for server, client faults. Anyway my idea, is to only expose the exception that can be handled by the client, like InvalidCountryNameFault or MaxRequestQuantityOverLimit, mark these as Client Fault, and any other exception like (RuntimeException), DBNotAvailable, etc (things client can't handle, ServiceException) as a general exception marked as Server Fault, but as I said, I haven't found the way to do this. Regards, -- David Castañeda R.
Re: Handling internal errors via SOAP faults
In general, the jaxws way of doing this is to map the runtime exceptions to a very generic soap fault that is fault code SERVER and just the message (ex.getMessage()) is set into the fault message. On the client side, this ends up throwing the generic SOAPFaultException (but with the correct message set). Basically, if you use a declared exception (wsdl:fault), you can have a properly typed exception on both sides.If you don't use a declared exception, you basically just get very generic stuff on the wire and on the client side. Dan On Friday 07 March 2008, Glen Mazza wrote: Hello, I have a general question for WSDL design regarding internal web service errors not the fault of the SOAP client request, such as database unavailable or system down or whatever. For example, let's say I have a simple GetCapital web service that takes a country and returns the name of its capital. One obvious user-instigated error is providing a country name that doesn't exist. Such a wsdl operation might be: wsdl:operation name=GetCapital wsdl:input message=tns:GetCapitalRequest / wsdl:output message=tns:GetCapitalResponse / wsdl:fault message=tns:InvalidCountryNameFault name=InvalidCountryNameFault / /wsdl:operation But what about exceptions due to the internal service-side errors not the fault of the SOAP client request (e.g., database being down, JNDI lookup not functioning, etc.) In this case, do I add an additional wsdl:fault (perhaps InternalServiceErrorFault) to each wsdl:operation or is there a generic error handling mechanism in JAX-WS that would not require me to burden each wsdl:operation with this additional fault? Thanks, Glen -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
interface and implemantation files under different package
Hi, If I put interface and implementation classes in different package, CXF doesn't expose all my methods in wsdl file. did any body has same problem before? do I need to add extra annotations in interface or implementation files? Thanks, Mehmet Connect with friends from any web browser - no download required. Try the new Yahoo! Canada Messenger for the Web BETA at http://ca.messenger.yahoo.com/webmessengerpromo.php
Re: Handling internal errors via SOAP faults
I use a fault called OperationFailedFault, and set its payload to the root
exception's message:
try {
context.commitChanges();
} catch(Exception e) {
context.rollbackChanges();
throw new OperationFailedFault(e.getMessage(), Commit failed,
e);
}
On Fri, Mar 7, 2008 at 4:05 AM, Glen Mazza [EMAIL PROTECTED] wrote:
Hello, I have a general question for WSDL design regarding internal web
service errors not the fault of the SOAP client request, such as
database unavailable or system down or whatever.
For example, let's say I have a simple GetCapital web service that
takes a country and returns the name of its capital. One obvious
user-instigated error is providing a country name that doesn't exist.
Such a wsdl operation might be:
wsdl:operation name=GetCapital
wsdl:input message=tns:GetCapitalRequest /
wsdl:output message=tns:GetCapitalResponse /
wsdl:fault message=tns:InvalidCountryNameFault
name=InvalidCountryNameFault /
/wsdl:operation
But what about exceptions due to the internal service-side errors not
the fault of the SOAP client request (e.g., database being down, JNDI
lookup not functioning, etc.) In this case, do I add an additional
wsdl:fault (perhaps InternalServiceErrorFault) to each wsdl:operation
or is there a generic error handling mechanism in JAX-WS that would not
require me to burden each wsdl:operation with this additional fault?
Thanks,
Glen
Re: Accessing WebService that requires username/password
ianroberts wrote: If it's internally using the standard URL mechanism then have you tried registering a java.net.Authenticator to supply the username and password? http://www.javaworld.com/javaworld/javatips/jw-javatip46.html Ian That did it! This is good in simple case of accessing a single service. (I found a good discussion at http://jroller.com/openInfrastructure/ Eoghan Glynn's blog search for Why is java.net.Authenticator so lame? on the page) But that is not CXF problem, but rather java.net.Authenticator's. Thanks for your help! -- View this message in context: http://www.nabble.com/Accessing-WebService-that-requires-username-password-tp15863184p15902145.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: Handling internal errors via SOAP faults
On Friday 07 March 2008, David Castañeda wrote:
Glen, I have been fighting against this sort of questions from several
weeks now,
I start a sample project that is on Jira about correct handling,
unfortunately I haven't found an answer from someone who know, neither
I have found the way to produce correct code for server, client
faults.
Anyway my idea, is to only expose the exception that can be handled by
the client, like InvalidCountryNameFault or
MaxRequestQuantityOverLimit, mark these as Client Fault, and any other
exception like (RuntimeException), DBNotAvailable, etc (things client
can't handle, ServiceException) as a general exception marked as
Server Fault, but as I said, I haven't found the way to do this.
That's probably because the spec specifically does not allow for them.
I've looked at the sample in the JIRA and there will be no way to do it,
per spec. Basically, undeclared exceptions are all to be treated as
generic runtime exceptions and mapped, per spec, to a relatively
generice soap:fault on the wire and then to a SOAPFaultException on the
client side. If you want properly typed exceptions, you HAVE to put
them on the SEI interface methods.
Using some JAX-WS/JAXB tricks, you can control the on-the-wire
representation of the exception a little more, but that won't stop it
from being mapped to a generic SOAPFaultException on the client side.
For example, if we take your sample from CXF-1434 and change the
UncheckedWrongTextException to look like:
@WebFault(name = UncheckedWrongTextException)
public class UncheckedWrongTextException extends RuntimeException {
UncheckedWrongText i;
public UncheckedWrongTextException(String msg) {
super(msg);
i = new UncheckedWrongText();
i.setMessage(msg);
}
public UncheckedWrongTextException(String msg, int t) {
super(msg);
i = new UncheckedWrongText();
i.setMessage(msg);
i.setIdx(t);
}
public UncheckedWrongText getFaultInfo() {
return i;
}
@XmlRootElement
public static class UncheckedWrongText {
int idx;
String msg;
public int getIdx() {
return idx;
}
public void setIdx(int i) {
idx = i;
}
public void setMessage(String m) {
msg = m;
}
public String getMessage() {
return msg;
}
}
}
And then add to HelloWorld.java:
@XmlSeeAlso({UncheckedWrongTextException.UncheckedWrongText.class})
Then the on-the-wire fault would look like:
soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;
soap:Body
soap:Fault
faultcodesoap:Server/faultcode
faultstringOnly characters are allowed/faultstring
detail
ns2:uncheckedWrongText xmlns:ns2=http://spring.demo/;
idx0/idx
messageOnly characters are allowed/message
/ns2:uncheckedWrongText
/detail
/soap:Fault
/soap:Body
/soap:Envelope
However, the client will still only get a SOAPFaultException. In this
case, though, the SOAPFaultException will have a getDetail() element
that contains the detail. Thus, it IS more information to the user.
---
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
Re: interface and implemantation files under different package
That would be very strange. I just attempted a quick test here and it worked fine. Is there any way you can send a testcase? Dan On Friday 07 March 2008, Mehmet Imga wrote: Hi, If I put interface and implementation classes in different package, CXF doesn't expose all my methods in wsdl file. did any body has same problem before? do I need to add extra annotations in interface or implementation files? Thanks, Mehmet Connect with friends from any web browser - no download required. Try the new Yahoo! Canada Messenger for the Web BETA at http://ca.messenger.yahoo.com/webmessengerpromo.php -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: AW: trying to use ClientProxyFactoryBean but failing
Your case is very different. I honestly have no idea how that would have worked even with 2.0.2. In your case, your client is specifically using the URL: http://localhost:8080/cxf/TestService However, your service is using some Mock thing that isn't opening up any port. The simple fix is to change your cxf.context.xml to remove the import of cxf-servlet and add: import resource=classpath:META-INF/cxf/cxf-extension-http-jetty.xml / Thus, when the service pops up, jetty will properly open the port, the client will connect, the test passes. Maybe we had some sort of dependency issue with 2.0.2 that cxf-servlet also brought in jetty or something like that that is now fixed. Don't really know. Dan On Friday 07 March 2008, Holger Stolzenberg wrote: I can´t tell you whats going on, just wanted to mention that it seems that your problem is related to mine, which I originally postet under thread http://www.nabble.com/-2.0.4--Service-unit-tests-fail-after-upgrade-fr om-2.0.2-to15610639.html Somehow my last response on that thread didn´t make it to the list. What I can say is that this probable issue also happens with CXF 2.0.2. I have put together a simple maven test project that can reproduce the issue. It is available under: http://lando23.net/simple-cxf-test.zip (12,6 KB) The project contains a simple service interface+impl, 1 spring config file and 1 test case. Running 'mvn test' will throw the exception described by Dan Lipofsky. Maybe someone of the CXF crew can have a look at it ;-) Thanks in advance -Ursprüngliche Nachricht- Von: Daniel Lipofsky [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 7. März 2008 01:00 An: cxf-user@incubator.apache.org Betreff: trying to use ClientProxyFactoryBean but failing Can anyone tell me why the first form works but the second doesn't? I am trying to start using the factory stuff but it is failing. What am I doing wrong? Works: TxService txService = new TxService(); TxPortType txPort = txService.getTxPort(); MapString, Object context = ((BindingProvider) txPort).getRequestContext(); context.put(BindingProvider.USERNAME_PROPERTY, me); context.put(BindingProvider.PASSWORD_PROPERTY, hello); context.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, http://localhost/ws/services/Tx;); txPort.getObjects(searchTerms, 0, 0); Fails: ClientProxyFactoryBean factory = new ClientProxyFactoryBean(); factory.setServiceClass(TxPortType.class); factory.setUsername(me); factory.setPassword(hello); factory.setAddress(http://localhost/ws/services/Tx;); TxPortType client = (TxPortType)factory.create(); client.getObjects(searchTerms, 0, 0); Error: org.apache.cxf.interceptor.Fault: Could not send Message. at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndin gI nterceptor.handleMessage(MessageSenderInterceptor.java:64) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto rC hain.java:208) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:276) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:222) at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at org.apache.cxf.frontend.ClientProxy.invoke(ClientProxy.java:68) at $Proxy36.getObjects(Unknown Source) at client.WSClient1.download(WSClient1.java:41) at client.WSClient1.main(WSClient1.java:29) Caused by: java.net.HttpRetryException: cannot retry due to server authentication, in streaming mode at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConn ec tion.java:1012) at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:367) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleRe sp onse(HTTPConduit.java:1863) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HT TP Conduit.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$MessageSenderEndin gI nterceptor.handleMessage(MessageSenderInterceptor.java:62) ... 8 more Thanks, Dan -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: NullPointerException thrown by CXFServlet
Yes, I am using spring 2.5.2 and with the latest 2.0.5 snapshot, the error went away and the service is now up and running. Thanks for your help. g dkulp wrote: Spring 2.5.2 or 2.0.x? This LOOKS like 2.5.2. Logged as bug: https://issues.apache.org/jira/browse/CXF-1435 Can you try the 2.0.5 snapshots and see if it's fixed? Yea, you would thing Spring 2.5.2 would be backwords compatible, with 2.5.1, but Dan On Thursday 06 March 2008, junker66 wrote: I'm getting the following error while deploying a service in tomcat: Mar 6, 2008 3:09:50 PM org.apache.catalina.core.ApplicationContext log SEVERE: StandardWrapper.Throwable java.lang.NullPointerException at org.springframework.context.support.AbstractRefreshableConfigApplicati onContext.setConfigLocations(AbstractRefreshableConfigApplicationContex t.java:78) at org.springframework.context.support.ClassPathXmlApplicationContext.in it(ClassPathXmlApplicationContext.java:137) at org.apache.cxf.bus.spring.BusApplicationContext.init(BusApplicationC ontext.java:68) at org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory. java:84) at org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory. java:65) at org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory. java:54) at org.apache.cxf.transport.servlet.CXFServlet.loadSpringBus(CXFServlet.j ava:101) at org.apache.cxf.transport.servlet.CXFServlet.loadBus(CXFServlet.java:63 ) at org.apache.cxf.transport.servlet.AbstractCXFServlet.init(AbstractCXFSe rvlet.java:86) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.j ava:1161) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:981 ) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext .java:4058) what could be the issue here? any help is appreciated. thanks, gary -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog -- View this message in context: http://www.nabble.com/NullPointerException-thrown-by-CXFServlet-tp15883372p15907016.html Sent from the cxf-user mailing list archive at Nabble.com.
RE: trying to use ClientProxyFactoryBean but failing
username/password are not wrong because I used the same username/password for each method and the first one works. I tried the change you suggested and now I get a different error. Does this give you any more info? ClientProxyFactoryBean factory = new ClientProxyFactoryBean(); factory.setServiceClass(TxPortType.class); factory.setUsername(me); factory.setPassword(hello); factory.setAddress(http://localhost/ws/services/Tx;); TxPortType port = (TxPortType)factory.create(); Client client = factory.getClientFactoryBean().getClient(); HTTPConduit httpConduit = (HTTPConduit) client.getConduit(); httpConduit.getClient().setAllowChunking(false); httpConduit.getClient().setAutoRedirect(true); port.getObjects(new ArrayListSearchTerm(0), 0, 0); org.apache.cxf.binding.soap.SoapFault: No namespace on html element. at org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMes sage(ReadHeadersInterceptor.java:88) at org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMes sage(ReadHeadersInterceptor.java:56) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC hain.java:208) at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:429) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResp onse(HTTPConduit.java:1955) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTP Conduit.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$MessageSenderEndingI nterceptor.handleMessage(MessageSenderInterceptor.java:62) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC hain.java:208) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:276) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:222) at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at org.apache.cxf.frontend.ClientProxy.invoke(ClientProxy.java:68) at $Proxy36.getObjects(Unknown Source) at client.WSClient1.main(WSClient1.java:33) Thanks, Dan On Friday 07 March 2008, Daniel Kulp wrote: Your error is a bit strange. It looks like it could be one of: 1) The name/password might be wrong or something and the server is re-asking you to authenticate 2) The server might be sending a redirect. You might want to put a wireshark/tcpdump trace on it to see what the server is sending back. That said, you can also try turning off the streaming and turning on the auto redirects. Performance will be slightly lower (has to buffer the full message), but it can then retry the request. TxService txService = new TxService(); TxPortType txPort = txService.getTxPort(); Client client = ClientProxy.getClient(txPort); HTTPConduit httpConduit = (HTTPConduit) client.getConduit(); httpConduit.getClient().setAllowChunking(false); httpConduit.getClient().setAutoRedirect(true); ... Dan On Thursday 06 March 2008, Daniel Lipofsky wrote: Can anyone tell me why the first form works but the second doesn't? I am trying to start using the factory stuff but it is failing. What am I doing wrong? Works: TxService txService = new TxService(); TxPortType txPort = txService.getTxPort(); MapString, Object context = ((BindingProvider) txPort).getRequestContext(); context.put(BindingProvider.USERNAME_PROPERTY, me); context.put(BindingProvider.PASSWORD_PROPERTY, hello); context.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, http://localhost/ws/services/Tx;); txPort.getObjects(searchTerms, 0, 0); Fails: ClientProxyFactoryBean factory = new ClientProxyFactoryBean(); factory.setServiceClass(TxPortType.class); factory.setUsername(me); factory.setPassword(hello); factory.setAddress(http://localhost/ws/services/Tx;); TxPortType client = (TxPortType)factory.create(); client.getObjects(searchTerms, 0, 0); Error: org.apache.cxf.interceptor.Fault: Could not send Message. at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndin gI nterceptor.handleMessage(MessageSenderInterceptor.java:64) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto rC hain.java:208) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:276) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:222) at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at org.apache.cxf.frontend.ClientProxy.invoke(ClientProxy.java:68) at $Proxy36.getObjects(Unknown Source) at client.WSClient1.download(WSClient1.java:41) at client.WSClient1.main(WSClient1.java:29) Caused by: java.net.HttpRetryException: cannot retry due to server authentication, in streaming
