svn commit: r1069200 - in /websites/production/cxf/content: cache/docs.pageCache docs/graalvm-support.html

[bu...@apache.org]

Author: buildbot
Date: Fri Dec 18 01:05:22 2020
New Revision: 1069200

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 Fri Dec 18 01:05:22 2020
@@ -117,7 +117,7 @@ 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-WSSupport">JAX-WS Support</h2><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.4.2 / 3.5.x</strong> there is a way to capture all dynamically generated classes in order to include 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">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-WSSupport">JAX-WS Support</h2><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 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">
 <pre class="brush: java; gutter: false; theme: Default">public interface GeneratedClassClassLoaderCapture {
     void capture(String className, byte[] bytes);
 }</pre>