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
RE: Error in AbstractHTTPDestination.setHeaders,AbstractHTTPDestination.setHeaders
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.
Error in AbstractHTTPDestination.setHeaders, AbstractHTTPDestination.setHeaders
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. I searched and found some references about SOAP headers, by my service is not using those, in fact the message looks like: ?xml version=1.0 encoding=utf-8? SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; SOAP-ENV:Body loginUser xmlns=http://services.secadmin.cis.ms.com/types; ns0:servername xmlns:ns0=http://services.secadmin.cis.ms.com/types;MYSERVER/ns0:serv ername ns0:database xmlns:ns0=http://services.secadmin.cis.ms.com/types;my_db/ns0:databas e ns0:username xmlns:ns0=http://services.secadmin.cis.ms.com/types;user56/ns0:userna me ns0:password xmlns:ns0=http://services.secadmin.cis.ms.com/types;user56pw/ns0:pass word /loginUser /SOAP-ENV:Body /SOAP-ENV:Envelope ava.lang.ArrayIndexOutOfBoundsException: 1 org.apache.cxf.transport.http.AbstractHTTPDestination.setHeaders(Abstrac tHTTPDestination.java:137) org.apache.cxf.transport.http.AbstractHTTPDestination.setupMessage(Abstr actHTTPDestination.java:286) org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestin ation.java:82) org.apache.cxf.transport.servlet.ServletController.invokeDestination(Ser vletController.java:213) org.apache.cxf.transport.servlet.ServletController.invoke(ServletControl ler.java:150) org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFSe rvlet.java:170) org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCXFSe rvlet.java:148) javax.servlet.http.HttpServlet.service(HttpServlet.java:709) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) 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.
RE: Getting error while deploying on
When you tried to deploy to Weblogic, did you attempt to deploy as a bare WAR, or wrapped in an EAR? You need to deploy as an EAR. The descriptor setup is documented here: http://cwiki.apache.org/CXF20DOC/appserverguide.html#AppServerGuide-WebL ogic However, when I tried it on WLS-9.2.2, I got the following error upon startup: Mar 11, 2008 7:51:01 AM EDT Warning Deployer BEA-149078 Stack trace for message 149004 weblogic.application.ModuleException: [HTTP:101216]Servlet: cxf failed to prel oad on startup in Web application: secadmin. java.lang.RuntimeException: org.springframework.beans.factory.BeanDefinitionStor eException: Parser configuration exception parsing XML from class path resource [META-INF/cxf/cxf.xml]; nested exception is javax.xml.parsers.ParserConfiguratio nException: Unable to validate using XSD: Your JAXP provider [org.apache.xerces. [EMAIL PROTECTED] does not support XML Schema. Are you run ning on Java 1.4 or below with Apache Crimson? Upgrade to Apache Xerces (or Java 1.5) for full XSD support. at org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory .java:87) at org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory .java:65) at org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory Not sure why it thinks xerces can't handle schmema since the contained WAR has xerces-2.9.0 -Chris -Original Message- From: Binu Andrews [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2008 5:41 AM To: cxf-user@incubator.apache.org Subject: Getting error while deploying on Hi, I am able to deploy my webserice in tomcat as well as JBoss. But I am getting the following error when i deployed the same war in weblogic 9.2 Mar 11, 2008 1:40:15 PM IST Warning HTTP BEA-101162 User defined listener org.springframework.web.context.ContextLoaderListener failed: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.cxf.wsdl.WSDLManager' defined in class path resource [META-INF/cxf/cxf.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.apache.cxf.wsdl11.WSDLManagerImpl]: Constructor threw exception; nested exception is java.lang.ClassCastException: interface org.xmlsoap.schemas.wsdl.http.AddressType. org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.cxf.wsdl.WSDLManager' defined in class path resource [META-INF/cxf/cxf.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.apache.cxf.wsdl11.WSDLManagerImpl]: Constructor threw exception; nested exception is java.lang.ClassCastException: interface org.xmlsoap.schemas.wsdl.http.AddressType at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac tory.createBean(AbstractAutowireCapableBeanFactory.java:454) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObjec t(AbstractBeanFactory.java:254) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.g etSingleton(DefaultSingletonBeanRegistry.java:144) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Ab stractBeanFactory.java:251) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Ab stractBeanFactory.java:163) Truncated. see log file for complete stacktrace org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.apache.cxf.wsdl11.WSDLManagerImpl]: Constructor threw exception; nested exception is java.lang.ClassCastException: interface org.xmlsoap.schemas.wsdl.http.AddressType at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:99) at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:60) at org.springframework.beans.factory.support.SimpleInstantiationStrategy.in stantiate(SimpleInstantiationStrategy.java:45) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac tory.instantiateBean(AbstractAutowireCapableBeanFactory.java:739) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac tory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:727) Truncated. see log file for complete stacktrace java.lang.ClassCastException: interface org.xmlsoap.schemas.wsdl.http.AddressType at java.lang.Class.asSubclass(Class.java:2948) at org.apache.cxf.wsdl.JAXBExtensionHelper.addExtensions(JAXBExtensionHelpe r.java:64) at org.apache.cxf.wsdl11.WSDLManagerImpl.registerInitialExtensions(WSDLMana gerImpl.java:224) at org.apache.cxf.wsdl11.WSDLManagerImpl.init(WSDLManagerImpl.java:97) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) Truncated. see log file for complete stacktrace
RE: Getting error while deploying on weblogic 9.2 but able to do in tomcat
I was able to load my cxf app on WLS-9.2.2 and access the WSDL (havn't tested services yet) I followed the instructions here: http://cwiki.apache.org/CXF20DOC/appserverguide.html#AppServerGuide-Pack warinanear%252Cdeploytheearwithweblogicapplication.xml With a slightly modified weblogic-application.xml: (the xml tag might be redundant) ?xml version=1.0 encoding=UTF-8? weblogic-application xmlns=http://www.bea.com/ns/weblogic/90; xml parser-factory saxparser-factory org.apache.xerces.jaxp.SAXParserFactoryImpl /saxparser-factory document-builder-factory org.apache.xerces.jaxp.DocumentBuilderFactoryImpl /document-builder-factory transformer-factory org.apache.xalan.processor.TransformerFactoryImpl /transformer-factory /parser-factory /xml application-param param-namewebapp.encoding.default/param-name param-valueUTF-8/param-value /application-param prefer-application-packages package-namejavax.jws.*/package-name package-nameorg.apache.xerces.*/package-name package-nameorg.apache.xalan.*/package-name /prefer-application-packages /weblogic-application Chris Wolf Morgan Stanley | Technology 1633 Broadway, 26th Floor | New York, NY 10019 Phone: +1 212 537-2980 [EMAIL PROTECTED] -Original Message- From: Binu Andrews [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2008 8:11 AM To: cxf-user@incubator.apache.org Subject: Getting error while deploying on weblogic 9.2 but able to do in tomcat Hi, I am able to deploy my webserice in tomcat as well as JBoss. But I am getting the following error when i deployed the same war in weblogic 9.2 Mar 11, 2008 1:40:15 PM IST Warning HTTP BEA-101162 User defined listener org.springframework.web.context.ContextLoaderListener failed: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.cxf.wsdl.WSDLManager' defined in class path resource [META-INF/cxf/cxf.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.apache.cxf.wsdl11.WSDLManagerImpl]: Constructor threw exception; nested exception is java.lang.ClassCastException: interface org.xmlsoap.schemas.wsdl.http.AddressType. org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.cxf.wsdl.WSDLManager' defined in class path resource [META-INF/cxf/cxf.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.apache.cxf.wsdl11.WSDLManagerImpl]: Constructor threw exception; nested exception is java.lang.ClassCastException: interface org.xmlsoap.schemas.wsdl.http.AddressType at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac tory.createBean(AbstractAutowireCapableBeanFactory.java:454) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObjec t(AbstractBeanFactory.java:254) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.g etSingleton(DefaultSingletonBeanRegistry.java:144) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Ab stractBeanFactory.java:251) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Ab stractBeanFactory.java:163) Truncated. see log file for complete stacktrace org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.apache.cxf.wsdl11.WSDLManagerImpl]: Constructor threw exception; nested exception is java.lang.ClassCastException: interface org.xmlsoap.schemas.wsdl.http.AddressType at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:99) at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:60) at org.springframework.beans.factory.support.SimpleInstantiationStrategy.in stantiate(SimpleInstantiationStrategy.java:45) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac tory.instantiateBean(AbstractAutowireCapableBeanFactory.java:739) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac tory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:727) Truncated. see log file for complete stacktrace java.lang.ClassCastException: interface org.xmlsoap.schemas.wsdl.http.AddressType at java.lang.Class.asSubclass(Class.java:2948) at org.apache.cxf.wsdl.JAXBExtensionHelper.addExtensions(JAXBExtensionHelpe r.java:64) at org.apache.cxf.wsdl11.WSDLManagerImpl.registerInitialExtensions(WSDLMana gerImpl.java:224) at org.apache.cxf.wsdl11.WSDLManagerImpl.init(WSDLManagerImpl.java:97) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) Truncated. see log
RE: CXF Client not maintaing cookies
I will try it.
BTW, is this the best way to deal with cookies on the *server* side?
My concern is it is not portable. Thanks.
@Resource
public void setWebServiceContext(WebServiceContext ctx) {
context = ctx;
}
//Resource
public WebServiceContext getWebServiceContext() {
return context;
}
[...]
{
MessageContext ctx = getWebServiceContext().getMessageContext();
// transport-specific request/response, cxf-specific property
names
HttpServletRequest request = (HttpServletRequest)
ctx.get(AbstractHTTPDestination.HTTP_REQUEST);
HttpServletResponse response = (HttpServletResponse)
ctx.get(AbstractHTTPDestination.HTTP_RESPONSE);
Cookie[] cookies = request.getCookies();
}
-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 11, 2008 9:24 AM
To: cxf-user@incubator.apache.org
Cc: Wolf, Chris (IT)
Subject: Re: CXF Client not maintaing cookies
Can you try with the 2.0.5 SNAPSHOT?
Due to a bug in 2.0.4, only a single cookie is maintained on the client
side. Thus, if you have mulitple cookies, they won't all be maintained
and sent back. This is fixed with 2.0.5.
The alternitive is to use a session on the server side. The only cookie
going back/forth would be the session cookie and any other state would
be stored in the session. Not ideal.
Dan
On Tuesday 11 March 2008, Wolf, Chris (IT) wrote:
I am trying to set an HTTP cookie from the CXF server. It works with
a browser, but the generated CXF client does not keep or send back
cookies. I tried the code:
SecAdmin_Service ss = new SecAdmin_Service(wsdlURL, SERVICE_NAME);
SecAdmin port = ss.getSecadmin(); BindingProvider provider =
(BindingProvider)port;
provider.getRequestContext().put(BindingProvider.SESSION_MAINTAIN_PROP
ER TY, true);
...as mentioned here:
http://www.nabble.com/JSESSIONID-cookie-not-sent-back-to-server-td1551
40 55.html
but it does not seem to be working. I am using CXF-2.0.4.
Thanks,
-Chris
NOTICE: If received in error, please destroy and notify sender. Sender
does not intend to waive confidentiality or privilege. Use of this
email is prohibited when received in error.
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
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.
RE: Getting error while deploying on
Maybe you can try adding : package-nameorg.xmlsoap.*/package-name to the weblogic-application.xml I sent earlier. -Chris -Original Message- From: Binu Andrews [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2008 8:52 AM To: cxf-user@incubator.apache.org; Wolf, Chris (IT) Subject: Re: Getting error while deploying on I am getting the same problem eventhough i deploy it as an ear file. java.lang.ClassCastException: interface org.xmlsoap.schemas.wsdl.http.AddressType I followed the steps mentioned in http://cwiki.apache.org/CXF20DOC/appserverguide.html#AppServerGuide-WebL ogic Regards -Binu - Original Message - From: Wolf, Chris (IT) [EMAIL PROTECTED] To: cxf-user@incubator.apache.org Sent: Tuesday, March 11, 2008 5:40 PM Subject: RE: Getting error while deploying on When you tried to deploy to Weblogic, did you attempt to deploy as a bare WAR, or wrapped in an EAR? You need to deploy as an EAR. The descriptor setup is documented here: http://cwiki.apache.org/CXF20DOC/appserverguide.html#AppServerGuide-WebL ogic However, when I tried it on WLS-9.2.2, I got the following error upon startup: Mar 11, 2008 7:51:01 AM EDT Warning Deployer BEA-149078 Stack trace for message 149004 weblogic.application.ModuleException: [HTTP:101216]Servlet: cxf failed to prel oad on startup in Web application: secadmin. java.lang.RuntimeException: org.springframework.beans.factory.BeanDefinitionStor eException: Parser configuration exception parsing XML from class path resource [META-INF/cxf/cxf.xml]; nested exception is javax.xml.parsers.ParserConfiguratio nException: Unable to validate using XSD: Your JAXP provider [org.apache.xerces. [EMAIL PROTECTED] does not support XML Schema. Are you run ning on Java 1.4 or below with Apache Crimson? Upgrade to Apache Xerces (or Java 1.5) for full XSD support. at org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory .java:87) at org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory .java:65) at org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory Not sure why it thinks xerces can't handle schmema since the contained WAR has xerces-2.9.0 -Chris -Original Message- From: Binu Andrews [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2008 5:41 AM To: cxf-user@incubator.apache.org Subject: Getting error while deploying on Hi, I am able to deploy my webserice in tomcat as well as JBoss. But I am getting the following error when i deployed the same war in weblogic 9.2 Mar 11, 2008 1:40:15 PM IST Warning HTTP BEA-101162 User defined listener org.springframework.web.context.ContextLoaderListener failed: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.cxf.wsdl.WSDLManager' defined in class path resource [META-INF/cxf/cxf.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.apache.cxf.wsdl11.WSDLManagerImpl]: Constructor threw exception; nested exception is java.lang.ClassCastException: interface org.xmlsoap.schemas.wsdl.http.AddressType. org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.cxf.wsdl.WSDLManager' defined in class path resource [META-INF/cxf/cxf.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.apache.cxf.wsdl11.WSDLManagerImpl]: Constructor threw exception; nested exception is java.lang.ClassCastException: interface org.xmlsoap.schemas.wsdl.http.AddressType at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac tory.createBean(AbstractAutowireCapableBeanFactory.java:454) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObjec t(AbstractBeanFactory.java:254) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.g etSingleton(DefaultSingletonBeanRegistry.java:144) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Ab stractBeanFactory.java:251) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Ab stractBeanFactory.java:163) Truncated. see log file for complete stacktrace org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.apache.cxf.wsdl11.WSDLManagerImpl]: Constructor threw exception; nested exception is java.lang.ClassCastException: interface org.xmlsoap.schemas.wsdl.http.AddressType at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:99) at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:60) at org.springframework.beans.factory.support.SimpleInstantiationStrategy.in stantiate(SimpleInstantiationStrategy.java:45) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac
RE: CXF Client not maintaing cookies
BTW, the code below does not seem to work on Weblogic-9.2.2, although it
works
on Tomcat-5.5, and it sort of works on the embedded Jetty (except really
long cookie
values seems to get truncated.)
-Original Message-
From: Wolf, Chris (IT)
Sent: Tuesday, March 11, 2008 10:05 AM
To: Daniel Kulp; cxf-user@incubator.apache.org
Subject: RE: CXF Client not maintaing cookies
I will try it.
BTW, is this the best way to deal with cookies on the *server* side?
My concern is it is not portable. Thanks.
@Resource
public void setWebServiceContext(WebServiceContext ctx) {
context = ctx;
}
//Resource
public WebServiceContext getWebServiceContext() {
return context;
}
[...]
{
MessageContext ctx = getWebServiceContext().getMessageContext();
// transport-specific request/response, cxf-specific property
names
HttpServletRequest request = (HttpServletRequest)
ctx.get(AbstractHTTPDestination.HTTP_REQUEST);
HttpServletResponse response = (HttpServletResponse)
ctx.get(AbstractHTTPDestination.HTTP_RESPONSE);
Cookie[] cookies = request.getCookies(); }
-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 11, 2008 9:24 AM
To: cxf-user@incubator.apache.org
Cc: Wolf, Chris (IT)
Subject: Re: CXF Client not maintaing cookies
Can you try with the 2.0.5 SNAPSHOT?
Due to a bug in 2.0.4, only a single cookie is maintained on the client
side. Thus, if you have mulitple cookies, they won't all be maintained
and sent back. This is fixed with 2.0.5.
The alternitive is to use a session on the server side. The only cookie
going back/forth would be the session cookie and any other state would
be stored in the session. Not ideal.
Dan
On Tuesday 11 March 2008, Wolf, Chris (IT) wrote:
I am trying to set an HTTP cookie from the CXF server. It works with
a browser, but the generated CXF client does not keep or send back
cookies. I tried the code:
SecAdmin_Service ss = new SecAdmin_Service(wsdlURL, SERVICE_NAME);
SecAdmin port = ss.getSecadmin(); BindingProvider provider =
(BindingProvider)port;
provider.getRequestContext().put(BindingProvider.SESSION_MAINTAIN_PROP
ER TY, true);
...as mentioned here:
http://www.nabble.com/JSESSIONID-cookie-not-sent-back-to-server-td1551
40 55.html
but it does not seem to be working. I am using CXF-2.0.4.
Thanks,
-Chris
NOTICE: If received in error, please destroy and notify sender. Sender
does not intend to waive confidentiality or privilege. Use of this
email is prohibited when received in error.
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
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 received in error.
RE: Need help for XMLStreamException: ParseError at [row,col]:[1,1]
Dan, Thanks for taking the time to help me out. I implemented the code you suggested and the error changed. I'm still getting a 302 on the response. I think I'll need to use the standalone tcpmon, which, if I remember correctly, shows all the HTTP headers. -Chris INFO: AutoRedirect is turned on. Mar 10, 2008 5:02:58 PM org.apache.cxf.phase.PhaseInterceptorChain doIntercept INFO: Interceptor has thrown exception, unwinding now org.apache.cxf.interceptor.Fault: Could not send Message. at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingI nterceptor.handleMessage(MessageSenderInterceptor.java:64) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC hain.java:220) 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.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:142) at $Proxy30.fetchSecIdParamsHist(Unknown Source) at com.ms.cis.secadmin.test.cxf.SecAdminClient.main(SecAdminClient.java:76) Caused by: java.io.IOException: /secadmin/ at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResp onse(HTTPConduit.java:1888) 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) ... 7 more Exception in thread main javax.xml.ws.soap.SOAPFaultException: Could not send Message. at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:182) at $Proxy30.fetchSecIdParamsHist(Unknown Source) at com.ms.cis.secadmin.test.cxf.SecAdminClient.main(SecAdminClient.java:76) Caused by: 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:220) 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.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:142) ... 2 more Caused by: java.io.IOException: /secadmin/ -Original Message- From: Daniel Kulp [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2008 11:04 AM To: cxf-user@incubator.apache.org Cc: Wolf, Chris (IT) Subject: Re: Need help for XMLStreamException: ParseError at [row,col]:[1,1] An HTTP 30x response code is usually a redirect response. By default, due to our streaming nature, we cannot honor redirects. You can configure the HTTPConduit to allow the redirects. When you do that, it no longer can stream (it must buffer the request), but it may work for you. Client client = ClientProxy.getClient(proxy); HTTPConduit http = (HTTPConduit) client.getConduit(); http.getClient().setAutoRedirect(true); Dan On Monday 10 March 2008, Wolf, Chris (IT) wrote: I know this issue has been discussed before, because I found a description and apparent fix here: http://www.mail-archive.com/cxf-user@incubator.apache.org/msg04687.htm l However, putting the updated Xerces and Xalan in the TOMCAT/common/endorsed directory did not solve the issue for me. If I deploy my service as a standalone service embedded in Jetty, (generated via wsdl2java -server)it works, but when I configure it for WAR deployment in Tomcat-5.5, the client (generated via wsdl2java -client) throws the exception shown below. Also when deployed in standalone mode I can retrieve the WSDL via HTTP GET, but when depoyed as a WAR in Tomcat, I just get a 404 error. When I used the TCP/IP Monitor (Eclipse plugin similar to tcpmon) I see the that Client is sending the expected SOAP envelope, but is getting nothing back, however, with HTTP 301 or 302 response codes. I double checked my proxy settings in Eclipse and browser and have verified that both localhost and the canonical hostname are excluded from proxying. I tried both localhost and the canonical hostname in the request. (overriding via BindingProvider.ENDPOINT_ADDRESS_PROPERTY) Any help would be greatly appreciated. -Chris Mar 9, 2008 6:00:44 PM org.apache.cxf.phase.PhaseInterceptorChain doIntercept INFO: Interceptor has thrown exception, unwinding now org.apache.cxf.binding.soap.SoapFault: Error reading XMLStreamReader
RE: Need help for XMLStreamException: ParseError at [row,col]:[1,1]
I switched from using Eclispe's built-in TCP/IP monitor, to using the standalone tcpmon (which shows HTTP headers) and saw that the 302 was redirecting from the canonical host to localhost (as I suspected). However, this redirect issue was a red herring, as the real issue was that I was using the wrong URL the whole time! Your blog page, [2] that totally explained the URL construction process that cleared my murky understanding of this. It turns out that I started the project using the standalone server, which makes the wsdl and services available at the URL in the wsdl, but the WAR/Tomcat deployment adds the extra path component, /services/, which of course, I was oblivious to. After fixing the URL, I was able to retrieve the WSDL, then I was able to get the client working. I would say that your explaination of how each URL path component is traced to where it comes from was extremely helpful, as it was never explained that clearly anywhere I've seen so far. -Chris -Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2008 12:15 AM To: cxf-user@incubator.apache.org Subject: Re: Need help for XMLStreamException: ParseError at [row,col]:[1,1] What are you putting in the WAR file--the web service or the SOAP client? Also, I'm unsure if you should be relying on the autogenerated client--that is primarily a helper file not really part of JAX-WS (GlassFish Metro I don't think provides it.) I've never bothered using it. The first thing to check is to make sure that you can access the Web Service's wsdl from a browser after you have deployed it to Tomcat--if you can't, then no client will ever work. (Check [2] for how WSDL URLs are created using Tomcat and CXF.) Once you know you can access the wsdl from a browser, you should be able to manually create a client similar in appearance to the example here[3] or here[4]. HTH, Glen [1] http://www.jroller.com/gmazza/date/20080308#MTstep9 [2] http://www.jroller.com/gmazza/date/20071019#notes (note #4) [3] http://www.jroller.com/gmazza/entry/using_the_ebay_shopping_api1 (step #7) [4] http://www.jroller.com/gmazza/date/20070929 Am Montag, den 10.03.2008, 00:01 -0400 schrieb Wolf, Chris (IT): I know this issue has been discussed before, because I found a description and apparent fix here: http://www.mail-archive.com/cxf-user@incubator.apache.org/msg04687.htm l However, putting the updated Xerces and Xalan in the TOMCAT/common/endorsed directory did not solve the issue for me. If I deploy my service as a standalone service embedded in Jetty, (generated via wsdl2java -server)it works, but when I configure it for WAR deployment in Tomcat-5.5, the client (generated via wsdl2java -client) throws the exception shown below. Also when deployed in standalone mode I can retrieve the WSDL via HTTP GET, but when depoyed as a WAR in Tomcat, I just get a 404 error. When I used the TCP/IP Monitor (Eclipse plugin similar to tcpmon) I see the that Client is sending the expected SOAP envelope, but is getting nothing back, however, with HTTP 301 or 302 response codes. I double checked my proxy settings in Eclipse and browser and have verified that both localhost and the canonical hostname are excluded from proxying. I tried both localhost and the canonical hostname in the request. (overriding via BindingProvider.ENDPOINT_ADDRESS_PROPERTY) Any help would be greatly appreciated. -Chris Mar 9, 2008 6:00:44 PM org.apache.cxf.phase.PhaseInterceptorChain doIntercept INFO: Interceptor has thrown exception, unwinding now org.apache.cxf.binding.soap.SoapFault: Error reading XMLStreamReader. at org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleM es sage(ReadHeadersInterceptor.java:191) [...] at com.ms.cis.secadmin.services.SecAdmin_Secadmin_Client.main(SecAdmin_Se ca dmin_Client.java:60) Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,1] Message: Premature end of file. at com.sun.xml.stream.XMLReaderImpl.next(XMLReaderImpl.java:563) at com.sun.xml.stream.XMLReaderImpl.nextTag(XMLReaderImpl.java:1177) at org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleM es sage(ReadHeadersInterceptor.java:85) ... 15 more 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 received in error.
CXF Client not maintaing cookies
I am trying to set an HTTP cookie from the CXF server. It works with a browser, but the generated CXF client does not keep or send back cookies. I tried the code: SecAdmin_Service ss = new SecAdmin_Service(wsdlURL, SERVICE_NAME); SecAdmin port = ss.getSecadmin(); BindingProvider provider = (BindingProvider)port; provider.getRequestContext().put(BindingProvider.SESSION_MAINTAIN_PROPER TY, true); ...as mentioned here: http://www.nabble.com/JSESSIONID-cookie-not-sent-back-to-server-td155140 55.html but it does not seem to be working. I am using CXF-2.0.4. Thanks, -Chris 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.
RE: CXF Client not maintaing cookies
That's actually very useful since I use the standalone mode for quick testing, however, the target deployment is for Tomcat-5.5 and I can see a Set-Cookie in an HTTP trace. Thanks Willem, -Chris -Original Message- From: Willem Jiang [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2008 12:36 AM To: cxf-user@incubator.apache.org Subject: Re: CXF Client not maintaing cookies Hi, Does your CXF server use Jetty as a stand alone HTTP Server? If So you need some server side configuration. Please enable the Jetty's support session feature, since the default value is disabled. Here is an example beans xmlns=http://www.springframework.org/schema/beans; xmlns:beans=http://www.springframework.org/schema/beans; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:sec=http://cxf.apache.org/configuration/security; xmlns:http=http://cxf.apache.org/transports/http/configuration; xmlns:httpj=http://cxf.apache.org/transports/http-jetty/configuration; xmlns:jaxws=http://java.sun.com/xml/ns/jaxws; xsi:schemaLocation=http://cxf.apache.org/configuration/security http://cxf.apache.org/schemas/configuration/security.xsd http://cxf.apache.org/transports/http/configuration http://cxf.apache.org/schemas/configuration/http-conf.xsd http://cxf.apache.org/transports/http-jetty/configuration http://cxf.apache.org/schemas/configuration/http-jetty.xsd http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd; ... httpj:engine-factory bus=cxf httpj:engine port=9001 httpj:sessionSupporttrue/hj:sessionSupport /httpj:engine /httpj:engine-factory /beans You need to specify the Jetty engine's port number according to your server's address, in the example the configuration just work for the publishing the service to port 9001. You can find more information about how to configure the Jetty server in CXF here: http://cwiki.apache.org/CXF20DOC/jetty-configuration.html Willem Wolf, Chris (IT) wrote: I am trying to set an HTTP cookie from the CXF server. It works with a browser, but the generated CXF client does not keep or send back cookies. I tried the code: SecAdmin_Service ss = new SecAdmin_Service(wsdlURL, SERVICE_NAME); SecAdmin port = ss.getSecadmin(); BindingProvider provider = (BindingProvider)port; provider.getRequestContext().put(BindingProvider.SESSION_MAINTAIN_PROP ER TY, true); ...as mentioned here: http://www.nabble.com/JSESSIONID-cookie-not-sent-back-to-server-td1551 40 55.html but it does not seem to be working. I am using CXF-2.0.4. Thanks, -Chris 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 received in error.
Need assistance re: ServiceConstructionException
Before posting this, I looked at the JAX-WS spec (although I could only
find 2.1) and searched
the message archives. Before resorting to downloading the CXF source
and building
CXF from scratch so I can debug this problem, I am hoping someone can
help.
I created a service with a number of operations, based on the
wsdl_first sample.
Everything works great in the Jetty-embedded configuration, however,
when I try
to prepare a WAR deployment, and deploy to Tomcat, I receive the
following cryptic error:
Mar 09 10:01:15 bw26wolfch [] 2 Error
org/apache/catalina/core/ContainerBase/[Catalina]/[localhost]/[/secadmin
]
Servlet /secadmin threw load() exception
org.apache.cxf.service.factory.ServiceConstructionException:
Could not find definition for service
{http://services.secadmin.cis.ms.com/}SecAdminImplService.
The generated service interface is:
com.ms.cis.secadmin.services.SecAdmin
The implementation class is:
com.ms.cis.secadmin.services.SecAdminImpl
*** So why is it looking for SecAdminImplService? Why is it appending
Service?
The relevant configuration settings are:
WSDL:
wsdl:definitions name=SecAdmin
targetNamespace=http://services.secadmin.cis.ms.com;
[...]
wsdl:portType name=SecAdmin
[...]
wsdl:binding name=SecAdmin_SOAPBinding type=tns:SecAdmin
[...]
wsdl:service name=SecAdmin
wsdl:port binding=tns:SecAdmin_SOAPBinding name=secadmin
soap:address location=http://localhost:8080/secadmin/
/wsdl:port
/wsdl:service
CXF-SERVLET:
beans xmlns=http://www.springframework.org/schema/beans;
[...]
jaxws:endpoint
id=secadmin
implementor=com.ms.cis.secadmin.services.SecAdminImpl
wsdlLocation=WEB-INF/wsdl/secadmin.wsdl
address=/secadmin
jaxws:features
bean class=org.apache.cxf.feature.LoggingFeature/
/jaxws:features
/jaxws:endpoint
/beans
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.
RE: Need assistance re: ServiceConstructionException
Glen,
Thanks so much for helping me - that was the issue. I actually did not
even have
a WebService annotation in my implementation class, because I did
wsdl-first and
thought the WebService annotation in the generated SEI was sufficient.
If the implementation
class implements the SEI, I don't see why the WebService annotation is
needed in both,
but whatever, all I care about (right now) is that it no longer throws
an exception.
Thanks,
-Chris
-Original Message-
From: Glen Mazza [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 09, 2008 5:09 PM
To: cxf-user@incubator.apache.org
Subject: Re: Need assistance re: ServiceConstructionException
Check your serviceName value for the @javax.jws.WebService annotation
preceding your web service's implementation class, like here:
http://www.jroller.com/gmazza/date/20080308#MTstep6
HTH,
Glen
Am Sonntag, den 09.03.2008, 11:04 -0400 schrieb Wolf, Chris (IT):
Before posting this, I looked at the JAX-WS spec (although I could
only find 2.1) and searched the message archives. Before resorting to
downloading the CXF source and building CXF from scratch so I can
debug this problem, I am hoping someone can help.
I created a service with a number of operations, based on the
wsdl_first sample.
Everything works great in the Jetty-embedded configuration, however,
when I try to prepare a WAR deployment, and deploy to Tomcat, I
receive the following cryptic error:
Mar 09 10:01:15 bw26wolfch [] 2 Error
org/apache/catalina/core/ContainerBase/[Catalina]/[localhost]/[/secadm
in
]
Servlet /secadmin threw load() exception
org.apache.cxf.service.factory.ServiceConstructionException:
Could not find definition for service
{http://services.secadmin.cis.ms.com/}SecAdminImplService.
The generated service interface is:
com.ms.cis.secadmin.services.SecAdmin
The implementation class is:
com.ms.cis.secadmin.services.SecAdminImpl
*** So why is it looking for SecAdminImplService? Why is it
appending Service?
The relevant configuration settings are:
WSDL:
wsdl:definitions name=SecAdmin
targetNamespace=http://services.secadmin.cis.ms.com;
[...]
wsdl:portType name=SecAdmin
[...]
wsdl:binding name=SecAdmin_SOAPBinding type=tns:SecAdmin [...]
wsdl:service name=SecAdmin
wsdl:port binding=tns:SecAdmin_SOAPBinding name=secadmin
soap:address location=http://localhost:8080/secadmin/
/wsdl:port
/wsdl:service
CXF-SERVLET:
beans xmlns=http://www.springframework.org/schema/beans;
[...]
jaxws:endpoint
id=secadmin
implementor=com.ms.cis.secadmin.services.SecAdminImpl
wsdlLocation=WEB-INF/wsdl/secadmin.wsdl
address=/secadmin
jaxws:features
bean class=org.apache.cxf.feature.LoggingFeature/
/jaxws:features
/jaxws:endpoint
/beans
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 received in error.
Need help for XMLStreamException: ParseError at [row,col]:[1,1]
I know this issue has been discussed before, because I found a description and apparent fix here: http://www.mail-archive.com/cxf-user@incubator.apache.org/msg04687.html However, putting the updated Xerces and Xalan in the TOMCAT/common/endorsed directory did not solve the issue for me. If I deploy my service as a standalone service embedded in Jetty, (generated via wsdl2java -server)it works, but when I configure it for WAR deployment in Tomcat-5.5, the client (generated via wsdl2java -client) throws the exception shown below. Also when deployed in standalone mode I can retrieve the WSDL via HTTP GET, but when depoyed as a WAR in Tomcat, I just get a 404 error. When I used the TCP/IP Monitor (Eclipse plugin similar to tcpmon) I see the that Client is sending the expected SOAP envelope, but is getting nothing back, however, with HTTP 301 or 302 response codes. I double checked my proxy settings in Eclipse and browser and have verified that both localhost and the canonical hostname are excluded from proxying. I tried both localhost and the canonical hostname in the request. (overriding via BindingProvider.ENDPOINT_ADDRESS_PROPERTY) Any help would be greatly appreciated. -Chris Mar 9, 2008 6:00:44 PM org.apache.cxf.phase.PhaseInterceptorChain doIntercept INFO: Interceptor has thrown exception, unwinding now org.apache.cxf.binding.soap.SoapFault: Error reading XMLStreamReader. at org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMes sage(ReadHeadersInterceptor.java:191) [...] at com.ms.cis.secadmin.services.SecAdmin_Secadmin_Client.main(SecAdmin_Seca dmin_Client.java:60) Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,1] Message: Premature end of file. at com.sun.xml.stream.XMLReaderImpl.next(XMLReaderImpl.java:563) at com.sun.xml.stream.XMLReaderImpl.nextTag(XMLReaderImpl.java:1177) at org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMes sage(ReadHeadersInterceptor.java:85) ... 15 more 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.
AccessControlException: access denied upon deploying to Tomcat-5.5
I built the wsdl_first sample and attempted to depoy the war to Tomcat-5.5. The tomcat manager shows that the web app is deployed and in the running state, however, neither the service nor even the WSDL urls produce results. (get a not found error) The log shows the following error: 2008-01-18 11:19:50,807 - Servlet /hw/webapp threw load() exception java.security.AccessControlException: access denied (javax.xml.ws.WebServicePermission publishEndpoint) at java.security.AccessControlContext.checkPermission(AccessControlContext. java:323) at java.security.AccessController.checkPermission(AccessController.java:546 ) [...] I read the readme's and FAQs and did a web search for this and only came up with two other hits of similar problems, but without a solution: http://forum.java.sun.com/thread.jspa?threadID=5166767messageID=9638582 http://bugs.caucho.com/view.php?id=2270 The question is, am I supposed to make some sort of configuration adjustment? How do I deploy and run the wsdl_first sample war in Tomcat-5.5? Full stack trace follows: 2008-01-18 11:19:50,807 - Servlet /hw/webapp threw load() exception java.security.AccessControlException: access denied (javax.xml.ws.WebServicePermission publishEndpoint) at java.security.AccessControlContext.checkPermission(AccessControlContext. java:323) at java.security.AccessController.checkPermission(AccessController.java:546 ) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at org.apache.cxf.jaxws.EndpointImpl.checkPublishPermission(EndpointImpl.ja va:333) at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:225) at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:179) at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:340) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac tory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1214 ) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac tory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1179) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac tory.initializeBean(AbstractAutowireCapableBeanFactory.java:1145) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac tory.createBean(AbstractAutowireCapableBeanFactory.java:427) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObjec t(AbstractBeanFactory.java:251) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.g etSingleton(DefaultSingletonBeanRegistry.java:144) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Ab stractBeanFactory.java:248) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Ab stractBeanFactory.java:160) at org.springframework.beans.factory.support.DefaultListableBeanFactory.pre InstantiateSingletons(DefaultListableBeanFactory.java:279) at org.springframework.context.support.AbstractApplicationContext.refresh(A bstractApplicationContext.java:360) at org.apache.cxf.transport.servlet.CXFServlet.loadAdditionalConfig(CXFServ let.java:203) at org.apache.cxf.transport.servlet.CXFServlet.loadSpringBus(CXFServlet.jav a:171) at org.apache.cxf.transport.servlet.CXFServlet.init(CXFServlet.java:98) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:243) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:517) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:275) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.jav a:161) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.jav a:114) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.jav a:1099) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932) 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.
Cannot get a java-first service to properly return collection of objects
I am trying to create a service which returns an array of objects. The only success I had was returning ListMapString, String and using Aegis data binding, but that's not really what I want. The contrived example is returning a collection of Quote objects. Quote has two String fields and a Date field. I tried declaring my method in the following ways: ListQuote getQuotes(String symbol); Quote [] getQuotes(String symbol); Either way, when the client gets the collection of quote objects, only one of String fields is populated, the other String and Date fields are null, but at least the correct number of Quote objects is returned. I tried with and without Aegis data binding - same result. Looking at the generated wsdl confirms that it thinks that Quote only has the one String field. The closest help I have found on the lists is here: http://www.nabble.com/Returning-Generic-Lists-Properly-Typed--tf4162937. html#a11844844 http://www.nabble.com/Returning-Generic-Lists-Properly-Typed--tf4162937. html#a11844844 These suggestions are either too vague or don't apply to my case. I am glad that all the samples work out of the box returning a simple String, but I recommend at least one real-world sample that returns an array or List of objects. Note that for my immediate requirement, I want to do java-first, not wsdl-first, so I would not consider starting with a wsdl file to be helpful, even though I'm sure that would work. Any help would be greatly appreciated. Regards, Chris Wolf 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.
