SSL Enabling CXF Clients + Spring + Factory methods
Hello CXFers,
I need to SSL enable some CXF services and client code that uses said
services. I found examples in the CXF sample area of SSL enabling a
client in code, but that's not really viable in an enterprise solution.
Doing some backward engineering of the code sample, I created the
following Spring configuration that did actually work (i.e., I was able
to successfully invoke methods over SSL):
bean id=fooServiceQName class=javax.xml.namespace.QName
constructor-arg value=http://foo.service.com/
constructor-arg value=FooService/
/bean
bean id=fooService class=com.service.Foo scope=prototype
constructor-arg
value=https://localhost:8443/services/foo?WSDL/
constructor-arg ref=fooServiceQName/
/bean
http:conduit name={http://foo.service.com
http://foo.service.com/ }FooServicePort.http-conduit
http:tlsClientParameters secureSocketProtocol=TLS/
/http:conduit
Unfortunately, this is pretty ugly and also requires that the service be
available at the time the XML config file is loaded, or creation of the
fooService bean will fail. There are of course work-arounds to that,
but they get ugly and unwieldy quickly. The surprising thing (and the
ultimate source of the problem) is that the following configuration will
NOT work:
bean id=fooServiceClient class=com.service.Foo
factory-bean=fooServiceClientFactory
factory-method=create/
bean id=fooServiceClientFactory
class=org.apache.cxf.jaxws.JaxWsProxyFactoryBean
property name=serviceClass value=com.service.Foo/
property name=address
value=https://localhost:8443/services/foo?WSDL
https://localhost:8443/services/foo?WSDL/ /
https://localhost:8443/sushi-services/services/AdministrationService?WS
DL/
/bean
http:conduit name={http://foo.service.com
http://foo.service.com/ }FooServicePort.http-conduit
http:tlsClientParameters secureSocketProtocol=TLS/
/http:conduit
Instead, this error occurs: java.io.IOException: Illegal Protocol https
for HTTP URLConnection Factory. Clearly, the HTTP Conduit is being
ignored. However, it brings up the greater question of why such a
theoretically simple configuration change is so difficult. With a large
set of services, it can become quite tedious to make sure all of the
Conduit names match perfectly with the template laid out at the bottom
of the Configuring SSL Support section at
http://cwiki.apache.org/confluence/display/CXF20DOC/Client+HTTP+Transpor
t.
Or am I doing something wrong here? Please let me know if that is the
case or this is just a chunk of functionality that does not yet exist.
Thanks!
Jeff
RE: Java first: Binding classes not exposed in service APIs
Update: I have verified that this is in fact supported by CXF, just not well documented yet. Here is my Spring configuration, which changes the default nillable and minOccurs settings to avoid stubs which wrap every Object with JAXBElement: bean id=typeMappingRegistryConfiguration class=org.apache.cxf.aegis.type.Configuration property name=defaultMinOccurs value1/value /property property name=defaultNillable value=false/ /bean bean id=typeMappingRegistry class=org.apache.cxf.aegis.type.DefaultTypeMappingRegistry property name=configuration ref=typeMappingRegistryConfiguration/ /bean bean id=aegisBean class=org.apache.cxf.aegis.databinding.AegisDatabinding property name=typeMappingRegistry ref=typeMappingRegistry/ /bean bean id=jaxws-and-aegis-service-factory class=org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean property name=properties map entry key=writeXsiType value type=java.lang.Booleantrue/value /entry entry key=overrideTypesList list valuecom.foo.bar.A/value valuecom.foo.bar.B/value valuecom.foo.bar.C/value /list /entry /map /property property name=dataBinding ref=aegisBean/ property name=serviceConfigurations list bean class=org.apache.cxf.jaxws.support.JaxWsServiceConfiguration/ bean class=org.apache.cxf.aegis.databinding.AegisServiceConfiguration/ bean class=org.apache.cxf.service.factory.DefaultServiceConfiguration/ /list /property /bean jaxws:endpoint id=fooService implementor=#myFooServiceBean implementorClass=com.service.foo.impl address=/foo jaxws:serviceFactory ref bean=jaxws-and-aegis-service-factory/ /jaxws:serviceFactory /jaxws:endpoint This all works as advertised, which is great. However, there are two features that appear to be lacking. First, let's say class A (referenced in the overrideTypesList above) has an enum property. CXF will correctly convert it to an XML enumeration. However, when creating stubs, the following error occurs: WSDLToJava Error : Thrown by JAXB : undefined simple or complex type 'ns3:SomeEnumType' Am I right to assume that CXF does not fully support Java 5 enums? Second, let's say class A has properties of types D, E and F. If class A was referenced in a service API (e.g., com.foo.bar.A getA(int id)), CXF is smart enough to bind D, E and F to XML in the resultant WSDL. However, if class A is only added to the WSDL via the overrideTypesList, classes D, E and F must also be manually added. If D, E and F in turn each have 3 more POJOs of their own, one can see how calling out each dependency out gets very unwieldy. I think these two features would be a great addition to CXF's capabilities. Thoughts? Cheers, Jeff -Original Message- From: Segal, Jeffrey [mailto:[EMAIL PROTECTED] Sent: Monday, November 05, 2007 6:30 PM To: cxf-user@incubator.apache.org Subject: Java first: Binding classes not exposed in service APIs I asked a smiliar question a few days ago referencing binding subclasses with Aegis (http://www.nabble.com/Migrating-XFire-Aegis-inheritance-to-CXF-tf473390 3.html), but I wanted to follow up on the subject and ask a more general question. Is binding arbitrary classes (i.e. those that are not necessarily exposed in a service interface) supported in CXF? If so, how is this done using JAXB? What would the Spring configuration look like? Thanks! Jeff
Java first: Binding classes not exposed in service APIs
I asked a smiliar question a few days ago referencing binding subclasses with Aegis (http://www.nabble.com/Migrating-XFire-Aegis-inheritance-to-CXF-tf473390 3.html), but I wanted to follow up on the subject and ask a more general question. Is binding arbitrary classes (i.e. those that are not necessarily exposed in a service interface) supported in CXF? If so, how is this done using JAXB? What would the Spring configuration look like? Thanks! Jeff
Migrating XFire/Aegis inheritance to CXF
I'd like to bump the question posed a few weeks ago by Nalyd (see
http://www.nabble.com/Aegis-inheritance-tf4668138.html#a13335122).
I am attempting to ensure that some additional classes which are not
present in my service interfaces get bound along with the others, a
common problem given a service such as:
public void queue(Job job);
where there exists the following classes:
public class BigJob extends Job { ... }
public class SmallJob extends Job {...}
In this case, Job will be bound to XML elements, but BigJob and SmallJob
will not. XFire does support this, documented at
http://xfire.codehaus.org/Aegis+Inheritance. However, I cannot find a
similar piece of documentation on porting this solution to CXF. It
seems as if the support is all still there but not necessarily exposed
(see http://cwiki.apache.org/CXF20DOC/aegis-theory-of-operation.html).
I have played around with a few things in my Spring configuration, such
as adding something like this to my ServiceFactoryBean:
bean id='jaxws-and-aegis-service-factory'
class=org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean
...
property name=properties
map
entry key=writeXsiType
value type=java.lang.Booleantrue/value
/entry
entry key=overrideTypesList
list
valuecom.foo.bar.BigJob/value
valuecom.foo.bar.SmallJob/value
/list
/entry
/map
/property
...
/bean
This deploys without error, but my WSDL and corresponding stubs do not
include the overridden types. Any ideas?
Thanks!
Jeff
