SSL Enabling CXF Clients + Spring + Factory methods

[Segal, Jeffrey]

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):
 

http://foo.service.com"/>


 

https://localhost:8443/services/foo?WSDL"/>


 
http://foo.service.com
 }FooServicePort.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:
 

 


https://localhost:8443/services/foo?WSDL
 "/
 >


 
http://foo.service.com
 }FooServicePort.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

[Segal, Jeffrey]

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:




1
















true



com.foo.bar.A
com.foo.bar.B
com.foo.bar.C






















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

[Segal, Jeffrey]

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

[Segal, Jeffrey]

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:
 

...



true



com.foo.bar.BigJob
com.foo.bar.SmallJob




...

 
This deploys without error, but my WSDL and corresponding stubs do not
include the overridden types.  Any ideas?
 
Thanks!
Jeff