cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From conflue...@apache.org
Subject [CONF] Apache CXF > FAQ
Date Thu, 02 Jun 2011 13:51:00 GMT
<html>
<head>
    <base href="https://cwiki.apache.org/confluence">
            <link rel="stylesheet" href="/confluence/s/2042/9/15/_/styles/combined.css?spaceKey=CXF&amp;forWysiwyg=true"
type="text/css">
    </head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
    <h2><a href="https://cwiki.apache.org/confluence/display/CXF/FAQ">FAQ</a></h2>
    <h4>Page <b>edited</b> by             <a href="https://cwiki.apache.org/confluence/display/~dkulp">Daniel
Kulp</a>
    </h4>
        <br/>
                         <h4>Changes (1)</h4>
                                 
    
<div id="page-diffs">
                    <table class="diff" cellpadding="0" cellspacing="0">
    
            <tr><td class="diff-snipped" >...<br></td></tr>
            <tr><td class="diff-unchanged" >and future calls to getRequestContext()
will use a thread local request context.   That allows the request context to be threadsafe.
  (Note: the response context is always thread local in CXF) <br> <br></td></tr>
            <tr><td class="diff-changed-lines" >* Settings on the conduit - if
you use code or configuration to directly manipulate the conduit (like to set TLS settings
or similar), those are not thread safe.   The conduit is per-instance and thus those settings
would be shared. <span class="diff-added-words"style="background-color: #dfd;">  Also,
if you use the FailoverFeature and LoadBalanceFeatures, the conduit is replaced on the fly.
  Thus, settings set on the conduit could get lost before being used on the setting thread.</span>
<br></td></tr>
            <tr><td class="diff-unchanged" > <br>* Session support - if
you turn on sessions support (see jaxws spec), the session cookie is stored in the conduit.
 Thus, it would fall into the above rules on conduit settings and thus be shared across threads.
<br></td></tr>
            <tr><td class="diff-snipped" >...<br></td></tr>
    
            </table>
    </div>                            <h4>Full Content</h4>
                    <div class="notificationGreySide">
        <h1><a name="FAQ-FrequentlyAskedQuestions"></a>Frequently Asked
Questions</h1>

<div>
<ul>
    <li><a href='#FAQ-General'>General</a></li>
<ul>
    <li><a href='#FAQ-CanCXFrunwithJDK1.6%3F'>Can CXF run with JDK 1.6?</a></li>
    <li><a href='#FAQ-CanCXFrunwithJDK1.5%3F'>Can CXF run with JDK 1.5?</a></li>
    <li><a href='#FAQ-CanCXFrunwithJDK1.4%3F'>Can CXF run with JDK 1.4?</a></li>
    <li><a href='#FAQ-CanCXFrunwithouttheSunreferenceSAAJimplementation%3F'>Can
CXF run without the Sun reference SAAJ implementation?</a></li>
    <li><a href='#FAQ-AretherecommercialofferingsofCXFthatprovideservices%2Csupport%2Candadditionalfeatures%3F'>Are
there commercial offerings of CXF that provide services, support, and additional features?</a></li>
    <li><a href='#FAQ-IsthereanApacheCXFcertificationprogram%3F'>Is there an Apache
CXF certification program?</a></li>
</ul>
    <li><a href='#FAQ-JAXWSRelated'>JAX-WS Related</a></li>
<ul>
    <li><a href='#FAQ-Thepartsinmygeneratedwsdlhavenamesoftheform%22arg0%22%2C%22arg1%22%2C...Whydon%27ttheparts%28andJavageneratedfromthem%29usetheniceparameternamesItypedintotheinterfacedefinition%3F'>The
parts in my generated wsdl have names of the form "arg0", "arg1", ... Why don't the parts
(and Java generated from them) use the nice parameter names I typed into the interface definition?</a></li>
    <li><a href='#FAQ-HowcanIaddsoapheaderstotherequest%2Fresponse%3F'>How can
I add soap headers to the request/response?</a></li>
    <li><a href='#FAQ-HowcanIturnonschemavalidationforjaxwsendpoint%3F'>How can
I turn on schema validation for jaxws endpoint?</a></li>
    <li><a href='#FAQ-AreJAXWSclientproxiesthreadsafe%3F'>Are JAX-WS client proxies
thread safe?</a></li>
</ul>
    <li><a href='#FAQ-SpringRelated'>Spring Related</a></li>
<ul>
    <li><a href='#FAQ-WhenusingSpringAOPtoenablethingsliketransactionsandsecurity%2CthegeneratedWSDLisverymessedupwithwrongnamespaces%2Cpartnames%2Cetc...'>When
using Spring AOP to enable things like transactions and security, the generated WSDL is very
messed up with wrong namespaces, part names, etc...</a></li>
</ul>
</ul></div>


<h2><a name="FAQ-General"></a>General</h2>

<h3><a name="FAQ-CanCXFrunwithJDK1.6%3F"></a>Can CXF run with JDK 1.6?</h3>

<p>JDK 1.6 incorporates the JAXB reference implementation. However, it incorporates
an old version of the RI. CXF does not support this version. As of 1.6_04, this is easy to
deal with: you must put the versions of JAXB RI (the 'impl' and 'xjc' jars) that we include
with CXF in your classpath. As of this writing, these are version 2.2.1.</p>

<h3><a name="FAQ-CanCXFrunwithJDK1.5%3F"></a>Can CXF run with JDK 1.5?</h3>

<p>Yes.  Keep in mind though that Java 2 SE 5.0 with JDK 1.5 has reached end of life
(<a href="http://www.oracle.com/technetwork/java/eol-135779.html" class="external-link"
rel="nofollow">EOL</a>).</p>

<h3><a name="FAQ-CanCXFrunwithJDK1.4%3F"></a>Can CXF run with JDK 1.4?</h3>

<p>No. Many of the technologies that CXF is based on require JDK 1.5. JAX-WS, JAXB,
etc. all require JDK 1.5 features such as generics and annotations. Note that J2SE 1.4 with
JDK 1.4 has reached end of life (<a href="http://www.oracle.com/technetwork/java/eol-135779.html"
class="external-link" rel="nofollow">EOL</a>).</p>

<h3><a name="FAQ-CanCXFrunwithouttheSunreferenceSAAJimplementation%3F"></a>Can
CXF run without the Sun reference SAAJ implementation?</h3>

<p>In many cases, CXF can run without an SAAJ implementation.   However, some features
such as JAX-WS handlers and WS-Security do require an SAAJ implementation.  By default, CXF
ships with the Sun SAAJ implementation, but CXF also supports axis2-saaj version 1.4.1 as
an alternative. When using a Java6 JRE, CXF can also use the SAAJ implementation built into
Java.</p>


<h3><a name="FAQ-AretherecommercialofferingsofCXFthatprovideservices%2Csupport%2Candadditionalfeatures%3F"></a>Are
there commercial offerings of CXF that provide services, support, and additional features?</h3>

<p>Several companies provide services, training, documentation, support, etc... on top
of CXF.   Some of those companies also produce products that are either based on Apache CXF
or include Apache CXF.   See the <a href="/confluence/display/CXF/Commercial+CXF+Offerings"
title="Commercial CXF Offerings">Commercial CXF Offerings</a> page for a list of
companies and the services they provide.</p>


<h3><a name="FAQ-IsthereanApacheCXFcertificationprogram%3F"></a>Is there
an Apache CXF certification program?</h3>
<p>No, but Oracle's <a href="http://education.oracle.com/pls/web_prod-plq-dad/db_pages.getpage?page_id=41&amp;p_exam_id=1Z0_862"
class="external-link" rel="nofollow">SCDJWS</a> certification covers the web services
stack and related areas.  Note, that the popular SCJP certification is a prerequisite to the
SCDJWS.  Also, check out the <a href="http://www.coderanch.com/forums/f-80/java-Web-Services-SCDJWS"
class="external-link" rel="nofollow">SCDJWS Forum</a> at the Java Ranch for healthy
discussions in regards to the certification. Study notes can be found at <a href="http://java.boot.by/scdjws5-guide/"
class="external-link" rel="nofollow">SCDJWS 5.0 Study Guide</a>, <a href="http://en.wikibooks.org/wiki/Sun_Certified_Web_Services_Developer_Certification"
class="external-link" rel="nofollow">WikiBooks</a> and <a href="http://www.coderanch.com/how-to/content/Exam-Objectives-5.pdf"
class="external-link" rel="nofollow">Ivan A. Krizsan Study Notes</a>.  Java Ranch
also provides and information <a href="http://www.coderanch.com/how-to/java/ScdjwsLinks"
class="external-link" rel="nofollow">page</a> in regards to the certification.</p>

<h2><a name="FAQ-JAXWSRelated"></a>JAX-WS Related</h2>

<h3><a name="FAQ-Thepartsinmygeneratedwsdlhavenamesoftheform%22arg0%22%2C%22arg1%22%2C...Whydon%27ttheparts%28andJavageneratedfromthem%29usetheniceparameternamesItypedintotheinterfacedefinition%3F"></a>The
parts in my generated wsdl have names  of the form "arg0", "arg1", ...  Why don't the parts
(and Java generated from them) use the nice parameter names I typed into the interface definition?</h3>

<p><b>Official answer:</b>  The JAX-WS spec (specifically section 3.6.1)
mandates that it be generated this way.   To customize the name, you have to use an @WebParam(name
= "blah") annotation to specify better names. (You can use @WebResult for the return value,
but you'll only see the results if you look at the XML.)</p>

<p><b>Reason:</b> One of the mysteries of java is that abstract methods
(and thus interface methods) do NOT get their parameter names compiled into them even with
debug info. Thus, when the service model is built from an interface, there is no way to determine
the names that were using in the original code. </p>

<p>If the service is built from a concrete class (instead of an interface) AND the class
was compiled with debug info, we can get the parameter names. The simple frontend does this.
However, this could cause potential problems. For example, when you go from developement to
production, you may turn off debug information (remove -g from javac flags) and suddenly the
application may break since the generated wsdl (and thus expect soap messages) would change.
Thus, the JAX-WS spec writers went the safe route and mandate that you have to use the @WebParam
annotations to specify the more descriptive names.</p>

<h3><a name="FAQ-HowcanIaddsoapheaderstotherequest%2Fresponse%3F"></a>How
can I add soap headers to the request/response?</h3>

<p>There are several ways to do this depending on how your project is written (code
first or wsdl first) and requirements such as portability.</p>

<ol>
	<li>The "JAX-WS" standard way to do this is to write a SOAP Handler that will add the
headers to the SOAP message and register the handler on the client/server.   This is completely
portable from jax-ws vendor to vendor, but is also more difficult and can have performance
implications.   You have to handle the conversion of the JAXB objects to XML yourself.   It
involves having the entire soap message in a DOM which breaks streaming.  Requires more memory.
 etc...   However, it doesn't require any changes to wsdl or SEI interfaces.</li>
	<li>JAX-WS standard "java first" way: if doing java first development, you can just
add an extra parameter to the method and annotate it with @WebParam(header = true).   If it's
a response header, make it a Holder and add the mode = Mode.OUT to @WebParam.</li>
	<li>wsdl first way: you can add elements to the message in the wsdl and then mark them
as soap:headers in the soap:binding section of the wsdl.   The wsdl2java tool will generate
the @WebParam(header = true) annotations as above.   With CXF, you can also put the headers
in their own message (not the same message as the request/response) and mark them as headers
in the soap:binding, but you will need to pass the -exsh true flag to wsdl2java to get the
paramters generated.  This is not portable to  other jax-ws providers.  Processing headers
from other messages it optional in the jaxws spec.</li>
	<li>CXF proprietary way:  In the context (BindingProvider.getRequestContext() on client,
WebServiceContext on server), you can add a List&lt;org.apache.cxf.headers.Header&gt;
with the key Header.HEADER_LIST.   The headers in the list are streamed at the appropriate
time to the wire according to the databinding object found in the Header object.   Like option
1, this doesn't require changes to wsdl or method signatures.   However, it's much faster
as it doesn't break streaming and the memory overhead is less.</li>
</ol>


<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
List&lt;Header&gt; headers = <span class="code-keyword">new</span> ArrayList&lt;Header&gt;();
Header dummyHeader = <span class="code-keyword">new</span> Header(<span class="code-keyword">new</span>
QName(<span class="code-quote">"uri:org.apache.cxf"</span>, <span class="code-quote">"dummy"</span>),
<span class="code-quote">"decapitated"</span>,
                                <span class="code-keyword">new</span> JAXBDataBinding(<span
class="code-object">String</span>.class));
headers.add(dummyHeader);

<span class="code-comment">//server side:
</span>context.getMessageContext().put(Header.HEADER_LIST, headers);

<span class="code-comment">//client side:
</span>((BindingProvider)proxy).getRequestContext().put(Header.HEADER_LIST, headers);
</pre>
</div></div>

<h3><a name="FAQ-HowcanIturnonschemavalidationforjaxwsendpoint%3F"></a>How
can I turn on schema validation for jaxws endpoint?</h3>
<p>For the client side</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
    &lt;jaxws:client name=<span class="code-quote">"{http://apache.org/hello_world_soap_http}SoapPort"</span>
        createdFromAPI=<span class="code-quote">"true"</span>&gt;
        <span class="code-tag">&lt;jaxws:properties&gt;</span>
            <span class="code-tag">&lt;entry key=<span class="code-quote">"schema-validation-enabled"</span>
value=<span class="code-quote">"true"</span> /&gt;</span>
        <span class="code-tag">&lt;/jaxws:properties&gt;</span>
    <span class="code-tag">&lt;/jaxws:client&gt;</span>
</pre>
</div></div>

<p>You may also do this programmatically:</p>

<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
((BindingProvider)port).getRequestContext().put(<span class="code-quote">"schema-validation-enabled"</span>,
<span class="code-quote">"<span class="code-keyword">true</span>"</span>);

</pre>
</div></div>

<p>For the server side</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
    &lt;jaxws:endpoint name=<span class="code-quote">"{http:<span class="code-comment">//apache.org/hello_world_soap_http}SoapPort"</span>
</span>        wsdlLocation=<span class="code-quote">"wsdl/hello_world.wsdl"</span>
        createdFromAPI=<span class="code-quote">"<span class="code-keyword">true</span>"</span>&gt;
        &lt;jaxws:properties&gt;
            &lt;entry key=<span class="code-quote">"schema-validation-enabled"</span>
value=<span class="code-quote">"<span class="code-keyword">true</span>"</span>
/&gt;
        &lt;/jaxws:properties&gt;
    &lt;/jaxws:endpoint&gt;
</pre>
</div></div>

<p>Starting with CXF 2.3 you have the additional option of using the org.apache.cxf.annotations.SchemaValidation
annotation.</p>

<h3><a name="FAQ-AreJAXWSclientproxiesthreadsafe%3F"></a>Are JAX-WS client
proxies thread safe?</h3>

<p><b>Official JAX-WS answer:</b>  No.   According to the JAX-WS spec, the
client proxies are NOT thread safe.   To write portable code, you should treat them as non-thread
safe and synchronize access or use a pool of instances or similar.</p>

<p><b>CXF answer:</b> CXF proxies are thread safe for MANY use cases.  
The exceptions are:</p>

<ul>
	<li>Use of ((BindingProvider)proxy).getRequestContext() - per JAX-WS spec, the request
context is PER INSTANCE.   Thus, anything set there will affect requests on other threads.
  With CXF, you can do:
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
((BindingProvider)proxy).getRequestContext().put(<span class="code-quote">"thread.local.request.context"</span>,
<span class="code-quote">"<span class="code-keyword">true</span>"</span>);
</pre>
</div></div>
<p>and future calls to getRequestContext() will use a thread local request context.
  That allows the request context to be threadsafe.   (Note: the response context is always
thread local in CXF)</p></li>
</ul>


<ul>
	<li>Settings on the conduit - if you use code or configuration to directly manipulate
the conduit (like to set TLS settings or similar), those are not thread safe.   The conduit
is per-instance and thus those settings would be shared.   Also, if you use the FailoverFeature
and LoadBalanceFeatures, the conduit is replaced on the fly.   Thus, settings set on the conduit
could get lost before being used on the setting thread.</li>
</ul>


<ul>
	<li>Session support - if you turn on sessions support (see jaxws spec), the session
cookie is stored in the conduit.  Thus, it would fall into the above rules on conduit settings
and thus be shared across threads.</li>
</ul>


<p>For the conduit issues, you COULD install a new ConduitSelector that uses a thread
local or similar.   That's a bit complex though.</p>

<p>For most "simple" use cases, you can use CXF proxies on multiple threads.   The above
outlines the workarounds for the others.   </p>


<h2><a name="FAQ-SpringRelated"></a>Spring Related</h2>

<h3><a name="FAQ-WhenusingSpringAOPtoenablethingsliketransactionsandsecurity%2CthegeneratedWSDLisverymessedupwithwrongnamespaces%2Cpartnames%2Cetc..."></a>When
using Spring AOP to enable things like transactions and security, the generated WSDL is very
messed up with wrong namespaces, part names, etc...</h3>

<p><b>Reason:</b> When using Spring AOP, spring injects a proxy to the bean
into CXF instead of the actual bean.   The Proxy does not have the annotations on it (like
the @WebService annotation) so we cannot query the information directly from the object like
we can in the non-AOP case.   The "fix" is to also specify the actual serviceClass of the
object in the spring config:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
&lt;jaxws:server 
      id=<span class="code-quote">"myService"</span> 
      serviceClass=<span class="code-quote">"my.<span class="code-keyword">package</span>.MyServiceImpl"</span>

      serviceBean=<span class="code-quote">"#myServiceImpl"</span> 
      address=<span class="code-quote">"/MyService"</span> /&gt; 
</pre>
</div></div>
<p>or:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
&lt;jaxws:endpoint
      id=<span class="code-quote">"myService"</span> 
      implementorClass=<span class="code-quote">"my.package.MyServiceImpl"</span>

      implementor=<span class="code-quote">"#myServiceImpl"</span> 
      address=<span class="code-quote">"/MyService"</span> /&gt; 
</pre>
</div></div>


    </div>
        <div id="commentsSection" class="wiki-content pageSection">
        <div style="float: right;">
            <a href="https://cwiki.apache.org/confluence/users/viewnotifications.action"
class="grey">Change Notification Preferences</a>
        </div>
        <a href="https://cwiki.apache.org/confluence/display/CXF/FAQ">View Online</a>
        |
        <a href="https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=68110&revisedVersion=58&originalVersion=57">View
Changes</a>
                |
        <a href="https://cwiki.apache.org/confluence/display/CXF/FAQ?showComments=true&amp;showCommentArea=true#addcomment">Add
Comment</a>
            </div>
</div>
</div>
</div>
</div>
</body>
</html>

Mime
View raw message