On Friday 08 October 2010 10:21:16 am Benson Margulies wrote:
> Dan,
> 
> I've recently developed a fondness for Simple, and let me explain why,
> because I think you are going to tell me that I'm confused.
> 
> I don't ever want a client to read a WSDL from the server, or anywhere
> else. I am using CXF as a transport between a set of components that
> all belong to me, and are developed in sync, and do not need the extra
> time and complexity of WSDL machinations. I also don't even want to
> consume one neuron on worrying about proxy thread-safety.
> 
> My understanding is that JAX-WS reserves the right to screw me if I
> don't read the WSDL into the client endpoint, even if it *should*
> *usually* work. I don't like to be explaining those *'s to skeptical
> co-workers.

Well, this is an area where CXF and the JAX-WS RI diverge quite a bit.   The 
RI does require the WSDL, and I'm really not sure why.    CXF, on the other 
hand, is quite happy using "null" for the wsdl address and will work just 
fine.

If the INTERFACE is properly and completely annotated, the JAX-WS frontend is 
much less likely to screw you than the simple frontend.   Things like the 
"arg0" things coming from the interface or impl just don't happen.   

Honestly, I really cannot think of any case where the simple frontend is less 
likely to screw you than the JAX-WS frontend.  There are some cases that are a 
bit less controllable with JAX-WS (like making the params 
required/minOccurs=1) that can be done easier with Simple+Aegis,  but that 
COULD be done with JAX-WS as well with an additional 
AbstractServiceConfiguration thing.    (Or, with JAXB 2.2, you can add 
@XmlElement(required=true) to the parameters along with the @WebParam, but 
that would be for JAXB databinding)


> I also don't even want to
> consume one neuron on worrying about proxy thread-safety.

Since the request context is on the ClientImpl that is the same for simple and 
jaxws, this issue would be identical.


Dan


> If, in fact, the spec for JAX-WS legitimizes my simple case, I'd much
> prefer to be configuring with snails and using JAX-WS+Aegis.
> 
> --benson
> 
> On Fri, Oct 8, 2010 at 10:13 AM, Daniel Kulp <dk...@apache.org> wrote:
> > On Wednesday 06 October 2010 7:52:52 am Benson Margulies wrote:
> >> I found myself explaining the 'interfaces don't carry param names'
> >> business to a coworker the other day. Thinking about it, I realized
> >> that there's still a pretty good trap hiding in all this, and I'm
> >> wondering if we should do something about it.
> >> 
> >> Here's my theoretical trap. Unsuspecting Java-first implementor has
> >> options set to compile Java with debug info, so there are parameter
> >> names in their interfaces.
> >> 
> >> Some day, some evil build engineer comes along and removes the symbols
> >> from the production build. Oops, new WSDL.
> >> 
> >> It seems to me that it would be better if the factories accepted a
> >> boolean that instructed them to ignore the param names in interfaces,
> >> so as to produce repeatable results regardless of the compile options.
> >> 
> >> Presumably, this isn't in the JAX-WS spec, but we could do it for
> >> Simple.
> > 
> > The simple frontend really needs a ConfigurableServiceConfiguration
> > object or similar that provides a bunch of configuration points.   The
> > one-way issue is another one.   It could have a
> > "setOneWays(List<String>) or similar for the list of one-way methods,
> > the flag you mention above, etc....   Maybe a
> > "setMethodParamNames(Map<String, List<String>)" type things to allow
> > people to configure in custome parameter names.
> > 
> > That said, I'm increasingly been wondering why people still use the
> > simple frontend.  :-)   I think the JAX-WS frontend handles everything
> > the simple frontend handles.   (aegis vs jaxb is a different issue)  
> >  But the JAX-WS frontend is WAY more controllable from within the code
> > via annotations.
> > 
> > --
> > Daniel Kulp
> > dk...@apache.org
> > http://dankulp.com/blog

-- 
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog

Reply via email to