cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r890767 - in /websites/production/cxf/content: cache/main.pageCache faq.html
Date Tue, 17 Dec 2013 20:49:06 GMT
Author: buildbot
Date: Tue Dec 17 20:49:06 2013
New Revision: 890767

Log:
Production update by buildbot for cxf

Modified:
    websites/production/cxf/content/cache/main.pageCache
    websites/production/cxf/content/faq.html

Modified: websites/production/cxf/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.

Modified: websites/production/cxf/content/faq.html
==============================================================================
--- websites/production/cxf/content/faq.html (original)
+++ websites/production/cxf/content/faq.html Tue Dec 17 20:49:06 2013
@@ -144,14 +144,12 @@ Apache CXF -- FAQ
          <td height="100%">
            <!-- Content -->
            <div class="wiki-content">
-<div id="ConfluenceContent"><h1 id="FAQ-FrequentlyAskedQuestions">Frequently
Asked Questions</h1>
+<div id="ConfluenceContent"><h1 id="FAQ-FrequentlyAskedQuestions">Frequently
Asked Questions</h1><p><style type="text/css">/*<![CDATA[*/
+div.rbtoc1387313326570 {padding: 0px;}
+div.rbtoc1387313326570 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1387313326570 li {margin-left: 0px;padding-left: 0px;}
 
-<style type="text/css">/*<![CDATA[*/
-div.rbtoc1387228353077 {padding: 0px;}
-div.rbtoc1387228353077 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1387228353077 li {margin-left: 0px;padding-left: 0px;}
-
-/*]]>*/</style><div class="toc-macro rbtoc1387228353077">
+/*]]>*/</style></p><div class="toc-macro rbtoc1387313326570">
 <ul class="toc-indentation"><li><a shape="rect" href="#FAQ-General">General</a>
 <ul class="toc-indentation"><li><a shape="rect" href="#FAQ-CanCXFrunwithJDK1.7?">Can
CXF run with JDK 1.7?</a></li><li><a shape="rect" href="#FAQ-CanCXFrunwithJDK1.6?">Can
CXF run with JDK 1.6?</a></li><li><a shape="rect" href="#FAQ-CanCXFrunwithJDK1.5?">Can
CXF run with JDK 1.5?</a></li><li><a shape="rect" href="#FAQ-CanCXFrunwithouttheSunreferenceSAAJimplementation?">Can
CXF run without the Sun reference SAAJ implementation?</a></li><li><a
shape="rect" href="#FAQ-AretherecommercialofferingsofCXFthatprovideservices,support,andadditionalfeatures?">Are
there commercial offerings of CXF that provide services, support, and additional features?</a></li><li><a
shape="rect" href="#FAQ-IsthereanApacheCXFcertificationprogram?">Is there an Apache CXF
certification program?</a></li></ul>
 </li><li><a shape="rect" href="#FAQ-JAX-WSRelated">JAX-WS Related</a>
@@ -159,57 +157,8 @@ div.rbtoc1387228353077 li {margin-left: 
 </li><li><a shape="rect" href="#FAQ-SpringRelated">Spring Related</a>
 <ul class="toc-indentation"><li><a shape="rect" href="#FAQ-WhenusingSpringAOPtoenablethingsliketransactionsandsecurity,thegeneratedWSDLisverymessedupwithwrongnamespaces,partnames,etc...">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>
 </li></ul>
-</div>
-
-
-<h2 id="FAQ-General">General</h2>
-
-<h3 id="FAQ-CanCXFrunwithJDK1.7?">Can CXF run with JDK 1.7?</h3>
-
-<p>Yes.   CXF supports Java 7.  Since Java 7 contains the 2.2.x versions of both JAXB
and JAX-WS API jars, using CXF with Java 7 is much easier than with Java 6.</p>
-
-<h3 id="FAQ-CanCXFrunwithJDK1.6?">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 id="FAQ-CanCXFrunwithJDK1.5?">Can CXF run with JDK 1.5?</h3>
-
-<p>Yes for CXF 2.6.x and older.  Keep in mind though that Java 2 SE 5.0 with JDK 1.5
has reached end of life (<a shape="rect" class="external-link" href="http://www.oracle.com/technetwork/java/eol-135779.html"
rel="nofollow">EOL</a>). CXF 2.7.x no longer supports Java 5. In order to upgrade
to 2.7.x, you must be using Java 6 (or newer).</p>
-
-
-<h3 id="FAQ-CanCXFrunwithouttheSunreferenceSAAJimplementation?">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 id="FAQ-AretherecommercialofferingsofCXFthatprovideservices,support,andadditionalfeatures?">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 shape="rect" href="commercial-cxf-offerings.html">Commercial
CXF Offerings</a> page for a list of companies and the services they provide.</p>
-
-
-<h3 id="FAQ-IsthereanApacheCXFcertificationprogram?">Is there an Apache CXF certification
program?</h3>
-<p>No, but Oracle's <a shape="rect" class="external-link" href="http://education.oracle.com/pls/web_prod-plq-dad/db_pages.getpage?page_id=41&amp;p_exam_id=1Z0_862"
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 shape="rect" class="external-link" href="http://www.coderanch.com/forums/f-80/java-Web-Services-SCDJWS"
rel="nofollow">SCDJWS Forum</a> at the Java Ranch for healthy discussions in regards
to the certification. Study notes can be found at <a shape="rect" class="external-link"
href="http://java.boot.by/scdjws5-guide/" rel="nofollow">SCDJWS 5.0 Study Guide</a>,
<a shape="rect" class="external-link" href="http://en.wikibooks.org/wiki/Sun_Certified_Web_Services_Developer_Certification"
rel="nofollow">WikiBooks</a> and <a shape="rect" class="external-link" href="http://www.coderanch.com/how-to/content/Exam-Objectives-5.pdf"
rel="nofollow">Iv
 an A. Krizsan Study Notes</a>.  Java Ranch also provides and information <a shape="rect"
class="external-link" href="http://www.coderanch.com/how-to/java/ScdjwsLinks" rel="nofollow">page</a>
in regards to the certification.</p>
-
-<h2 id="FAQ-JAX-WSRelated">JAX-WS Related</h2>
-
-<h3 id="FAQ-Thepartsinmygeneratedwsdlhavenamesoftheform&quot;arg0&quot;,&quot;arg1&quot;,...Whydon'ttheparts(andJavageneratedfromthem)usetheniceparameternamesItypedintotheinterfacedefinition?">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><strong>Official answer:</strong>  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><strong>Reason:</strong> 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 id="FAQ-HowcanIaddsoapheaderstotherequest/response?">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 @WebPara
 m(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 pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
-<script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[
-List&lt;Header&gt; headers = new ArrayList&lt;Header&gt;();
+</div><h2 id="FAQ-General">General</h2><h3 id="FAQ-CanCXFrunwithJDK1.7?">Can
CXF run with JDK 1.7?</h3><p>Yes. CXF supports Java 7. Since Java 7 contains the
2.2.x versions of both JAXB and JAX-WS API jars, using CXF with Java 7 is much easier than
with Java 6.</p><h3 id="FAQ-CanCXFrunwithJDK1.6?">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 id="FAQ-CanCXFrunwithJDK1.5?">Can
CXF run with JDK 1.5?</h3><p>Yes for CXF 2.6.x and older. Keep in mind though
that Java 2 SE 5.0 with JDK 1.5 has reached end of life (<a shape="rect" class="external-link"
href="http://www.oracle.com/technetwork/java/eol-135779.html" rel="nofollow">EOL</a>).
CXF 2.7.x no longer support
 s Java 5. In order to upgrade to 2.7.x, you must be using Java 6 (or newer).</p><h3
id="FAQ-CanCXFrunwithouttheSunreferenceSAAJimplementation?">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 id="FAQ-AretherecommercialofferingsofCXFthatprovideservices,support,andadditionalfeatures?">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 shape="rect" href
 ="commercial-cxf-offerings.html">Commercial CXF Offerings</a> page for a list of
companies and the services they provide.</p><h3 id="FAQ-IsthereanApacheCXFcertificationprogram?">Is
there an Apache CXF certification program?</h3><p>No, but Oracle's <a shape="rect"
class="external-link" href="http://education.oracle.com/pls/web_prod-plq-dad/db_pages.getpage?page_id=41&amp;p_exam_id=1Z0_862"
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 shape="rect" class="external-link" href="http://www.coderanch.com/forums/f-80/java-Web-Services-SCDJWS"
rel="nofollow">SCDJWS Forum</a> at the Java Ranch for healthy discussions in regards
to the certification. Study notes can be found at <a shape="rect" class="external-link"
href="http://java.boot.by/scdjws5-guide/" rel="nofollow">SCDJWS 5.0 Study Guide</a>,
<a shape="rect" class="external-link" href="http://en.wi
 kibooks.org/wiki/Sun_Certified_Web_Services_Developer_Certification" rel="nofollow">WikiBooks</a>
and <a shape="rect" class="external-link" href="http://www.coderanch.com/how-to/content/Exam-Objectives-5.pdf"
rel="nofollow">Ivan A. Krizsan Study Notes</a>. Java Ranch also provides and information
<a shape="rect" class="external-link" href="http://www.coderanch.com/how-to/java/ScdjwsLinks"
rel="nofollow">page</a> in regards to the certification.</p><h2 id="FAQ-JAX-WSRelated">JAX-WS
Related</h2><h3 id="FAQ-Thepartsinmygeneratedwsdlhavenamesoftheform&quot;arg0&quot;,&quot;arg1&quot;,...Whydon'ttheparts(andJavageneratedfromthem)usetheniceparameternamesItypedintotheinterfacedefinition?">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><strong>Official
answer:</strong> The JAX-WS spec (specifically section 3.6.1) mandates that it be generat
 ed 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><strong>Reason:</strong>
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 c
 hange. 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 id="FAQ-HowcanIaddsoapheaderstotherequest/response?">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 doi
 ng 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 He
 ader.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
pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[List&lt;Header&gt;
headers = new ArrayList&lt;Header&gt;();
 Header dummyHeader = new Header(new QName(&quot;uri:org.apache.cxf&quot;, &quot;dummy&quot;),
&quot;decapitated&quot;,
                                 new JAXBDataBinding(String.class));
 headers.add(dummyHeader);
@@ -220,33 +169,19 @@ context.getMessageContext().put(Header.H
 //client side:
 ((BindingProvider)proxy).getRequestContext().put(Header.HEADER_LIST, headers);
 ]]></script>
-</div></div>
-
-<h3 id="FAQ-HowcanIturnonschemavalidationforjaxwsendpoint?">How can I turn on schema
validation for jaxws endpoint?</h3>
-<p>For the client side</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
-<script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[
-    &lt;jaxws:client name=&quot;{http://apache.org/hello_world_soap_http}SoapPort&quot;
+</div></div><h3 id="FAQ-HowcanIturnonschemavalidationforjaxwsendpoint?">How
can I turn on schema validation for jaxws endpoint?</h3><p>For the client side</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
+<script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[
   &lt;jaxws:client name=&quot;{http://apache.org/hello_world_soap_http}SoapPort&quot;
         createdFromAPI=&quot;true&quot;&gt;
         &lt;jaxws:properties&gt;
             &lt;entry key=&quot;schema-validation-enabled&quot; value=&quot;true&quot;
/&gt;
         &lt;/jaxws:properties&gt;
     &lt;/jaxws:client&gt;
 ]]></script>
-</div></div>
-
-<p>You may also do this programmatically:</p>
-
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
-<script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[
-((BindingProvider)port).getRequestContext().put(&quot;schema-validation-enabled&quot;,
&quot;true&quot;); 
+</div></div><p>You may also do this programmatically:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
+<script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[((BindingProvider)port).getRequestContext().put(&quot;schema-validation-enabled&quot;,
&quot;true&quot;); 
 ]]></script>
-</div></div>
-
-<p>For the server side</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
-<script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[
-    &lt;jaxws:endpoint name=&quot;{http://apache.org/hello_world_soap_http}SoapPort&quot;
+</div></div><p>For the server side</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[
   &lt;jaxws:endpoint name=&quot;{http://apache.org/hello_world_soap_http}SoapPort&quot;
         wsdlLocation=&quot;wsdl/hello_world.wsdl&quot;
         createdFromAPI=&quot;true&quot;&gt;
         &lt;jaxws:properties&gt;
@@ -254,62 +189,18 @@ context.getMessageContext().put(Header.H
         &lt;/jaxws:properties&gt;
     &lt;/jaxws:endpoint&gt;
 ]]></script>
-</div></div>
-
-<p>Starting with CXF 2.3 you have the additional option of using the org.apache.cxf.annotations.SchemaValidation
annotation.</p>
-
-<h3 id="FAQ-AreJAX-WSclientproxiesthreadsafe?">Are JAX-WS client proxies thread safe?</h3>
-
-<p><strong>Official JAX-WS answer:</strong>  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><strong>CXF answer:</strong> 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 pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
-<script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[
-((BindingProvider)proxy).getRequestContext().put(&quot;thread.local.request.context&quot;,
&quot;true&quot;);
+</div></div><p>Starting with CXF 2.3 you have the additional option of
using the org.apache.cxf.annotations.SchemaValidation annotation.</p><h3 id="FAQ-AreJAX-WSclientproxiesthreadsafe?">Are
JAX-WS client proxies thread safe?</h3><p><strong>Official JAX-WS answer:</strong>
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><strong>CXF answer:</strong> CXF proxies are thread
safe for MANY use cases. The exceptions are:</p><ul><li><p>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:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[((BindingProvider)proxy).getRequestContext().put(&quot;thread.local.request.context&quot;,
&quot;true&quot;);
 ]]></script>
-</div></div>
-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)</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>
-
-
-<ul><li>WS-Security tokens - If use WS-SecureConversation or WS-Trust, the retrieved
token is cached in the Endpoint/Proxy to avoid the extra (and expensive) calls to the STS
to obtain tokens.   Thus, multiple threads will share the token.   If each thread has different
security credentials or requirements, you need to use separate proxy instances.</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>
-
-<h3 id="FAQ-Thegeneratedwsdl(GETrequestonthe?wsdladdress)doesn'tcontainthemessages,types,portType,etc...WhatdidIdowrong?">The
generated wsdl (GET request on the ?wsdl address) doesn't contain the messages, types, portType,
etc...  What did I do wrong?</h3>
-
-<p>Usually this means the wsdl at that address contains the service and binding, but
uses a &lt;wsdl:import&gt; element to import another wsdl (usually at ?wsdl=MyService1.wsdl
type address) that defines the types, messages, and portType.   The cause of this is different
targetNamespaces for the Service Interface (mapped to the port type) and the service implementation
(mapped to the Service/Binding).  By default, the targetNamespace is derived from the package
of each of those, so if they are in different packages, you will see this issue.  Also, if
you define a targetNamespace attribute on the @WebService annotation on one of them, but not
the other, you will likely see this as well.   The easiest fix is to update the @WebService
annotation on BOTH to have the exact same targetNamespace defined.   </p>
-
-
-
-<h2 id="FAQ-SpringRelated">Spring Related</h2>
-
-<h3 id="FAQ-WhenusingSpringAOPtoenablethingsliketransactionsandsecurity,thegeneratedWSDLisverymessedupwithwrongnamespaces,partnames,etc...">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><strong>Reason:</strong> 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 pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
-<script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[
-&lt;jaxws:server 
+</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><ul><li>WS-Security
tokens - If use WS-SecureConversation or WS-Trust, the retrieved token is cached in the Endpoint/Pr
 oxy to avoid the extra (and expensive) calls to the STS to obtain tokens. Thus, multiple
threads will share the token. If each thread has different security credentials or requirements,
you need to use separate proxy instances.</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><h3 id="FAQ-Thegeneratedwsdl(GETrequestonthe?wsdladdress)doesn'tcontainthemessages,types,portType,etc...WhatdidIdowrong?">The
generated wsdl (GET request on the ?wsdl address) doesn't contain the messages, types, portType,
etc... What did I do wrong?</h3><p>Usually this means the wsdl at that address
contains the service and binding, but uses a &lt;wsdl:import&gt; element to import
another wsdl (usually at ?wsdl=MyService1.wsdl type address) that defines the types, messages,
and portType.
  The cause of this is different targetNamespaces for the Service Interface (mapped to the
port type) and the service implementation (mapped to the Service/Binding). By default, the
targetNamespace is derived from the package of each of those, so if they are in different
packages, you will see this issue. Also, if you define a targetNamespace attribute on the
@WebService annotation on one of them, but not the other, you will likely see this as well.
The easiest fix is to update the @WebService annotation on BOTH to have the exact same targetNamespace
defined.</p><h2 id="FAQ-SpringRelated">Spring Related</h2><h3 id="FAQ-WhenusingSpringAOPtoenablethingsliketransactionsandsecurity,thegeneratedWSDLisverymessedupwithwrongnamespaces,partnames,etc...">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><strong>Reason:</strong>
When using Spring AOP, spring injects a proxy to the bean int
 o 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 pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[&lt;jaxws:server

       id=&quot;myService&quot; 
       serviceClass=&quot;my.package.MyServiceImpl&quot; 
       serviceBean=&quot;#myServiceImpl&quot; 
       address=&quot;/MyService&quot; /&gt; 
 ]]></script>
-</div></div>
-<p>or:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
-<script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[
-&lt;jaxws:endpoint
+</div></div><p>or:</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[&lt;jaxws:endpoint
       id=&quot;myService&quot; 
       implementorClass=&quot;my.package.MyServiceImpl&quot; 
       implementor=&quot;#myServiceImpl&quot; 



Mime
View raw message