Author: buildbot
Date: Mon Dec 21 00:00:04 2020
New Revision: 1069307

Log:
Production update by buildbot for cxf

Modified:
    websites/production/cxf/content/cache/docs.pageCache
    websites/production/cxf/content/docs/graalvm-support.html

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

Modified: websites/production/cxf/content/docs/graalvm-support.html
==============================================================================
--- websites/production/cxf/content/docs/graalvm-support.html (original)
+++ websites/production/cxf/content/docs/graalvm-support.html Mon Dec 21 
00:00:04 2020
@@ -117,7 +117,16 @@ Apache CXF -- GraalVM Support
          <td height="100%">
            <!-- Content -->
            <div class="wiki-content">
-<div id="ConfluenceContent"><p><a shape="rect" class="external-link" 
href="https://www.graalvm.org/"; rel="nofollow">GraalVM</a> is becoming an 
increasingly popular target to deploy Apache CXF services. The most challenging 
deployments are the ones which bundle Apache CXF services and applications as 
<a shape="rect" class="external-link" 
href="https://www.graalvm.org/reference-manual/native-image/"; 
rel="nofollow">native images</a>. There are <a shape="rect" 
class="external-link" 
href="https://www.graalvm.org/reference-manual/native-image/#ahead-of-time-compilation-limitations";
 rel="nofollow">some limitations</a> with that and there are certain 
improvements incorporated into Apache CXF recently to provide the way to 
overcome those.</p><h2 id="GraalVMSupport-JAX-RSSupport">JAX-RS 
Support</h2><p>// In progress</p><h2 id="GraalVMSupport-JAX-WSSupport">JAX-WS 
Support</h2><p>For many JAX-WS services which rely on Apache CXF and use its 
code-generation capabilities, producing <a shape="rect
 " class="external-link" href="https://www.graalvm.org/"; 
rel="nofollow">GraalVM</a>'s native images is straightforward, assuming the 
benefits of the <a shape="rect" class="external-link" 
href="https://www.graalvm.org/reference-manual/native-image/BuildConfiguration/#assisted-configuration-of-native-image-builds";
 rel="nofollow">assisted configuration of native image builds</a> could be 
taken of.</p><h3 id="GraalVMSupport-DynamicServers/Clients">Dynamic Servers / 
Clients</h3><p>In certain scenarios Apache CXF does aggressive code generation 
and dynamic class loading at runtime. This violates one of the <a shape="rect" 
class="external-link" href="https://www.graalvm.org/"; 
rel="nofollow">GraalVM</a>'s ahead-of-time compilation limitations which states 
that <strong>"... all classes and all bytecodes that are reachable at run time 
must be known at build time"</strong>. Since <strong>3.3.9 / 3.4.2 / 
3.5.x</strong> there is a way to capture all dynamically generated classes in 
order to inclu
 de them into the native image at build time and then use class loading 
(instead of class generation) at runtime. It eliminates the need for dynamic 
class generation and loading. The capturing capability is provided by <a 
shape="rect" class="external-link" 
href="https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/common/spi/GeneratedClassClassLoaderCapture.java";
 rel="nofollow">GeneratedClassClassLoaderCapture</a> extension (shown 
below).</p><div class="code panel pdl" style="border-width: 1px;"><div 
class="codeContent panelContent pdl">
+<div id="ConfluenceContent"><p><a shape="rect" class="external-link" 
href="https://www.graalvm.org/"; rel="nofollow"></a><style 
type="text/css">/*<![CDATA[*/
+div.rbtoc1608508752216 {padding: 0px;}
+div.rbtoc1608508752216 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1608508752216 li {margin-left: 0px;padding-left: 0px;}
+
+/*]]>*/</style></p><div class="toc-macro rbtoc1608508752216">
+<ul class="toc-indentation"><li><a shape="rect" 
href="#GraalVMSupport-JAX-RSSupport">JAX-RS Support</a></li><li><a shape="rect" 
href="#GraalVMSupport-JAX-WSSupport">JAX-WS Support</a>
+<ul class="toc-indentation"><li><a shape="rect" 
href="#GraalVMSupport-DynamicServers/Clients">Dynamic Servers / 
Clients</a></li><li><a shape="rect" 
href="#GraalVMSupport-Samples">Samples</a></li></ul>
+</li></ul>
+</div><p><a shape="rect" class="external-link" href="https://www.graalvm.org/"; 
rel="nofollow">GraalVM</a> is becoming an increasingly popular target to deploy 
Apache CXF services. The most challenging deployments are the ones which bundle 
Apache CXF services and applications as <a shape="rect" class="external-link" 
href="https://www.graalvm.org/reference-manual/native-image/"; 
rel="nofollow">native images</a>. There are <a shape="rect" 
class="external-link" 
href="https://www.graalvm.org/reference-manual/native-image/#ahead-of-time-compilation-limitations";
 rel="nofollow">some limitations</a> with that and there are certain 
improvements incorporated into Apache CXF recently to provide the way to 
overcome those.</p><h2 id="GraalVMSupport-JAX-RSSupport">JAX-RS 
Support</h2><p>// In progress</p><h2 id="GraalVMSupport-JAX-WSSupport">JAX-WS 
Support</h2><p>For many JAX-WS services which rely on Apache CXF and use its 
code-generation capabilities, producing <a shape="rect" class="external-link
 " href="https://www.graalvm.org/"; rel="nofollow">GraalVM</a>'s native images 
is straightforward, assuming the benefits of the <a shape="rect" 
class="external-link" 
href="https://www.graalvm.org/reference-manual/native-image/BuildConfiguration/#assisted-configuration-of-native-image-builds";
 rel="nofollow">assisted configuration of native image builds</a> could be 
taken of.</p><h3 id="GraalVMSupport-DynamicServers/Clients">Dynamic Servers / 
Clients</h3><p>In certain scenarios Apache CXF does aggressive code generation 
and dynamic class loading at runtime. This violates one of the <a shape="rect" 
class="external-link" href="https://www.graalvm.org/"; 
rel="nofollow">GraalVM</a>'s ahead-of-time compilation limitations which states 
that <strong>"... all classes and all bytecodes that are reachable at run time 
must be known at build time"</strong>. Since <strong>3.3.9 / 3.4.2 / 
3.5.x</strong> there is a way to capture all dynamically generated classes in 
order to include them into the nativ
 e image at build time and then use class loading (instead of class generation) 
at runtime. It eliminates the need for dynamic class generation and loading. 
The capturing capability is provided by <a shape="rect" class="external-link" 
href="https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/common/spi/GeneratedClassClassLoaderCapture.java";
 rel="nofollow">GeneratedClassClassLoaderCapture</a> extension (shown 
below).</p><div class="code panel pdl" style="border-width: 1px;"><div 
class="codeContent panelContent pdl">
 <pre class="brush: java; gutter: false; theme: Default">public interface 
GeneratedClassClassLoaderCapture {
     void capture(String className, byte[] bytes);
 }</pre>


Reply via email to