[jira] [Updated] (CXF-7685) WSDL2java -compile fails when run with JDK-9, JDK-10, JDK-11
[
https://issues.apache.org/jira/browse/CXF-7685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rebecca Searls updated CXF-7685:
Description:
JBossws-cxf calls WSDL2java and passes input arguments. WSDL2java prints the
input args it recieves, that information looks like this,
{code:java}
wsdl2java -compile -d /tmp/output/tmp1993473 -verbose -classdir /tmp/output
-allowElementReferences
https://raw.githubusercontent.com/jbossws/jbossws-cxf/master/modules/testsuite/shared-tests/src/test/resources/jaxws/smoke/tools/wsdl/TestServiceSoap12.wsdl
{code}
Starting with JDK-9 WSDL2java is unable to successfully compile the generated
classes. Class imports, javax.jws.WebMethod, javax.jws.WebService and the like
can not be resolved. javac does not find module java.xml.ws by default. From
StackOverflow discussions it appears the --add-modules java.xml.ws may need to
be passed to the compiler. I see any way in the existing code to do this.
I think WSDL2java should pass by default java.xml.ws and other related ee
modules by default to the compiler.
Here is the output of the tool.
{code:java}
1206 > ~/bin/mywsdl2java -compile -d /tmp/output/tmp1993473 -verbose -classdir
/tmp/output -allowElementReferences
https://raw.githubusercontent.com/jbossws/jbossws-cxf/master/modules/testsuite/shared-tests/src/test/resources/jaxws/smoke/tools/wsdl/TestServiceSoap12.wsdl
OpenJDK 64-Bit Server VM warning: Ignoring option MaxPermSize; support was
removed in 8.0
Listening for transport dt_socket at address: 8787
SLF4J: Detected both log4j-over-slf4j.jar AND bound slf4j-log4j12.jar on the
class path, preempting StackOverflowError.
SLF4J: See also http://www.slf4j.org/codes.html#log4jDelegationLoop for more
details.
Loading FrontEnd jaxws ...
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further
details.
Loading DataBinding jaxb ...
wsdl2java -compile -d /tmp/output/tmp1993473 -verbose -classdir /tmp/output
-allowElementReferences
https://raw.githubusercontent.com/jbossws/jbossws-cxf/master/modules/testsuite/shared-tests/src/test/resources/jaxws/smoke/tools/wsdl/TestServiceSoap12.wsdl
wsdl2java - Apache CXF 3.2.4-SNAPSHOT-53b2be829ed6cd7660ae90e035cc8588b0a8dfb1
Mar 21, 2018 8:50:56 PM org.apache.cxf.wsdl11.WSDLServiceBuilder checkForWrapped
INFO: Operation {http://www.openuri.org/2004/04/HelloWorld}echo cannot be
unwrapped, input message must reference global element declaration with same
localname as operation
/tmp/output/tmp1993473/org/openuri/_2004/_04/helloworld/EndpointInterface.java:3:
error: package javax.jws is not visible
import javax.jws.WebMethod;
^
(package javax.jws is declared in module java.xml.ws, which is not in the
module graph)
/tmp/output/tmp1993473/org/openuri/_2004/_04/helloworld/EndpointInterface.java:4:
error: package javax.jws is not visible
import javax.jws.WebParam;
^
(package javax.jws is declared in module java.xml.ws, which is not in the
module graph)
/tmp/output/tmp1993473/org/openuri/_2004/_04/helloworld/EndpointInterface.java:5:
error: package javax.jws is not visible
import javax.jws.WebResult;
^
(package javax.jws is declared in module java.xml.ws, which is not in the
module graph)
/tmp/output/tmp1993473/org/openuri/_2004/_04/helloworld/EndpointInterface.java:6:
error: package javax.jws is not visible
import javax.jws.WebService;
^
(package javax.jws is declared in module java.xml.ws, which is not in the
module graph)
/tmp/output/tmp1993473/org/openuri/_2004/_04/helloworld/EndpointInterface.java:7:
error: package javax.jws.soap is not visible
import javax.jws.soap.SOAPBinding;
^
(package javax.jws.soap is declared in module java.xml.ws, which is not in
the module graph)
WSDLToJava Error: Failed to compile generated code
org.apache.cxf.tools.common.ToolException: Failed to compile generated code
at org.apache.cxf.tools.common.ClassUtils.compile(ClassUtils.java:125)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:303)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:164)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:412)
at
org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:105)
at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:86)
at org.apache.cxf.tools.wsdlto.WSDLToJava.main(WSDLToJava.java:185)
{code}
Please find attached script mywsdl2java which will demonstrate this issue.
Edit mywsdl2java and change CXF_HOME and M2_HOME to be the appropriate path.
Make directory /tmp/output/tmp1993473
In a terminal exec cmd
./mywsdl2java
[jira] [Created] (CXF-7685) WSDL2java -compile fails when run with JDK-9, JDK-10, JDK-11
Rebecca Searls created CXF-7685:
---
Summary: WSDL2java -compile fails when run with JDK-9, JDK-10,
JDK-11
Key: CXF-7685
URL: https://issues.apache.org/jira/browse/CXF-7685
Project: CXF
Issue Type: Bug
Components: Tooling
Affects Versions: 3.2.3, 3.2.2
Environment: OS: Fedora 26
JDK: 9.0.4
mvn: 3.5.0
cxf: 3.2.4-SNAPSHOT
Reporter: Rebecca Searls
Attachments: mywsdl2java
JBossws-cxf calls WSDL2java and passes input arguments. WSDL2java prints the
input args it recieves. That information looks like this,
{code:java}
wsdl2java -compile -d /tmp/output/tmp1993473 -verbose -classdir /tmp/output
-allowElementReferences
https://raw.githubusercontent.com/jbossws/jbossws-cxf/master/modules/testsuite/shared-tests/src/test/resources/jaxws/smoke/tools/wsdl/TestServiceSoap12.wsdl
{code}
Starting with JDK-9 WSDL2java is unable to successfully compile the generated
classes. Class imports, javax.jws.WebMethod, javax.jws.WebService and the like
can not be resolved because "module java.xml.ws, which is not in the module
graph".
Here is the output of the tool.
{code:java}
1206 > ~/bin/mywsdl2java -compile -d /tmp/output/tmp1993473 -verbose -classdir
/tmp/output -allowElementReferences
https://raw.githubusercontent.com/jbossws/jbossws-cxf/master/modules/testsuite/shared-tests/src/test/resources/jaxws/smoke/tools/wsdl/TestServiceSoap12.wsdl
OpenJDK 64-Bit Server VM warning: Ignoring option MaxPermSize; support was
removed in 8.0
Listening for transport dt_socket at address: 8787
SLF4J: Detected both log4j-over-slf4j.jar AND bound slf4j-log4j12.jar on the
class path, preempting StackOverflowError.
SLF4J: See also http://www.slf4j.org/codes.html#log4jDelegationLoop for more
details.
Loading FrontEnd jaxws ...
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further
details.
Loading DataBinding jaxb ...
wsdl2java -compile -d /tmp/output/tmp1993473 -verbose -classdir /tmp/output
-allowElementReferences
https://raw.githubusercontent.com/jbossws/jbossws-cxf/master/modules/testsuite/shared-tests/src/test/resources/jaxws/smoke/tools/wsdl/TestServiceSoap12.wsdl
wsdl2java - Apache CXF 3.2.4-SNAPSHOT-53b2be829ed6cd7660ae90e035cc8588b0a8dfb1
Mar 21, 2018 8:50:56 PM org.apache.cxf.wsdl11.WSDLServiceBuilder checkForWrapped
INFO: Operation {http://www.openuri.org/2004/04/HelloWorld}echo cannot be
unwrapped, input message must reference global element declaration with same
localname as operation
/tmp/output/tmp1993473/org/openuri/_2004/_04/helloworld/EndpointInterface.java:3:
error: package javax.jws is not visible
import javax.jws.WebMethod;
^
(package javax.jws is declared in module java.xml.ws, which is not in the
module graph)
/tmp/output/tmp1993473/org/openuri/_2004/_04/helloworld/EndpointInterface.java:4:
error: package javax.jws is not visible
import javax.jws.WebParam;
^
(package javax.jws is declared in module java.xml.ws, which is not in the
module graph)
/tmp/output/tmp1993473/org/openuri/_2004/_04/helloworld/EndpointInterface.java:5:
error: package javax.jws is not visible
import javax.jws.WebResult;
^
(package javax.jws is declared in module java.xml.ws, which is not in the
module graph)
/tmp/output/tmp1993473/org/openuri/_2004/_04/helloworld/EndpointInterface.java:6:
error: package javax.jws is not visible
import javax.jws.WebService;
^
(package javax.jws is declared in module java.xml.ws, which is not in the
module graph)
/tmp/output/tmp1993473/org/openuri/_2004/_04/helloworld/EndpointInterface.java:7:
error: package javax.jws.soap is not visible
import javax.jws.soap.SOAPBinding;
^
(package javax.jws.soap is declared in module java.xml.ws, which is not in
the module graph)
WSDLToJava Error: Failed to compile generated code
org.apache.cxf.tools.common.ToolException: Failed to compile generated code
at org.apache.cxf.tools.common.ClassUtils.compile(ClassUtils.java:125)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:303)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:164)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:412)
at
org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:105)
at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:86)
at org.apache.cxf.tools.wsdlto.WSDLToJava.main(WSDLToJava.java:185)
{code}
Please file attached script mywsdl2java which will demonstrate this issue.
Edit mywsdl2java and change CXF_HOME and M2_HOME to be the appropriate path.
Make directory
[jira] [Commented] (CXF-7670) synthetic methods: equal candidates for handling the current request
[ https://issues.apache.org/jira/browse/CXF-7670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16408828#comment-16408828 ] Andriy Redko commented on CXF-7670: --- [~ilgrosso] I just saw that [~dkulp] committed a fix (thanks!), could you please check if your issue has gone? I will be committing test case shortly. Thank you. > synthetic methods: equal candidates for handling the current request > > > Key: CXF-7670 > URL: https://issues.apache.org/jira/browse/CXF-7670 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.2.1, 3.2.2 > Environment: I have noticed this with kotlin projects. >Reporter: Laszlo Hornyak >Priority: Major > Fix For: 3.2.4 > > > When discovering JAX-RS annotations, CXF does not filter out synthetic > methods. If the compiler have created any synthetic methods out of the > annotated methods, it will store them as JAX-RS resource methods with > actually the same annotated method. > After startup, CXF will log each invocation on the duplicated resource > methods with a warning, which reduces performance, and generates quite some > log. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CXF-7683) Codegen fails when using JDK10 with maven and cxf-plugin
[ https://issues.apache.org/jira/browse/CXF-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned CXF-7683: - Assignee: Freeman Fang > Codegen fails when using JDK10 with maven and cxf-plugin > > > Key: CXF-7683 > URL: https://issues.apache.org/jira/browse/CXF-7683 > Project: CXF > Issue Type: Bug > Components: Tooling >Affects Versions: 3.2.3 > Environment: Apache Maven 3.5.3 > (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00) > Maven home: C:\Develop\_tools\apache-maven-3.5.3\bin\.. > Java version: 10, vendor: Oracle Corporation > Java home: C:\Develop\_tools\jdk-10.0.0 > Default locale: de_DE, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" >Reporter: Falko Modler >Assignee: Freeman Fang >Priority: Major > > The fix from CXF-7517 only works for JDK9 and not for the newly released > JDK10 because [the code only checks for 9, not > 9+|https://github.com/apache/cxf/commit/d529ecd2252046c0e55fbe7b5e6a24c7b0d07301#diff-251b0327fb2172db1d74135de8666edcR206]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-7684) Base64 encoding in AttachmentSerializer does not create correct output for large attachments
[ https://issues.apache.org/jira/browse/CXF-7684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-7684. -- Resolution: Fixed Assignee: Daniel Kulp Fix Version/s: 3.2.4 3.1.16 > Base64 encoding in AttachmentSerializer does not create correct output for > large attachments > > > Key: CXF-7684 > URL: https://issues.apache.org/jira/browse/CXF-7684 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.0.16 >Reporter: Uwe Ryssel >Assignee: Daniel Kulp >Priority: Major > Fix For: 3.1.16, 3.2.4 > > > As client, I want to send a SOAP message with base64-encoded attachments. I > have activated base64 encoding for attachments by adding an out interceptor, > which sets the message parameter > org.apache.cxf.message.Message.CONTENT_TRANSFER_ENCODING to "base64", since > it is supported by the CXF-core's AttachmentSerializer. > For small attachments, the encoding works. But when I have a large > attachment, the base64-encoded data is, I think, not valid: > As implemented in AttachmentSerializer's method encodeBase64(), the encoding > of the input data is done in blocks of maximum 262144 bytes. Since 262144 > divided by 3 has remainder 1, each of the blocks containing the full 262144 > bytes will generate two '=' padding characters at the end of the block output. > So for large attachments with > 262144 bytes, the created base64 data stream > contains padding characters within the stream, and not only at the end. I did > not find any hint, that this is allowed. > Especially the server implementation, which I use, interprets the padding > characters also as end of stream, so that attachments > 262144 do not work in > that case. > An fix for this issue would be to use a buffer size, which is divisible by > three without remainder. > I still use CXF 3.0.16, since the client have to work with Java 1.6. But > 3.1.x and 3.2.x use the same method, so the same issue should apply there too. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7643) Ability to disable certain ContextResolved CDI Beans
[
https://issues.apache.org/jira/browse/CXF-7643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16408207#comment-16408207
]
ASF GitHub Bot commented on CXF-7643:
-
dkulp closed pull request #393: CXF-7643 ensure CDI extension defaults are CDI
compliant
URL: https://github.com/apache/cxf/pull/393
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/integration/cdi/src/main/java/org/apache/cxf/cdi/ContextProducerBean.java
b/integration/cdi/src/main/java/org/apache/cxf/cdi/ContextProducerBean.java
index 7fab97782d7..98bcca69ee6 100644
--- a/integration/cdi/src/main/java/org/apache/cxf/cdi/ContextProducerBean.java
+++ b/integration/cdi/src/main/java/org/apache/cxf/cdi/ContextProducerBean.java
@@ -34,16 +34,19 @@
public class ContextProducerBean extends AbstractCXFBean implements
PassivationCapable {
private final Type type;
+private final Set qualifiers;
-ContextProducerBean(Type type) {
+ContextProducerBean(Type type, boolean defaultQualifier) {
this.type = type;
+this.qualifiers = new HashSet<>(defaultQualifier ? 2 : 1);
+this.qualifiers.add(ContextResolved.LITERAL);
+if (defaultQualifier) {
+this.qualifiers.add(DEFAULT);
+}
}
@Override
public Set getQualifiers() {
-Set qualifiers = new HashSet<>(2);
-qualifiers.add(ContextResolved.LITERAL);
-qualifiers.add(DEFAULT);
return qualifiers;
}
diff --git
a/integration/cdi/src/main/java/org/apache/cxf/cdi/JAXRSCdiResourceExtension.java
b/integration/cdi/src/main/java/org/apache/cxf/cdi/JAXRSCdiResourceExtension.java
index bc7a251cbb3..d2b76dbd5cd 100644
---
a/integration/cdi/src/main/java/org/apache/cxf/cdi/JAXRSCdiResourceExtension.java
+++
b/integration/cdi/src/main/java/org/apache/cxf/cdi/JAXRSCdiResourceExtension.java
@@ -22,6 +22,7 @@
import java.util.ArrayList;
import java.util.Collection;
import java.util.Collections;
+import java.util.HashSet;
import java.util.LinkedHashSet;
import java.util.List;
import java.util.Objects;
@@ -35,6 +36,7 @@
import javax.enterprise.inject.spi.AnnotatedType;
import javax.enterprise.inject.spi.Bean;
import javax.enterprise.inject.spi.BeanManager;
+import javax.enterprise.inject.spi.BeforeBeanDiscovery;
import javax.enterprise.inject.spi.BeforeShutdown;
import javax.enterprise.inject.spi.Extension;
import javax.enterprise.inject.spi.InjectionTarget;
@@ -63,6 +65,10 @@
import org.apache.cxf.jaxrs.utils.JAXRSServerFactoryCustomizationUtils;
import org.apache.cxf.jaxrs.utils.ResourceUtils;
+import static java.util.Arrays.asList;
+import static java.util.Optional.ofNullable;
+import static org.apache.cxf.cdi.AbstractCXFBean.DEFAULT;
+
/**
* Apache CXF portable CDI extension to support initialization of JAX-RS
resources.
*/
@@ -78,6 +84,8 @@
new ArrayList< CreationalContext< ? > >();
private final Set< Type > contextTypes = new LinkedHashSet<>();
+private final Collection< String > existingStandardClasses = new
HashSet<>();
+
/**
* Holder of the classified resource classes, converted to appropriate
instance
* representations.
@@ -112,6 +120,46 @@ public void addResourceProvider(final CdiResourceProvider
other) {
}
}
+// observing JAXRSCdiResourceExtension a "container" can customize that
value to prevent some instances
+// to be added with the default qualifier
+public Collection getExistingStandardClasses() {
+return existingStandardClasses;
+}
+
+/**
+ * Fires itsels, allows other extensions to modify this one.
+ * Typical example can be to modify existingStandardClasses to prevent CXF
+ * to own some beans it shouldn't create with default classifier.
+ *
+ * @param beforeBeanDiscovery the corresponding cdi event.
+ * @param beanManager the cdi bean manager.
+ */
+void onStartup(@Observes final BeforeBeanDiscovery beforeBeanDiscovery,
final BeanManager beanManager) {
+final ClassLoader loader =
ofNullable(Thread.currentThread().getContextClassLoader())
+.orElseGet(ClassLoader::getSystemClassLoader);
+boolean webHandled = false;
+try { // OWB
+
loader.loadClass("org.apache.webbeans.web.lifecycle.WebContainerLifecycle");
+webHandled = true;
+} catch (final NoClassDefFoundError | ClassNotFoundException e) {
+// ok to keep them all
+}
+if (!webHandled) {
+try { // Weld
+loader.loadClass("org.jboss.weld.module.web.WeldWebModule");
+webHandled = true;
+} catch (final NoClassDefFoundError |
[jira] [Created] (CXF-7684) Base64 encoding in AttachmentSerializer does not create correct output for large attachments
Uwe Ryssel created CXF-7684: --- Summary: Base64 encoding in AttachmentSerializer does not create correct output for large attachments Key: CXF-7684 URL: https://issues.apache.org/jira/browse/CXF-7684 Project: CXF Issue Type: Bug Components: Core Affects Versions: 3.0.16 Reporter: Uwe Ryssel As client, I want to send a SOAP message with base64-encoded attachments. I have activated base64 encoding for attachments by adding an out interceptor, which sets the message parameter org.apache.cxf.message.Message.CONTENT_TRANSFER_ENCODING to "base64", since it is supported by the CXF-core's AttachmentSerializer. For small attachments, the encoding works. But when I have a large attachment, the base64-encoded data is, I think, not valid: As implemented in AttachmentSerializer's method encodeBase64(), the encoding of the input data is done in blocks of maximum 262144 bytes. Since 262144 divided by 3 has remainder 1, each of the blocks containing the full 262144 bytes will generate two '=' padding characters at the end of the block output. So for large attachments with > 262144 bytes, the created base64 data stream contains padding characters within the stream, and not only at the end. I did not find any hint, that this is allowed. Especially the server implementation, which I use, interprets the padding characters also as end of stream, so that attachments > 262144 do not work in that case. An fix for this issue would be to use a buffer size, which is divisible by three without remainder. I still use CXF 3.0.16, since the client have to work with Java 1.6. But 3.1.x and 3.2.x use the same method, so the same issue should apply there too. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7517) Codegen fails when using JDK9 with maven and cxf-plugin
[
https://issues.apache.org/jira/browse/CXF-7517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16408028#comment-16408028
]
Falko Modler commented on CXF-7517:
---
This fix doesn't work for the newly released JDK*10* because the version number
check is too strict, see: CXF-7683
> Codegen fails when using JDK9 with maven and cxf-plugin
> ---
>
> Key: CXF-7517
> URL: https://issues.apache.org/jira/browse/CXF-7517
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 3.1.12
>Reporter: David J. M. Karlsen
>Assignee: Freeman Fang
>Priority: Major
> Labels: jdk9
> Fix For: 3.2.1
>
>
> I get this stack trace when trying to generate code with the
> cxf-codegen-plugin:
> {noformat}
> [INFO] --- cxf-codegen-plugin:3.1.12:wsdl2java (default) @ jfr-srv-schemas ---
> [INFO] Using proxy server configured in maven.
> [INFO] Running code generation in fork mode...
> [INFO] The java executable is
> /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/java
> [INFO] Building jar:
> /var/folders/c7/18m1hlzs075_z0f5nfnt44jmgn/T/cxf-tmp-3400635706757982781/cxf-codegen16491176446297681426.jar
> [WARNING] WARNING: An illegal reflective access operation has occurred
> [WARNING] WARNING: Illegal reflective access by
> com.sun.xml.bind.v2.runtime.reflect.opt.Injector
> (file:/Users/et2448/.m2/repository/com/sun/xml/bind/jaxb-impl/2.2.11/jaxb-impl-2.2.11.jar)
> to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int)
> [WARNING] WARNING: Please consider reporting this to the maintainers of
> com.sun.xml.bind.v2.runtime.reflect.opt.Injector
> [WARNING] WARNING: Use --illegal-access=warn to enable warnings of further
> illegal reflective access operations
> [WARNING] WARNING: All illegal access operations will be denied in a future
> release
> [WARNING] Exception in thread "main" java.lang.NoClassDefFoundError:
> javax/xml/ws/Service
> [WARNING] at
> org.apache.cxf.tools.wsdlto.frontend.jaxws.JAXWSContainer.isJaxws22(JAXWSContainer.java:64)
> [WARNING] at
> org.apache.cxf.tools.wsdlto.frontend.jaxws.JAXWSContainer.getServiceTarget(JAXWSContainer.java:61)
> [WARNING] at
> org.apache.cxf.tools.wsdlto.frontend.jaxws.JAXWSContainer.validate(JAXWSContainer.java:68)
> [WARNING] at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:175)
> [WARNING] at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:164)
> [WARNING] at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:415)
> [WARNING] at
> org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:105)
> [WARNING] at
> org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
> [WARNING] at
> org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:86)
> [WARNING] at
> org.apache.cxf.maven_plugin.wsdl2java.ForkOnceWSDL2Java.main(ForkOnceWSDL2Java.java:51)
> [WARNING] Caused by: java.lang.ClassNotFoundException: javax.xml.ws.Service
> [WARNING] at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
> [WARNING] at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:185)
> [WARNING] at
> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
> [WARNING] ... 10 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CXF-7683) Codegen fails when using JDK10 with maven and cxf-plugin
Falko Modler created CXF-7683: - Summary: Codegen fails when using JDK10 with maven and cxf-plugin Key: CXF-7683 URL: https://issues.apache.org/jira/browse/CXF-7683 Project: CXF Issue Type: Bug Components: Tooling Affects Versions: 3.2.3 Environment: Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00) Maven home: C:\Develop\_tools\apache-maven-3.5.3\bin\.. Java version: 10, vendor: Oracle Corporation Java home: C:\Develop\_tools\jdk-10.0.0 Default locale: de_DE, platform encoding: Cp1252 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" Reporter: Falko Modler The fix from CXF-7517 only works for JDK9 and not for the newly released JDK10 because [the code only checks for 9, not 9+|https://github.com/apache/cxf/commit/d529ecd2252046c0e55fbe7b5e6a24c7b0d07301#diff-251b0327fb2172db1d74135de8666edcR206]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7670) synthetic methods: equal candidates for handling the current request
[ https://issues.apache.org/jira/browse/CXF-7670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated CXF-7670: Fix Version/s: 3.2.4 > synthetic methods: equal candidates for handling the current request > > > Key: CXF-7670 > URL: https://issues.apache.org/jira/browse/CXF-7670 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.2.1, 3.2.2 > Environment: I have noticed this with kotlin projects. >Reporter: Laszlo Hornyak >Priority: Major > Fix For: 3.2.4 > > > When discovering JAX-RS annotations, CXF does not filter out synthetic > methods. If the compiler have created any synthetic methods out of the > annotated methods, it will store them as JAX-RS resource methods with > actually the same annotated method. > After startup, CXF will log each invocation on the duplicated resource > methods with a warning, which reduces performance, and generates quite some > log. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7670) synthetic methods: equal candidates for handling the current request
[ https://issues.apache.org/jira/browse/CXF-7670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16407567#comment-16407567 ] Francesco Chicchiriccò commented on CXF-7670: - The PR #388 introduced some regression, as described in the linked ML thread. > synthetic methods: equal candidates for handling the current request > > > Key: CXF-7670 > URL: https://issues.apache.org/jira/browse/CXF-7670 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.2.1, 3.2.2 > Environment: I have noticed this with kotlin projects. >Reporter: Laszlo Hornyak >Priority: Major > > When discovering JAX-RS annotations, CXF does not filter out synthetic > methods. If the compiler have created any synthetic methods out of the > annotated methods, it will store them as JAX-RS resource methods with > actually the same annotated method. > After startup, CXF will log each invocation on the duplicated resource > methods with a warning, which reduces performance, and generates quite some > log. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7680) Restrict the size of SOAP message OR allow only MTOM messages
[
https://issues.apache.org/jira/browse/CXF-7680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16407549#comment-16407549
]
Nicholas commented on CXF-7680:
---
[~coheigea]
Here is test case:
Server - https://gist.github.com/iliakp/168437e74be19349eb1a5f8be16ac97d
Client - https://gist.github.com/iliakp/8aa51930be9dc94d9f00dfa8c8100796
I copied two fragments in client: one with mtom and one without it.
on the server I have setted System property
System.setProperty("org.apache.cxf.stax.maxXMLCharacters", "2");
to avoid non-mtom incoming requests with possibly very large xml data. So if
client decides to embed 500MB b64 encoded file in xml it will definitely exceed
2 characters and throw exception.
I was asking if this was the "right" way to do this limitation...
> Restrict the size of SOAP message OR allow only MTOM messages
> -
>
> Key: CXF-7680
> URL: https://issues.apache.org/jira/browse/CXF-7680
> Project: CXF
> Issue Type: Wish
> Components: JAX-WS Runtime, Soap Binding
>Affects Versions: 3.2.2
>Reporter: Nicholas
>Priority: Critical
> Labels: performance, security
>
> I encountered this problem, but couldn't get any help, although hours of
> searching...
> I am developing B2B web services.
> Service is receiving SOAP request where file attachments are encoded in
> base64 format, application works well, except if one of the client decides to
> send very large XML - possibly 500MB of XML data, at this very point my
> application's java heap size grows exponentially and mostly throw
> OutOfMemoryException. So I decided to use MTOM mechanism to send and receive
> messages with large(or several) attachments, application performs well,
> memory-wise, but there is still another problem, server and client, BOTH need
> to enable MTOM messaging, even if it is enabled on server, client can send it
> still with base64 format and server receives without any worries until
> aformentioned exception is thrown. Anyone can create a HUGE xml message that
> can crash my app in seconds. How can I secure my application from these kind
> of malicious service calls.
> Searched a lot, but couldn't find virtually any reliable solution for this.
> So question/problem/wish is:
> 1) How can I restrict the size of SOAP message (only XML part if MTOM).
> OR
> 2) How can I allow only MTOM messages.
> What I found/explored:
> [http://cxf.apache.org/docs/security.html] in the "Controlling Large Request
> Payloads" section there is written about Woodstox parser which can be used to
> restrict XML message by its character sizes, but also written that it's not
> recommended and it's insecure. Even if this was the solution, how would it
> behave in MTOM message.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
