WebServiceContext not injected in endpoint
trying customizing the JAxWSMethodInvoker I have problems injecting the web
service context with the @Resource annotation.
Maybe there's something wrong in what I am doing, maybe it could be a bug.
Assume you have a GreeterImpl endpoint with the web service context
injected.
Try the following:
case 1
ScopePolicy policy = ApplicationScopePolicy.instance();
// trying with the following is the same:
// ScopePolicy policy = RequestScopePolicy.instance();
org.apache.cxf.common.util.factory.Factory factory= new
LocalFactory(GreeterImpl.class);
JAXWSMethodInvoker invoker = new JAXWSMethodInvoker(fattorazza, policy);
JaxWsServerFactoryBean factoryBean = new JaxWsServerFactoryBean();
factoryBean.setAddress(address);
factoryBean.setServiceBean(implementor);
factoryBean.setInvoker(invoker);
factoryBean.create();
case 2
Endpoint.publish(address,implementor);
the endpoint
public class GreeterImpl implements Greeter {
@Resource
private WebServiceContext context;
public java.lang.String greetMe(java.lang.String requestType) {
if (context != null) {
// in case 1 it is null, in case 2 it is !=null
}
return hello + requestType;
}
in case 1 the method invocation works fine, but the context is not injected,
while in case 2 the context is injected.
where is the fault?
Davide
--
View this message in context:
http://www.nabble.com/WebServiceContext-not-injected-in-endpoint-tp15708465p15708465.html
Sent from the cxf-user mailing list archive at Nabble.com.
WebServiceContext Principal
According to the javadoc of WebServiceContext class, getUserPrincipal() Returns the Principal that identifies the sender of the request currently being serviced. If the sender has not been authenticated, the method returns null. how is supposed to be filled this Principal? When? By whom? -- View this message in context: http://www.nabble.com/WebServiceContext-Principal-tp15708867p15708867.html Sent from the cxf-user mailing list archive at Nabble.com.
CXF Proxy and WS-Security
Is it possible with CXF to use single Proxy and be able to set the user for UsernameToken before each invocation and be thread safe? All examples I've seen so far sets the user on the interceptor once per proxy. Can I specify callback for username, similar to the password?
maintain'g session problem
Hi ,
I am new to cxf . My services are successfully exposed and i wrote
the client stubs to communicate with my services .currently i am stuck
up with one problem and i am looking for some pointers on this.
I would like check the authentication of the user before using my
services. I have list of valid user details in my db.
whenever User trying to use my services , I want to check the
authentication. for this purpuse i am calling a method internally when
ever the user invoke my service and binding the username password and
setting it in to the httpSession (please refer the below code). i hope
that now u understand the problem, when ever i am trying to get the
values from the session it is giving null values.because it is creating
the new session for every request. please help me to avoid this. I know
in axis we can give maintainsession(true) to avoid this.
(IN my Serviceimpl class)
@Resource
WebServiceContext wsc;
@WebMethod
public void isValidUser(String username, String password) {
MessageContext context=wsc.getMessageContext();
HttpServletRequest
request=(HttpServletRequest)context.get(MessageContext.SERVLET_REQUEST);
/*
here i am calling some method to check the authentication and
after puting some flag value in session.
*/
}
@WebMethod
public void getMySerivce(String str){
HttpServletRequest
request=(HttpServletRequest)wsc.getMessageContext().get(MessageContext.SERVLET_REQUEST);
boolean value=request.getSession().getAttribute(MYFLAG);//
getting null. because here i am getting new session instance.
}
thanks,
prakeshkt
Re: maintain'g session problem
prakesh kt wrote: when ever i am trying to get the values from the session it is giving null values.because it is creating the new session for every request. please help me to avoid this. I know in axis we can give maintainsession(true) to avoid this. ((BindingProvider)clientStub).getRequestContext().put( BindingProvider.SESSION_MAINTAIN_PROPERTY, Boolean.TRUE); I got this from a Metro blog entry but it's a JAX-WS thing, not specific to Metro, and it works for me with CXF. Ian -- Ian Roberts | Department of Computer Science [EMAIL PROTECTED] | University of Sheffield, UK
Re: maintain'g session problem
Thank u, it is working for me . -- Sent using goWebtop from Laszlo Systems. Try it yourself : http://www.gowebtop.com On Wed, Feb 27, 2008 at 5:55 PM, Ian Roberts wrote: prakesh kt wrote: when ever i am trying to get the values from the session it is giving null values.because it is creating the new session for every request. please help me to avoid this. I know in axis we can give maintainsession(true) to avoid this. ((BindingProvider)clientStub).getRequestContext().put( BindingProvider.SESSION_MAINTAIN_PROPERTY, Boolean.TRUE); I got this from a Metro blog entry but it's a JAX-WS thing, not specific to Metro, and it works for me with CXF. Ian -- Ian Roberts | Department of Computer Science [EMAIL PROTECTED] | University of Sheffield, UK
Re: WebServiceContext not injected in endpoint
This is one of the many issues with the ScopePolicy/factory stuff which
is one of the reasons I eliminated the ScopePolicy stuff entirely from
the 2.1/trunk codebase. :-)
Is there any chance you could give the 2.1 snapshots a try? Configuring
your usecase will be SLIGHTLY different, but not by much:
org.apache.cxf.service.invoker.Factory factory = new
org.apache.cxf.service.invoker.PerRequestFactory(GreeterImpl.class);
JAXWSMethodInvoker invoker = new JAXWSMethodInvoker(factory);
.
The newer Factory stuff, since it has access to the exchange at request
time, can get the bus and thus get the resources properly injected.
That said, the resource injection isn't free so that will add a small
amount of extra processing per request. Thus, you might want to use
the PooledFactory to maintain a pool of GreeterImpl objects or possibly
a SessionFactory to create one per session (assuming your clients honor
the session).
In anycase, with the 2.1 code the major bugs should be fixed and I'd LOVE
to see someone else test it a bit to makre sure. Basically, resources
should get injected and the pooled stuff should actually work.
Dan
On Wednesday 27 February 2008, Davide Gesino wrote:
trying customizing the JAxWSMethodInvoker I have problems injecting
the web service context with the @Resource annotation.
Maybe there's something wrong in what I am doing, maybe it could be a
bug.
Assume you have a GreeterImpl endpoint with the web service context
injected.
Try the following:
case 1
ScopePolicy policy = ApplicationScopePolicy.instance();
// trying with the following is the same:
// ScopePolicy policy = RequestScopePolicy.instance();
org.apache.cxf.common.util.factory.Factory factory= new
LocalFactory(GreeterImpl.class);
JAXWSMethodInvoker invoker = new JAXWSMethodInvoker(fattorazza,
policy);
JaxWsServerFactoryBean factoryBean = new JaxWsServerFactoryBean();
factoryBean.setAddress(address);
factoryBean.setServiceBean(implementor);
factoryBean.setInvoker(invoker);
factoryBean.create();
case 2
Endpoint.publish(address,implementor);
the endpoint
public class GreeterImpl implements Greeter {
@Resource
private WebServiceContext context;
public java.lang.String greetMe(java.lang.String requestType) {
if (context != null) {
// in case 1 it is null, in case 2 it is !=null
}
return hello + requestType;
}
in case 1 the method invocation works fine, but the context is not
injected, while in case 2 the context is injected.
where is the fault?
Davide
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
Re: WebServiceContext Principal
On Wednesday 27 February 2008, Davide Gesino wrote: According to the javadoc of WebServiceContext class, getUserPrincipal() Returns the Principal that identifies the sender of the request currently being serviced. If the sender has not been authenticated, the method returns null. how is supposed to be filled this Principal? When? By whom? Well, that's kind of application specific. When running inside a servlet engine and using the CXFServlet, the CXFServlet provides an implementation that makes the getUserPrincipal() call back onto the same method of the current HttpServletRequest. Thus, it's filled in by tomcat from the information tomcat knows about. (like tomcat-users.xml in the tomcat conf directory along with information in the web.xml) HOWEVER, if you have some sort of custom CXF interceptor, you can create your own org.apache.cxf.security.SecurityContext object that does whatever custom thing you need and set that in the message and then the calls to the WebServiceContext getUserPrincipal stuff will go through that. Ideally, the ws-security stuff would also set a new SecurityContext or similar with the information it has. I'm not sure if it has a principal or role information right now or not. -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: CXF Proxy and WS-Security
On Tuesday 26 February 2008, Will Gomes wrote: Is it possible with CXF to use single Proxy and be able to set the user for UsernameToken before each invocation and be thread safe? All examples I've seen so far sets the user on the interceptor once per proxy. Can I specify callback for username, similar to the password? Unforunately, at this point, the answer is no due to spec compliance issues.You can read some of the discussion about it in JIRA: https://issues.apache.org/jira/browse/CXF-1410 We're kind of debating which direction to go: 1) A separate proprietary getThreadRequestContext() call on a proprietary interface. 2) A flag that would somehow flip the getRequestContext() call over to a thread safe variety. In either case, the behavoir would be proprietary to CXF as the spec (and TCK) more or less requires the non-thread safe behavior to be the default. :-( I'd be interesting in hearing your opinions on the matter. -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: CXF Proxy and WS-Security
Daniel Kulp wrote: On Tuesday 26 February 2008, Will Gomes wrote: Is it possible with CXF to use single Proxy and be able to set the user for UsernameToken before each invocation and be thread safe? All examples I've seen so far sets the user on the interceptor once per proxy. Can I specify callback for username, similar to the password? Unforunately, at this point, the answer is no due to spec compliance issues.You can read some of the discussion about it in JIRA: https://issues.apache.org/jira/browse/CXF-1410 We're kind of debating which direction to go: 1) A separate proprietary getThreadRequestContext() call on a proprietary interface. 2) A flag that would somehow flip the getRequestContext() call over to a thread safe variety. In either case, the behavoir would be proprietary to CXF as the spec (and TCK) more or less requires the non-thread safe behavior to be the default. :-( I'd be interesting in hearing your opinions on the matter. Second solution seems more portable. Could the WSS4JOutInterceptor be made to make a callback to a UsernameCallbackHandler to retreive the username and add to the message context? I assume the message is thread safe when in the InterceptorChain. Also, i'm not sure the purpose of having a password callback (aside from keeping passwords out of config/code) if there is no associated username callback handler.
RE: Does CXF Support Interfaces as Web Params?
Yes, I've used JAXB with interfaces and its painful but does work.
However, it appears from the code in JAXBUtils that CXF explicitly excludes
interfaces even if they are annotated to be properly marshaled by JAXB (as
per https://jaxb.dev.java.net/guide/Mapping_interfaces.html)
-Original Message-
From: jim ma [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 26, 2008 9:18 PM
To: cxf-user@incubator.apache.org
Subject: Re: Does CXF Support Interfaces as Web Params?
Kohsuke Kawaguchi's blog talked about this , you can get some information
from
this link:
http://weblogs.java.net/blog/kohsuke/archive/2006/06/jaxb_and_interf.html
On Wed, Feb 27, 2008 at 9:25 AM, Glen Mazza [EMAIL PROTECTED] wrote:
I think the answer is no, neither CXF nor GlassFish Metro support
interfaces as parameters. It's either a JAX-WS or JAXB rule, I'm not
certain.
Glen
Am Dienstag, den 26.02.2008, 15:07 -0800 schrieb Ayush Gupta:
In my web service, there is a method which takes an interface as its
parameter, instead of a concrete class. Reference code is at the bottom
of
this email.
When I run the client, I get an exception Caused by:
javax.xml.bind.JAXBException:
com.passenger.test.ComplexObjectInterfaceis
not known to this context. Further investigation and digging through
the
CXF code bought me to JAXBUtils. getValidClass(Class? cls) which is
called
while building the JAXBContext. The code in JAXBUtils. getValidClass
explicitly excludes inclusion of any interfaces! I also tried setting
the
XmlJavaTypeAdapter on the interface but that didn't work.
So, does CXF Support Interfaces as Web Params? I'd appreciate anyone
throwing some light on this!
Thanks
-ayush
Web Service Interface:
public interface TestServiceInterface {
public void testMethod(MyInterface param);
}
Parameter Interface:
public interface MyInterface{
String getText();
void setText(String t);
}
Parameter concrete class:
public class MyClass implements MyInterface {
private String text;
public String getText() {
return text;
}
public void setText(String t) {
this.text = t;
}
}
Client:
Service service = Service.create(SERVICE_NAME);
service.addPort(PORT_NAME, SOAPBinding.SOAP11HTTP_BINDING,
ENDPOINT_ADDRESS);
TestServiceInterface serviceInterface =
service.getPort(TestServiceInterface.class);
serviceInterface. testMethod(new MyClass());
CXF problem using extended class as Web Param
Hi all,
I'm implementing an unwrapped REST web service using HTTP Binding, deployed
on JBoss, using Spring.
In a specific method I need to use a class that's extending other as a web
parameter. Lets say:
The web service:
@Post
@HttpResource(location=/auth)
public String authenticate(@WebParam(name=AuthRequest) AuthRequest
request);
AuthRequest:
public class AuthRequest extends GenericRequest{
final static long serialVersionUID = 1L;
public AuthRequest() {
super();
}
public AuthRequest(Integer applicationId, String password, String
login) {
super(applicationId, password, login);
}
And GenericRequest..
public class GenericRequest implements Serializable {
public GenericRequest(){
}
public GenericRequest(Integer applicationId, String password, String
login)
{
super();
this.applicationId = applicationId;
this.password = password;
this.login = login;
}
private static final long serialVersionUID = 5037815176301473091L;
private Integer applicationId;
private String password;
private String login;
... and further setters and getters...
Wasn't this supposed to work??
I'm getting the following exception instead:
INFO: Interceptor has thrown exception, unwinding now
java.lang.NullPointerException
at
org.apache.cxf.binding.http.IriDecoderHelper.interopolateParams(IriDecoderHelper.java:306)
at
org.apache.cxf.binding.http.interceptor.URIParameterInInterceptor.mergeParams(URIParameterInInterceptor.java:122)
at
org.apache.cxf.binding.http.interceptor.URIParameterInInterceptor.handleMessage(URIParameterInInterceptor.java:103)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:78)
at
org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:92)
(...)
Thanks in advance,
Rui Ramos
--
View this message in context:
http://www.nabble.com/CXF-problem-using-extended-class-as-Web-Param-tp15721500p15721500.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: java2wsdl yeilds WSDL file that causes NullPointerException
On Tuesday 26 February 2008, Daniel Lipofsky wrote: OK, I solved this original problem but I have more questions: How do you control the soap location. Right now it is outputing soap:address location=http://localhost:9090/hello/ which is not correct. Hmm I don't see a way to do it with the 2.0.x java2wsdl tooling. With the 2.1 tooling, there is a -address flag that looks like it would be for that pupose. Also, can I override this programmatically in the client? That's the easy part. ((BindingProvider)proxy).getRequestContext().put( BindingProvider.ENDPOINT_ADDRESS_PROPERTY, http://blah/blah/blah;); Dan Thanks, Dan p.s. I solved it by removing package-info.java and also BasePortType.java and BaseService.java which were hanging around from when I generated things for the abstract class; I also removed a reference to targetNamespace=.../Base.wsdl that was hanging around in WSException.java. Not sure what really did it. -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Does CXF Support Interfaces as Web Params?
On Wednesday 27 February 2008, Ayush Gupta wrote:
Yes, I've used JAXB with interfaces and its painful but does work.
However, it appears from the code in JAXBUtils that CXF explicitly
excludes interfaces even if they are annotated to be properly
marshaled by JAXB (as per
https://jaxb.dev.java.net/guide/Mapping_interfaces.html)
Fixable I'll try to get that fixed tomorrow. :-)
Dan
-Original Message-
From: jim ma [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 26, 2008 9:18 PM
To: cxf-user@incubator.apache.org
Subject: Re: Does CXF Support Interfaces as Web Params?
Kohsuke Kawaguchi's blog talked about this , you can get some
information from
this link:
http://weblogs.java.net/blog/kohsuke/archive/2006/06/jaxb_and_interf.h
tml
On Wed, Feb 27, 2008 at 9:25 AM, Glen Mazza [EMAIL PROTECTED]
wrote:
I think the answer is no, neither CXF nor GlassFish Metro support
interfaces as parameters. It's either a JAX-WS or JAXB rule, I'm
not certain.
Glen
Am Dienstag, den 26.02.2008, 15:07 -0800 schrieb Ayush Gupta:
In my web service, there is a method which takes an interface as
its parameter, instead of a concrete class. Reference code is at
the bottom
of
this email.
When I run the client, I get an exception Caused by:
javax.xml.bind.JAXBException:
com.passenger.test.ComplexObjectInterfaceis
not known to this context. Further investigation and digging
through
the
CXF code bought me to JAXBUtils. getValidClass(Class? cls) which
is
called
while building the JAXBContext. The code in JAXBUtils.
getValidClass explicitly excludes inclusion of any interfaces! I
also tried setting
the
XmlJavaTypeAdapter on the interface but that didn't work.
So, does CXF Support Interfaces as Web Params? I'd appreciate
anyone throwing some light on this!
Thanks
-ayush
Web Service Interface:
public interface TestServiceInterface {
public void testMethod(MyInterface param);
}
Parameter Interface:
public interface MyInterface{
String getText();
void setText(String t);
}
Parameter concrete class:
public class MyClass implements MyInterface {
private String text;
public String getText() {
return text;
}
public void setText(String t) {
this.text = t;
}
}
Client:
Service service = Service.create(SERVICE_NAME);
service.addPort(PORT_NAME, SOAPBinding.SOAP11HTTP_BINDING,
ENDPOINT_ADDRESS);
TestServiceInterface serviceInterface =
service.getPort(TestServiceInterface.class);
serviceInterface. testMethod(new MyClass());
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
Re: Problem generating WSDL from Java API with CXF 2.0.3
This looks exactly like the issue in:
http://www.nabble.com/Does-CXF-Support-Interfaces-as-Web-Params--to15702272.html
I'll look at it more tonight or tomorrow.
Dan
On Wednesday 27 February 2008, Phil Weighill-Smith wrote:
Dan,
So we managed to get the new tool running, but we still have the same
problem. I've attached the full actual WSDL generated.
This is generated using the following snippet of Ant scripting:
target name=generate-remote-java2wsdl
depends=-make-output-dir java
classname=org.apache.cxf.tools.java2ws.JavaToWS fork=true arg
value=-wsdl/
arg value=-s/
arg
value=${product.dir}/user-module/built/output/generated/ arg
value=-o/
arg
value=${product.dir}/user-module/built/output/UserModule.wsdl/
arg
value=com.volantis.openapi.mss.usermodule.UserModule/ classpath
path refid=cxf.classpath/
/classpath
/java
/target
When executed we get the following output from Ant:
generate-remote-java2wsdl:
[java] log4j:WARN No appenders could be found for logger
(org.apache.cxf.bus.spring.BusApplicationContext). [java] log4j:WARN
Please initialize the log4j system properly. [java] Feb 27, 2008
2:06:35 PM org.apache.cxf.bus.spring.BusApplicationContext
getConfigResources [java] INFO: No cxf.xml configuration file
detected, relying on defaults. [java] Feb 27, 2008 2:06:37 PM
org.apache.cxf.service.factory.ReflectionServiceFactoryBean
buildServiceFromClass [java] INFO: Creating Service
{http://com.volantis.xmlns/2008/01/mss/user-module}UserModuleService
from class com.volantis.openapi.mss.usermodule.UserModule [java] Feb
27, 2008 2:06:38 PM
org.apache.cxf.service.factory.ReflectionServiceFactoryBean
buildServiceFromClass [java] INFO:
{http://com.volantis.xmlns/2008/01/mss/user-module}parameters part
type QName null. [java]
{http://com.volantis.xmlns/2008/01/mss/user-module}parameter part type
QName null. [java]
{http://com.volantis.xmlns/2008/01/mss/user-module}parameters part
type QName null. [java]
{http://com.volantis.xmlns/2008/01/mss/user-module}return part type
QName null. [java]
{http://com.volantis.xmlns/2008/01/mss/user-module}return part type
QName null. [java]
{http://com.volantis.xmlns/2008/01/mss/user-module}definition part
type QName null. [java]
{http://com.volantis.xmlns/2008/01/mss/user-module}parameter part type
QName null. [java]
{http://com.volantis.xmlns/2008/01/mss/user-module}return part type
QName null. [java]
{http://com.volantis.xmlns/2008/01/mss/user-module}return part type
QName null. [java]
{http://com.volantis.xmlns/2008/01/mss/user-module}parameters part
type QName null. [java]
{http://com.volantis.xmlns/2008/01/mss/user-module}return part type
QName null. [java]
{http://com.volantis.xmlns/2008/01/mss/user-module}preference part
type QName null. [java]
{http://com.volantis.xmlns/2008/01/mss/user-module}originalPreference
part type QName null. [java]
{http://com.volantis.xmlns/2008/01/mss/user-module}parameters part
type QName null.
I'm wondering if the QName null issues are the source of our problems,
and what they mean.
Here is the start of our SEI (with the first operation/method
included):
package com.volantis.openapi.mss.usermodule;
import com.volantis.openapi.mss.usermodule.jaxb.Adapters;
import java.util.List;
import javax.jws.WebParam;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.xml.datatype.Duration;
import javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter;
/**
* Provides access to the various operations that can be performed
against the * user module which forms part of the MSS API.
*
* ...
*/
@WebService(name = UserModule,
targetNamespace =
http://com.volantis.xmlns/2008/01/mss/user-module;)
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT,
use = SOAPBinding.Use.LITERAL,
parameterStyle = SOAPBinding.ParameterStyle.WRAPPED)
public interface UserModule {
/**
* Get the details of the specified user, with or without
extension * parameter and subscription details and potentially
updating the user's * last known device.
*
* @param applicationID the ID for the application
scope in * which the user exists.
Must not be * null
* @param userID the application-scope unique
ID for * the user to be retrieved.
Must not be * null
* @param device the DRWS device name for the
request * during which the user's
details are * to be retrieved. If
not null this may * be used to
update the user's last * known
device
* @param
upgrading from XFire - SSL handshake errors
Have the default cipher suites changed between XFire and CXF?
The reason I ask is that I am in the process of upgrading a XFire client to
CXF. The XFire client successfully uses a SOAP service over HTTPS. I didn't
do anything particular to get XFire working over HTTPS so presumably the
default cipher suites were used.
My first attempt at connecting to the same endpoint via my new CXF client
resulted in the following SSL handshake_failure:
INFO: The cipher suites have been set to SSL_RSA_WITH_DES_CBC_SHA,
SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA,
SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA,
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA,
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, SSL_RSA_WITH_NULL_MD5,
SSL_RSA_WITH_NULL_SHA, SSL_DH_anon_WITH_DES_CBC_SHA,
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5, SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA,
TLS_KRB5_WITH_DES_CBC_SHA, TLS_KRB5_WITH_DES_CBC_MD5,
TLS_KRB5_EXPORT_WITH_RC4_40_SHA, TLS_KRB5_EXPORT_WITH_RC4_40_MD5,
TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA, TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5.
%% No cached client session
*** ClientHello, SSLv3
RandomCookie: GMT: 1187298740 bytes = { 113, 45, 193, 158, 214, 231, 11,
225, 197, 38, 3, 179, 175, 26, 25, 234, 108, 241, 155, 106, 191, 62, 221,
65, 209, 8, 182, 48 }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA,
SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5,
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA,
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, SSL_RSA_WITH_NULL_MD5,
SSL_RSA_WITH_NULL_SHA, SSL_DH_anon_WITH_DES_CBC_SHA,
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5, SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA,
TLS_KRB5_WITH_DES_CBC_SHA, TLS_KRB5_WITH_DES_CBC_MD5,
TLS_KRB5_EXPORT_WITH_RC4_40_SHA, TLS_KRB5_EXPORT_WITH_RC4_40_MD5,
TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA, TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5]
Compression Methods: { 0 }
***
WRITE: SSLv3 Handshake, length = 79
WRITE: SSLv2 client hello message, length = 101
READ: SSLv3 Alert, length = 2
RECV TLSv1 ALERT: fatal, handshake_failure
called closeSocket()
handling exception: javax.net.ssl.SSLHandshakeException: Received fatal
alert: handshake_failure
Feb 27, 2008 2:49:08 PM org.apache.cxf.phase.PhaseInterceptorChain
doIntercept
INFO: Interceptor has thrown exception, unwinding now
org.apache.cxf.binding.soap.SoapFault: Error writing to XMLStreamWriter.
at
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.writeSoapEnvelopeStart(SoapOutInterceptor.java:136)
at
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:76)
at
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:57)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.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.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
at $Proxy48.localAuthenticationQuery(Unknown Source) ...
Caused by: javax.xml.stream.XMLStreamException
at
com.sun.xml.stream.writers.XMLStreamWriterImpl.writeStartElement(XMLStreamWriterImpl.java:1210)
at
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.writeSoapEnvelopeStart(SoapOutInterceptor.java:95)
... 16 more
After googling around for SSLv3 Alert, length = 2 I found that this can
occur when the server rejects the cipher suites given in the ClientHello
message. By running the working XFire client with
-Djavax.net.debug=ssl,handshake enabled I learned that the server was
choosing SSL_RSA_WITH_3DES_EDE_CBC_SHA as the cipher suite. Sure enough
this cipher suite isn't in the default cipher suites thay my CXF client was
picking up (list is above). Adding this to my CXF client resolved the
handshake issue:
TLSClientParameters tlsParams = new TLSClientParameters();
tlsParams.getCipherSuites().add(SSL_RSA_WITH_3DES_EDE_CBC_SHA);
conduit.setTlsClientParameters(tlsParams);
I'm all set now but this got me thinking about how my upgrade could have
been made much smoother had the default cipher suites remained the same. But
perhaps there is a good reason why they differ?
thanks,
-Travis
--
View this message in context:
http://www.nabble.com/upgrading-from-XFire---SSL-handshake-errors-tp15725238p15725238.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Does CXF Support Interfaces as Web Params?
On Wednesday 27 February 2008, Ayush Gupta wrote:
Yes, I've used JAXB with interfaces and its painful but does work.
However, it appears from the code in JAXBUtils that CXF explicitly
excludes interfaces even if they are annotated to be properly
marshaled by JAXB (as per
https://jaxb.dev.java.net/guide/Mapping_interfaces.html)
Actually, that code IS correct. I've been experimenting with this quite
a bit tonight and JAXB will barf if you try to create a context with any
class that is an interface, even if the interface has the
XmlJavaTypeAdapter annotation on it and such. Thus, that code is
correct. However, this also means that you cannot use interfaces
for top level things, only for stuff within actual concrete beans.
That said, I was pleasantly suprised when I wrote my test case that the
test actually worked with whats on the trunk today PROVIDING you have a
valid version of asm jar available AND you use wrapped doc/lit. With
the work I did two weeks ago, in the wrapped doc/lit case, it will use
ASM to buildup concrete beans in memory and the interface params get put
over just fine and they work. (This is on the 2.1 line only. Way to
complex to port back to 2.0.x.)
If you AREN'T using wrapped doc/lit or you don't have an asm jar
available, then there are issues. We have to drop down to JAXB
proprietary API's and types to get them to work. That's not going to
be easy and due to the extra book keeping, is going to be a performance
issue.In general, I strongly suggest the wrapped doc/lit with asm.
In anycase, I'm adding a sample of this to the java_first_jaxws sample to
kind of show it working. I'll start a new snapshot deploy before I
head to bed tonight so the 2.1 snapshots in the morning should have it.
I'd really appreciate it if folks could look at it and let me know how
to improve the sample to show some more of these complex scenarios. I
do admit most of our samples are very basic. This should be a step in
the right direction for providing something a bit more complex.
Dan
-Original Message-
From: jim ma [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 26, 2008 9:18 PM
To: cxf-user@incubator.apache.org
Subject: Re: Does CXF Support Interfaces as Web Params?
Kohsuke Kawaguchi's blog talked about this , you can get some
information from
this link:
http://weblogs.java.net/blog/kohsuke/archive/2006/06/jaxb_and_interf.h
tml
On Wed, Feb 27, 2008 at 9:25 AM, Glen Mazza [EMAIL PROTECTED]
wrote:
I think the answer is no, neither CXF nor GlassFish Metro support
interfaces as parameters. It's either a JAX-WS or JAXB rule, I'm
not certain.
Glen
Am Dienstag, den 26.02.2008, 15:07 -0800 schrieb Ayush Gupta:
In my web service, there is a method which takes an interface as
its parameter, instead of a concrete class. Reference code is at
the bottom
of
this email.
When I run the client, I get an exception Caused by:
javax.xml.bind.JAXBException:
com.passenger.test.ComplexObjectInterfaceis
not known to this context. Further investigation and digging
through
the
CXF code bought me to JAXBUtils. getValidClass(Class? cls) which
is
called
while building the JAXBContext. The code in JAXBUtils.
getValidClass explicitly excludes inclusion of any interfaces! I
also tried setting
the
XmlJavaTypeAdapter on the interface but that didn't work.
So, does CXF Support Interfaces as Web Params? I'd appreciate
anyone throwing some light on this!
Thanks
-ayush
Web Service Interface:
public interface TestServiceInterface {
public void testMethod(MyInterface param);
}
Parameter Interface:
public interface MyInterface{
String getText();
void setText(String t);
}
Parameter concrete class:
public class MyClass implements MyInterface {
private String text;
public String getText() {
return text;
}
public void setText(String t) {
this.text = t;
}
}
Client:
Service service = Service.create(SERVICE_NAME);
service.addPort(PORT_NAME, SOAPBinding.SOAP11HTTP_BINDING,
ENDPOINT_ADDRESS);
TestServiceInterface serviceInterface =
service.getPort(TestServiceInterface.class);
serviceInterface. testMethod(new MyClass());
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
Building cxf
I just downloaded the 2.04 sources. Trying to compile I get this error: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /Users/alleon/Documents/apache-cxf-2.0.4-incubator-src/maven-plugins/codegen-plugin/src/main/java/org/apache/cxf/maven_plugin/WSDL2JavaMojo.java:[37,33] package org.apache.maven.artifact does not exist /Users/alleon/Documents/apache-cxf-2.0.4-incubator-src/maven-plugins/codegen-plugin/src/main/java/org/apache/cxf/maven_plugin/WSDL2JavaMojo.java:[169,13] cannot find symbol symbol : class Artifact location: class org.apache.cxf.maven_plugin.WSDL2JavaMojo /Users/alleon/Documents/apache-cxf-2.0.4-incubator-src/maven-plugins/codegen-plugin/src/main/java/org/apache/cxf/maven_plugin/WSDL2JavaMojo.java:[169,52] cannot find symbol symbol : class Artifact location: class org.apache.cxf.maven_plugin.WSDL2JavaMojo Any idea on what I might be doing wrong ? I am running on a MacOS 10.4 machine -- Best Regards Guillaume PGP KeyID:C1A0A73F FingerPrint:A4A2 73C0 E7D4 6437 8185 D05E ECF2 AD84 C1A0 A73F http://cheztog.blogspot.com
