[jira] [Commented] (CXF-8951) Concurrent WebClient usage causes massive thread overhead
[ https://issues.apache.org/jira/browse/CXF-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780390#comment-17780390 ] Daniel Kulp commented on CXF-8951: -- Please re-try with 4.0.4-SNAPSHOT. I believe the thread leak is now fixed. > Concurrent WebClient usage causes massive thread overhead > - > > Key: CXF-8951 > URL: https://issues.apache.org/jira/browse/CXF-8951 > Project: CXF > Issue Type: Bug > Components: Core, JAX-RS >Affects Versions: 3.6.2, 4.0.3 >Reporter: Lars Ködderitzsch >Priority: Major > Attachments: cxf-connector-threads.zip > > > Concurrent usage of Webclients causes massively more threads to be created in > cxf-3.6.x/4.x than before. > Supposedly this results from introducing a new conduit implementation based > on the "new" java http client compared to HttpUrlConnection before. > It seems that a new http client is created per requesting thread - and each > http client in turn creates an own pool of selector/worker threads. > To demonstate I've attached a test project with several methods to test > different scenarios. > Each tests launches a simple JAX-RS Server, configures/uses WebClients in > different configuration and submits 1000 requests via up to 100 parrallel > requestor threads. > The number of live threads in the JVM instance if printed after each request. > Baseline is the number of threads used by the server instance + the 100 > requesting threads. > > singleClientInstanceWithNewConduit -> reuses a threadsafe client instance, > thread count rises to 700+ live threads > singleClientInstanceWithOldConduit -> reuses a threadsafe client instance, > stays at about 200 threads > clientPerRequestWithOldConduit -> creates a client instance per request > (no closing!), keeps below 200 threads > clientPerRequestWithNewConduit -> creates a client instance per request > (no closing!), creates a runaway thread leak (!) > clientPerRequestWithNewConduit is additionally interesting because current > documentation is not clear about whether client instances > are required to be resource managed or not. > It appears that closing clients was not required up until cxf-3.6.0 and > documentation actively encourages creating new "lightweight" client instances > on the fly (see Thread safety in > [https://cxf.apache.org/docs/jax-rs-client-api.html]). > However, cxf-3.6+ implementation (and comments in CXF-8885) seem to suggest > that clients are in fact *not lightweight* (anymore?) but need to be closed, > when no longer used. > But then in turn WebClient/Client does not even implement > Closeable/Autoclosable. So, it's all quite muddy - and there doesn't seem to > be a real consensus on the idiomatic usage of Webclients. > It would be very nice if you could bring some clarity on this as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8950) HttpClient in CXF closing prematurely; 4.0.4-SNAPSHOT
[
https://issues.apache.org/jira/browse/CXF-8950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17779590#comment-17779590
]
Daniel Kulp commented on CXF-8950:
--
Discussing this with [~reta], we don't believe this is a valid bug. You are
specifically closing the client (in the try with resources block) but then
continuing to use objects (the Response) that are expecting the client to still
be open/connected.You need to be fully done with the client prior to
calling close (or don't call close and allow the garbage collector to clean it
up, but that would not be deterministic as to when that would happen). Or
re-use the clients (which would have other benefits with keep-alives, http/2,
etc..).
When closing the client, all resources associated with that client are no
longer valid. You would definitely need to fully consume the entity prior to
closing the client.
> HttpClient in CXF closing prematurely; 4.0.4-SNAPSHOT
> -
>
> Key: CXF-8950
> URL: https://issues.apache.org/jira/browse/CXF-8950
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 4.0.3, 4.0.4
>Reporter: Sebastian Violet
>Assignee: Daniel Kulp
>Priority: Critical
> Fix For: 3.6.3, 4.0.4
>
> Attachments: CXF-HTTPClient-LargePayload.zip
>
>
> When processing requests using the JAX RS client which used the new
> HttpClient, there is the input stream is closed prematurely.
>
> [^CXF-HTTPClient-LargePayload.zip] , you will see that we are using
> {*}Response{*}, because we are interested in getting response status as well
> as the response headers. This fails with the following error:
> {code:java}
> Exception in thread "main" java.lang.RuntimeException: java.io.IOException:
> closed
> at LargeDataTester.main(LargeDataTester.java:89)
> Caused by: java.io.IOException: closed
> at
> java.net.http/jdk.internal.net.http.ResponseSubscribers$HttpResponseInputStream.current(ResponseSubscribers.java:448)
> at
> java.net.http/jdk.internal.net.http.ResponseSubscribers$HttpResponseInputStream.read(ResponseSubscribers.java:508)
> at java.base/java.io.FilterInputStream.read(FilterInputStream.java:119)
> at
> org.apache.cxf.transport.http.HttpClientHTTPConduit$HttpClientFilteredInputStream.read(HttpClientHTTPConduit.java:422)
> at
> java.base/java.io.SequenceInputStream.read(SequenceInputStream.java:197)
> at java.base/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:333)
> at java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:376)
> at java.base/sun.nio.cs.StreamDecoder.lockedRead(StreamDecoder.java:219)
> at java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:173)
> at java.base/java.io.InputStreamReader.read(InputStreamReader.java:189)
> at java.base/java.io.Reader.read(Reader.java:265)
> at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1610)
> at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1589)
> at org.apache.commons.io.IOUtils.copy(IOUtils.java:1384)
> at org.apache.commons.io.IOUtils.copy(IOUtils.java:1153)
> at org.apache.commons.io.IOUtils.toString(IOUtils.java:3105)
> at LargeDataTester.main(LargeDataTester.java:84)
> Caused by: java.io.IOException: selector manager closed
> at
> java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.selectorClosedException(HttpClientImpl.java:1061)
> at
> java.net.http/jdk.internal.net.http.HttpClientImpl.closeSubscribers(HttpClientImpl.java:552)
> at
> java.net.http/jdk.internal.net.http.HttpClientImpl.stop(HttpClientImpl.java:543)
> at
> java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.shutdown(HttpClientImpl.java:1165)
> at
> java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.run(HttpClientImpl.java:1364)
> {code}
>
> {color:#FF}*You can execute the code like so:*{color}
> {code:java}
> mvn compile exec:exec{code}
> ℹ️ {*}Note{*}: You can do a diff between what works(Letting CXF deserialize
> the object response payload automatically), and the last commit(Using
> Response).
> {code:java}
> git diff HEAD^ HEAD {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8946) HttpClient in CXF causing memory leak
[
https://issues.apache.org/jira/browse/CXF-8946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-8946.
--
Fix Version/s: 3.6.3
4.0.4
Assignee: Daniel Kulp
Resolution: Fixed
> HttpClient in CXF causing memory leak
> -
>
> Key: CXF-8946
> URL: https://issues.apache.org/jira/browse/CXF-8946
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 4.0.3
>Reporter: Sebastian Violet
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: 3.6.3, 4.0.4
>
> Attachments: CXF-HTTPClient-MemoryLeak.zip, Screenshot 2023-10-19 at
> 2.29.56 PM.png, call_mem_leak.sh, java_pid17394.hprof.zip,
> java_pid17394_Leak_Suspects.zip, java_pid91652.0001.hprof.zip,
> java_pid91652.0001_Leak_Suspects.zip, memory-leak-demo.zip, screenshot-1.png,
> screenshot-2.png
>
>
> When processing requests using the JAX RS client which used the new
> HttpClient, there is a memory leak.
> We found this when running it in spring boot using
> {code:java}
> @Async{code}
>
> I have tried to reproduce it using the attached code, and it seems to work
> with a low heap size.
>
> You can execute the code like so:
> {code:java}
> mvn compile exec:exec{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8946) HttpClient in CXF causing memory leak
[
https://issues.apache.org/jira/browse/CXF-8946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1508#comment-1508
]
Daniel Kulp commented on CXF-8946:
--
{code:xml}
apache.snapshots
https://repository.apache.org/snapshots/
Apache Snapshot Repo
true
false
{code}
> HttpClient in CXF causing memory leak
> -
>
> Key: CXF-8946
> URL: https://issues.apache.org/jira/browse/CXF-8946
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 4.0.3
>Reporter: Sebastian Violet
>Priority: Major
> Attachments: CXF-HTTPClient-MemoryLeak.zip, Screenshot 2023-10-19 at
> 2.29.56 PM.png, call_mem_leak.sh, java_pid17394.hprof.zip,
> java_pid17394_Leak_Suspects.zip, java_pid91652.0001.hprof.zip,
> java_pid91652.0001_Leak_Suspects.zip, memory-leak-demo.zip
>
>
> When processing requests using the JAX RS client which used the new
> HttpClient, there is a memory leak.
> We found this when running it in spring boot using
> {code:java}
> @Async{code}
>
> I have tried to reproduce it using the attached code, and it seems to work
> with a low heap size.
>
> You can execute the code like so:
> {code:java}
> mvn compile exec:exec{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8946) HttpClient in CXF causing memory leak
[
https://issues.apache.org/jira/browse/CXF-8946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1496#comment-1496
]
Daniel Kulp commented on CXF-8946:
--
I have no idea how to use your second demo. "mvn test" runs fine and nothing
fails or memory dumps or anything with 4.0.3.
Your first one from yesterday is now fixed. Had it running for 40 minutes
this afternoon while running the rest of the CXF tests before pushing the
changes. I'll deploy a 4.0.4-SNAPSHOT. Should be available in 20m or so if
you want to test with that.
That all said, as I alluded to, you SHOULD be either (a) closing the
StatusClient service when done with it to let it release things immediately, or
(b) (likely preferable) Reusing the StatusClient. Creating a
JAXRSClientFactory and the client is a very heavyweight process.
> HttpClient in CXF causing memory leak
> -
>
> Key: CXF-8946
> URL: https://issues.apache.org/jira/browse/CXF-8946
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 4.0.3
>Reporter: Sebastian Violet
>Priority: Major
> Attachments: CXF-HTTPClient-MemoryLeak.zip, Screenshot 2023-10-19 at
> 2.29.56 PM.png, java_pid17394.hprof.zip, java_pid17394_Leak_Suspects.zip,
> java_pid91652.0001.hprof.zip, java_pid91652.0001_Leak_Suspects.zip,
> memory-leak-demo.zip
>
>
> When processing requests using the JAX RS client which used the new
> HttpClient, there is a memory leak.
> We found this when running it in spring boot using
> {code:java}
> @Async{code}
>
> I have tried to reproduce it using the attached code, and it seems to work
> with a low heap size.
>
> You can execute the code like so:
> {code:java}
> mvn compile exec:exec{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8946) HttpClient in CXF causing memory leak
[
https://issues.apache.org/jira/browse/CXF-8946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1301#comment-1301
]
Daniel Kulp commented on CXF-8946:
--
Just adding some notes while investigating
If the service client is properly closed, it goes forever. That's good news:
{code:java}
@Override
public String status() {
final StatusService service = JAXRSClientFactory.create(this.apiUrl,
StatusService.class,
Collections.singletonList(new GsonJsonProvider()));
try (AutoCloseable c = (AutoCloseable)service) {
final ClientConfiguration config = WebClient.getConfig(service);
final Slf4jVerboseEventSender slf4jVerboseEventSender = new
Slf4jVerboseEventSender();
config.getInInterceptors().add(new
LoggingInInterceptor(slf4jVerboseEventSender));
config.getOutInterceptors().add(new
LoggingOutInterceptor(slf4jVerboseEventSender));
return service.status();
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
return null;
}
}
{code}
Also, if I update the sleep() method to add four calls to System.gc(), it also
runs forever. (three is not enough) Thus, the references ARE being released
eventually. It's just taking a lot longer that it should. Not sure why yet.
Still Investigating.
> HttpClient in CXF causing memory leak
> -
>
> Key: CXF-8946
> URL: https://issues.apache.org/jira/browse/CXF-8946
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 4.0.3
>Reporter: Sebastian Violet
>Priority: Major
> Attachments: CXF-HTTPClient-MemoryLeak.zip, java_pid17394.hprof.zip,
> java_pid17394_Leak_Suspects.zip, memory-leak-demo.zip
>
>
> When processing requests using the JAX RS client which used the new
> HttpClient, there is a memory leak.
> We found this when running it in spring boot using
> {code:java}
> @Async{code}
>
> I have tried to reproduce it using the attached code, and it seems to work
> with a low heap size.
>
> You can execute the code like so:
> {code:java}
> mvn compile exec:exec{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8896) http client sends some strange HTTP/1.1 and HTTP/2 mix headers
[
https://issues.apache.org/jira/browse/CXF-8896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-8896.
--
Fix Version/s: (was: 4.1.0)
Resolution: Not A Problem
> http client sends some strange HTTP/1.1 and HTTP/2 mix headers
> --
>
> Key: CXF-8896
> URL: https://issues.apache.org/jira/browse/CXF-8896
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.2
>Reporter: Jim Ma
>Priority: Major
> Fix For: 4.0.3
>
>
> From CXF 4.0.1, without the force http version with
>
> {code:java}
> ((BindingProvider)port).getRequestContext().put("org.apache.cxf.transport.http.forceVersion",
> "1.1"), {code}
> The http client sends request with strange headers :
> {code:java}
> POST /jaxws-securityDomain2/authz HTTP/1.1
> Connection: Upgrade, HTTP2-Settings
> Content-Length: 207
> Host: 127.0.0.1:23088
> HTTP2-Settings: AAEAAEIBAAMAAABkAAQBAAUAAEAA
> Upgrade: h2c
> Accept: */*
> Content-Type: text/xml; charset=UTF-8
> SOAPAction: ""
> User-Agent: Apache-CXF/4.0.1 {code}
> This works in CXF 4.0.0 and this commit seems introduce issue:
> [https://github.com/apache/cxf/commit/9b36a4bc996615e0ed02795c74167586a2bb11df]
>
> If force the HTTP/1.1 with property :
> org.apache.cxf.transport.http.forceVersion , it works. But this is a backward
> compatible issue and we should still support HTTP/1.1 by default.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8918) Upgrade xnio-nio jar to latest version (3.8.8+) to get rid of CVE-2022-0084
[ https://issues.apache.org/jira/browse/CXF-8918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-8918. -- Fix Version/s: 3.6.2 Assignee: Daniel Kulp Resolution: Fixed > Upgrade xnio-nio jar to latest version (3.8.8+) to get rid of CVE-2022-0084 > > > Key: CXF-8918 > URL: https://issues.apache.org/jira/browse/CXF-8918 > Project: CXF > Issue Type: Bug >Affects Versions: 3.5.6 >Reporter: Dhoka Pramod >Assignee: Daniel Kulp >Priority: Major > Fix For: 3.5.7, 3.6.2 > > > Upgrade xnio-nio jar to latest version (3.8.8+) to get rid of CVE-2022-0084 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8926) MTOM - Lock while processing attachment
[
https://issues.apache.org/jira/browse/CXF-8926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17763184#comment-17763184
]
Daniel Kulp commented on CXF-8926:
--
I BELIEVE this is already fixed. (CXF-8895) It would be great if you could
double check with the latest snapshots. We're hoping to do a new release next
week and I'd love to verify that this is fixed.
> MTOM - Lock while processing attachment
> ---
>
> Key: CXF-8926
> URL: https://issues.apache.org/jira/browse/CXF-8926
> Project: CXF
> Issue Type: Bug
>Reporter: wilfried
>Priority: Major
>
> I'm currently implementing a SOAP client to send document with CXF 4.0.1 (the
> application is quarkus based).
> My client is working fine when firewall is open between my machine and the
> target server, but in case firewall is closed (for QA environment for
> example), I was expecting to get a timeout, but it's not the case. The SOAP
> client stops its execution to the interceptor *AttachmentOutEndingInterceptor
> *and waits indefinitely.
> After profiling the application, I found out a lock as shown by the below
> thread dump:
> {code:java}
> "executor-thread-2" #296 daemon prio=5 os_prio=0 cpu=31.25ms elapsed=201.04s
> tid=0x019f9cd475d0 nid=0x5cf8 in Object.wait() [0x009645dfe000]
>java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(java.base@17.0.2/Native Method)
> - waiting on
> at
> java.io.PipedInputStream.awaitSpace(java.base@17.0.2/PipedInputStream.java:273)
> at
> java.io.PipedInputStream.receive(java.base@17.0.2/PipedInputStream.java:231)
> - locked <0x000613854b08> (a java.io.PipedInputStream)
> at
> java.io.PipedOutputStream.write(java.base@17.0.2/PipedOutputStream.java:150)
> at
> org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:51)
> at
> org.apache.cxf.io.AbstractThresholdOutputStream.write(AbstractThresholdOutputStream.java:69)
> at
> org.apache.cxf.io.CacheAndWriteOutputStream.write(CacheAndWriteOutputStream.java:81)
> at jakarta.activation.DataHandler.writeTo(DataHandler.java:283)
> at
> org.apache.cxf.attachment.AttachmentSerializer.writeAttachments(AttachmentSerializer.java:318)
> at
> org.apache.cxf.interceptor.AttachmentOutInterceptor$AttachmentOutEndingInterceptor.handleMessage(AttachmentOutInterceptor.java:126)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> - locked <0x000613856e30> (a
> org.apache.cxf.phase.PhaseInterceptorChain)
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:528)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:439)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:354)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:312)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:140)
> at jdk.proxy7.$Proxy235.addMessage(jdk.proxy7/Unknown Source)
> at
> lu.etat.ci.fwt.soap.SOAPTestController.callSaySomethingMtomSecuredCIDUT(SOAPTestController.java:138)
> at
> lu.etat.ci.fwt.soap.SOAPTestController$quarkusrestinvoker$callSaySomethingMtomSecuredCIDUT_1b14f2d5ed1a4d42c824e7582903a9f19063cae3.invoke(Unknown
> Source)
> at
> org.jboss.resteasy.reactive.server.handlers.InvocationHandler.handle(InvocationHandler.java:29)
> at
> io.quarkus.resteasy.reactive.server.runtime.QuarkusResteasyReactiveRequestContext.invokeHandler(QuarkusResteasyReactiveRequestContext.java:141)
> at
> org.jboss.resteasy.reactive.common.core.AbstractResteasyReactiveContext.run(AbstractResteasyReactiveContext.java:145)
> at
> io.quarkus.vertx.core.runtime.VertxCoreRecorder$14.runWith(VertxCoreRecorder.java:576)
> at
> org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2513)
> at
> org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1512)
> at
> org.jboss.threads.DelegatingRunnable.run(DelegatingRunnable.java:29)
> at
> org.jboss.threads.ThreadLocalResettingRunnable.run(ThreadLocalResettingRunnable.java:29)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(java.base@17.0.2/Thread.java:833)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8924) Make Wsdl2Java generate code in a deterministic way for reproducible builds
[ https://issues.apache.org/jira/browse/CXF-8924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17763080#comment-17763080 ] Daniel Kulp commented on CXF-8924: -- I've started a vote in WebServices for the XmlSchema release. Hope to be able to pick that up next week. > Make Wsdl2Java generate code in a deterministic way for reproducible builds > --- > > Key: CXF-8924 > URL: https://issues.apache.org/jira/browse/CXF-8924 > Project: CXF > Issue Type: Improvement >Affects Versions: 4.0.1 >Reporter: Bjørn Mølgård Vester >Assignee: Daniel Kulp >Priority: Minor > > When you run the wsdl2java tool on a collection of schemas, it will generate > a class "ObjectFactory" with method names taken from the schemas. > Currently, the order of these methods is not predictable as it depends on the > hash code of the absolute file path to the schemas. The file paths may change > depending on where you have, for instance, checked out the code. It is also > normal for a CI server to check out code in folders named after the branch or > pull request. > Besides the benefits of having [reproducible > builds|[https://reproducible-builds.org/],] for us, it also breaks our build > cache that fingerprints the input schemas and the generated code that may > differ depending on where it was built. This causes cache misses that again > lead to unnecessary long build times. > The issue arises in the class SchemaCollection. Here, schemas are added to a > class XmlSchemaCollection from the xmlschema-core Apache project, with a > system ID that includes the absolute file path to the schema. The schemas are > later returned ordered by the hash code of the system ID (among other > things), which changes depending on the paths. > This issue can be fixed either in CXF by not using full paths for system IDs, > by sorting the schemas during code generation by name and namespace for > instance, or finally, it can be solved by letting XmlSchemaCollection return > schemas in the same order as they were added. I think the latter is the most > elegant solution, so I've opened an issue for that project and submitted a > PR: https://issues.apache.org/jira/browse/XMLSCHEMA-65. > If that PR is accepted and a new version is released, I would like CXF to > update to that version. If not, it would be great if a fix could be made to > CXF itself. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-8924) Make Wsdl2Java generate code in a deterministic way for reproducible builds
[ https://issues.apache.org/jira/browse/CXF-8924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp reassigned CXF-8924: Assignee: Daniel Kulp > Make Wsdl2Java generate code in a deterministic way for reproducible builds > --- > > Key: CXF-8924 > URL: https://issues.apache.org/jira/browse/CXF-8924 > Project: CXF > Issue Type: Improvement >Affects Versions: 4.0.1 >Reporter: Bjørn Mølgård Vester >Assignee: Daniel Kulp >Priority: Minor > > When you run the wsdl2java tool on a collection of schemas, it will generate > a class "ObjectFactory" with method names taken from the schemas. > Currently, the order of these methods is not predictable as it depends on the > hash code of the absolute file path to the schemas. The file paths may change > depending on where you have, for instance, checked out the code. It is also > normal for a CI server to check out code in folders named after the branch or > pull request. > Besides the benefits of having [reproducible > builds|[https://reproducible-builds.org/],] for us, it also breaks our build > cache that fingerprints the input schemas and the generated code that may > differ depending on where it was built. This causes cache misses that again > lead to unnecessary long build times. > The issue arises in the class SchemaCollection. Here, schemas are added to a > class XmlSchemaCollection from the xmlschema-core Apache project, with a > system ID that includes the absolute file path to the schema. The schemas are > later returned ordered by the hash code of the system ID (among other > things), which changes depending on the paths. > This issue can be fixed either in CXF by not using full paths for system IDs, > by sorting the schemas during code generation by name and namespace for > instance, or finally, it can be solved by letting XmlSchemaCollection return > schemas in the same order as they were added. I think the latter is the most > elegant solution, so I've opened an issue for that project and submitted a > PR: https://issues.apache.org/jira/browse/XMLSCHEMA-65. > If that PR is accepted and a new version is released, I would like CXF to > update to that version. If not, it would be great if a fix could be made to > CXF itself. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8895) Deadlock instead of timeout with new HttpClientHTTPConduit using large payloads
[
https://issues.apache.org/jira/browse/CXF-8895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762570#comment-17762570
]
Daniel Kulp commented on CXF-8895:
--
Sorry, should be 4.0.3 and 3.6.2. It was fixed the end of June in:
https://github.com/apache/cxf/commit/1e9e61a3765318c7706a1886733fd45fe2f2f977
> Deadlock instead of timeout with new HttpClientHTTPConduit using large
> payloads
> ---
>
> Key: CXF-8895
> URL: https://issues.apache.org/jira/browse/CXF-8895
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.6.0, 3.6.1, 3.6.2
>Reporter: Manuel
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: 3.6.2, 4.0.3
>
> Attachments: GreetMeDocLiteralReq.xml
>
>
> Hello,
>
> we discovered an issue that causes a deadlock with large payloads which
> exceed the chunk-length (that is used as buffer size for an
> {{{}PipedInputStream{}}}) when sending a message to a currently
> offline/not-available server.
> Even when setting the {{ConnectionTimeout}} for the HTTPConduit to e.g.,
> 1000ms, the timeout does not occur. (the {{ReceiveTimeout}} works as expected
> though)
> The feature that introduced the new {{HttpClientHTTPConduit}} was CXF-8840
> with commit
> [1e7169|https://github.com/apache/cxf/commit/1e7169c627d6908118f99dc98d774ffb53dd38c6].
>
> What was {*}expected{*}:
> Any type of timeout-related exception.
>
> What *actually* happened:
> The thread runs into a deadlock.
>
> How to {*}reproduce{*}:
> Run
> {{org.apache.cxf.systest.dispatch.DispatchClientServerTest.testTimeout()}}
> and increase the payload of {{resources/GreetMeDocLiteralReq.xml}} (or use
> the attachment provided). The test will not terminate after the given
> timeout, the test will run indefinitely.
> The {{{}PipedInputStream{}}}'s read method was never called (server offline),
> hence the {{{}PipedOutputStream{}}}'s write method can't continue to write
> the data -> Deadlock.
>
> {{Regards,}}
> {{Manuel}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8895) Deadlock instead of timeout with new HttpClientHTTPConduit using large payloads
[
https://issues.apache.org/jira/browse/CXF-8895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated CXF-8895:
-
Fix Version/s: 3.6.2
4.0.3
(was: 4.0.2)
(was: 3.6.1)
> Deadlock instead of timeout with new HttpClientHTTPConduit using large
> payloads
> ---
>
> Key: CXF-8895
> URL: https://issues.apache.org/jira/browse/CXF-8895
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.6.0, 3.6.1, 3.6.2
>Reporter: Manuel
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: 3.6.2, 4.0.3
>
> Attachments: GreetMeDocLiteralReq.xml
>
>
> Hello,
>
> we discovered an issue that causes a deadlock with large payloads which
> exceed the chunk-length (that is used as buffer size for an
> {{{}PipedInputStream{}}}) when sending a message to a currently
> offline/not-available server.
> Even when setting the {{ConnectionTimeout}} for the HTTPConduit to e.g.,
> 1000ms, the timeout does not occur. (the {{ReceiveTimeout}} works as expected
> though)
> The feature that introduced the new {{HttpClientHTTPConduit}} was CXF-8840
> with commit
> [1e7169|https://github.com/apache/cxf/commit/1e7169c627d6908118f99dc98d774ffb53dd38c6].
>
> What was {*}expected{*}:
> Any type of timeout-related exception.
>
> What *actually* happened:
> The thread runs into a deadlock.
>
> How to {*}reproduce{*}:
> Run
> {{org.apache.cxf.systest.dispatch.DispatchClientServerTest.testTimeout()}}
> and increase the payload of {{resources/GreetMeDocLiteralReq.xml}} (or use
> the attachment provided). The test will not terminate after the given
> timeout, the test will run indefinitely.
> The {{{}PipedInputStream{}}}'s read method was never called (server offline),
> hence the {{{}PipedOutputStream{}}}'s write method can't continue to write
> the data -> Deadlock.
>
> {{Regards,}}
> {{Manuel}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8895) Deadlock instead of timeout with new HttpClientHTTPConduit using large payloads
[
https://issues.apache.org/jira/browse/CXF-8895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-8895.
--
Fix Version/s: 4.0.2
3.6.1
Assignee: Daniel Kulp
Resolution: Fixed
> Deadlock instead of timeout with new HttpClientHTTPConduit using large
> payloads
> ---
>
> Key: CXF-8895
> URL: https://issues.apache.org/jira/browse/CXF-8895
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.6.0, 3.6.1, 3.6.2
>Reporter: Manuel
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: 4.0.2, 3.6.1
>
> Attachments: GreetMeDocLiteralReq.xml
>
>
> Hello,
>
> we discovered an issue that causes a deadlock with large payloads which
> exceed the chunk-length (that is used as buffer size for an
> {{{}PipedInputStream{}}}) when sending a message to a currently
> offline/not-available server.
> Even when setting the {{ConnectionTimeout}} for the HTTPConduit to e.g.,
> 1000ms, the timeout does not occur. (the {{ReceiveTimeout}} works as expected
> though)
> The feature that introduced the new {{HttpClientHTTPConduit}} was CXF-8840
> with commit
> [1e7169|https://github.com/apache/cxf/commit/1e7169c627d6908118f99dc98d774ffb53dd38c6].
>
> What was {*}expected{*}:
> Any type of timeout-related exception.
>
> What *actually* happened:
> The thread runs into a deadlock.
>
> How to {*}reproduce{*}:
> Run
> {{org.apache.cxf.systest.dispatch.DispatchClientServerTest.testTimeout()}}
> and increase the payload of {{resources/GreetMeDocLiteralReq.xml}} (or use
> the attachment provided). The test will not terminate after the given
> timeout, the test will run indefinitely.
> The {{{}PipedInputStream{}}}'s read method was never called (server offline),
> hence the {{{}PipedOutputStream{}}}'s write method can't continue to write
> the data -> Deadlock.
>
> {{Regards,}}
> {{Manuel}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8914) No content-length header after upgrade CXF from 3.5.6 to 3.6.1
[ https://issues.apache.org/jira/browse/CXF-8914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762491#comment-17762491 ] Daniel Kulp commented on CXF-8914: -- Another option (and possibly the better option) is to set the ChunkingThreshold to something fairly high, but reasonable. If you know all your messages are under 10M, set it to 10M. With chunking completely turned off, the entire request message needs to be buffered to determine the content length prior to sending the data. The URLConnection does this automatically if chunking is turned off. However, one problem with this is that if you accidentally send a really large message, it will consume all the memory and then crash. If you keep chunking turned on, but set to a fairly high threshold, then as long as the messages are below the threshold, it can then set the Content-Length and send the message. This should work even with the newer conduit. However, once the threshold is reached, it "flushes" the buffer and starts streaming. Thus, it won't end up consuming all the memory. If the other server doesn't understand the chunking, it may not work and would generate an error, but at least your client is still running. > No content-length header after upgrade CXF from 3.5.6 to 3.6.1 > -- > > Key: CXF-8914 > URL: https://issues.apache.org/jira/browse/CXF-8914 > Project: CXF > Issue Type: Bug >Affects Versions: 3.6.1 > Environment: SpringBoot 2.7.13 >Reporter: Stephan Näcker >Priority: Major > Fix For: 3.6.2, 4.0.3 > > > After updating the CXF dependency in our application from 3.5.6 to 3.6.1 it > does not add a content-length header anymore, when doing a multipart request > for a file upload. > I didn't find any information, how to let CXF set the header. Is it just > dependent of chunking? > Actually the application sets "allow chunking" to false. But I'm not sure, > how I can test, if this really works. > Thanks in advance for your help. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8885) HttpClient SelectorManager threads run indefinitely causing OOM
[ https://issues.apache.org/jira/browse/CXF-8885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-8885. -- Fix Version/s: 3.6.2 4.0.3 Assignee: Daniel Kulp Resolution: Fixed > HttpClient SelectorManager threads run indefinitely causing OOM > --- > > Key: CXF-8885 > URL: https://issues.apache.org/jira/browse/CXF-8885 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 4.0.0, 3.6.0 >Reporter: Cardo Eggert >Assignee: Daniel Kulp >Priority: Major > Fix For: 3.6.2, 4.0.3 > > Attachments: image (5).png > > > Probably caused by https://issues.apache.org/jira/browse/CXF-8840 . > Started to notice that when updating from 3.5.x to 3.6.0 that our servers > started getting OOM. Noticed from the resulting logs that a lot of threads > were active that were in the format > HttpClient--SelectorManager > when reverted to 3.5.6 then it did not occur anymore. > > Tried to use VirtualVM when debugging it and saw when the thread was started, > it never died, basically meaning that it ran indefinitely. OOM happened when > there were about over 1000 of these threads. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8903) Too many open files error in HttpClientHTTPConduit
[
https://issues.apache.org/jira/browse/CXF-8903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-8903.
--
Fix Version/s: 3.6.2
Assignee: Daniel Kulp
Resolution: Fixed
> Too many open files error in HttpClientHTTPConduit
> --
>
> Key: CXF-8903
> URL: https://issues.apache.org/jira/browse/CXF-8903
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.2
>Reporter: Jim Ma
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: 3.6.2, 4.0.3, 4.1.0
>
>
> It seems there is resource leak in HttpClientHTTPConduit. When upgrade CXF to
> 4.0.2, the "lsof" shows there are many files open since it is changed to use
> JDK's HTTPClient.
> {code:java}
> Caused by: java.lang.InternalError: java.io.IOException: Too many open files
> at
> java.net.http/jdk.internal.net.http.HttpClientImpl.(HttpClientImpl.java:311)
> at
> java.net.http/jdk.internal.net.http.HttpClientImpl.create(HttpClientImpl.java:253)
> at
> java.net.http/jdk.internal.net.http.HttpClientBuilderImpl.build(HttpClientBuilderImpl.java:135)
> at
> org.apache.cxf.impl//org.apache.cxf.transport.http.HttpClientHTTPConduit.setupConnection(HttpClientHTTPConduit.java:231)
> at
> org.apache.cxf.impl//org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduit.setupConnection(AsyncHTTPConduit.java:190)
> at
> org.apache.cxf.impl//org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:529)
> at
> org.apache.cxf@4.0.2//org.apache.cxf.transport.TransportURIResolver.resolve(TransportURIResolver.java:133)
> at
> org.apache.cxf@4.0.2//org.apache.cxf.catalog.CatalogXmlSchemaURIResolver.resolveEntity(CatalogXmlSchemaURIResolver.java:66)
> at
> org.apache.ws.xmlschema//org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:682)
> at
> org.apache.ws.xmlschema//org.apache.ws.commons.schema.SchemaBuilder.handleImport(SchemaBuilder.java:536)
> at
> org.apache.ws.xmlschema//org.apache.ws.commons.schema.SchemaBuilder.handleSchemaElementChild(SchemaBuilder.java:1524)
> at
> org.apache.ws.xmlschema//org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:656)
> at
> org.apache.ws.xmlschema//org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:551)
> at
> org.apache.cxf@4.0.2//org.apache.cxf.common.xmlschema.SchemaCollection.read(SchemaCollection.java:129)
> at
> org.apache.cxf.impl//org.apache.cxf.wsdl11.SchemaUtil.extractSchema(SchemaUtil.java:145)
> at
> org.apache.cxf.impl//org.apache.cxf.wsdl11.SchemaUtil.getSchemas(SchemaUtil.java:74)
> at
> org.apache.cxf.impl//org.apache.cxf.wsdl11.SchemaUtil.getSchemas(SchemaUtil.java:66)
> at
> org.apache.cxf.impl//org.apache.cxf.wsdl11.SchemaUtil.getSchemas(SchemaUtil.java:61)
> at
> org.apache.cxf.impl//org.apache.cxf.wsdl11.WSDLServiceBuilder.getSchemas(WSDLServiceBuilder.java:378)
> at
> org.apache.cxf.impl//org.apache.cxf.wsdl11.WSDLServiceBuilder.buildServices(WSDLServiceBuilder.java:345)
> at
> org.apache.cxf.impl//org.apache.cxf.wsdl11.WSDLServiceBuilder.buildServices(WSDLServiceBuilder.java:209)
> at
> org.apache.cxf.impl//org.apache.cxf.wsdl11.WSDLServiceFactory.create(WSDLServiceFactory.java:161)
> at
> org.apache.cxf.impl//org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromWSDL(ReflectionServiceFactoryBean.java:407)
> at
> org.apache.cxf.impl//org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:527)
> at
> org.apache.cxf.impl//org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262)
> at
> org.apache.cxf.impl//org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
> at
> org.apache.cxf.impl//org.apache.cxf.jaxws.ServiceImpl.createPort(ServiceImpl.java:466)
> at
> org.jboss.ws.jaxws-client@7.0.0-SNAPSHOT//org.jboss.wsf.stack.cxf.client.ProviderImpl$JBossWSServiceImpl.createPort(ProviderImpl.java:580)
> at
> org.apache.cxf.impl//org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:342)
> at
> org.apache.cxf.impl//org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:337)
> at
> jakarta.xml.ws.api@1.0.0.Final//jakarta.xml.ws.Service.getPort(Service.java:210)
> at
> deployment.jaxws-cxf-jbws3713-client.war//org.jboss.test.ws.jaxws.cxf.jbws3713.HelperUsignThreadLocal$3.initialValue(HelperUsignThreadLocal.java:145)
> at
> deployment.jaxws-cxf-jbws3713-client.war//org.jboss.test.ws.jaxws.cxf.jbws3713.HelperUsignThreadLocal$3.initialValue(HelperUsignThreadLocal.java:139)
> at java.base/java.lang.ThreadLo
[jira] [Commented] (CXF-8923) HTTP/2 - Downgrade protocol with server that doesn't aceept HTTP/2 under HTTP
[
https://issues.apache.org/jira/browse/CXF-8923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17761959#comment-17761959
]
Daniel Kulp commented on CXF-8923:
--
FYI: the first message is NOT an HTTP/2 message. It's an HTTP/1.1 message with
the Upgrade header which is proper per HTTP/1.1 spec. That header allows
servers that CAN use HTTP/2 to upgrade if they can support it. A proper "HTTP
1.1 only" server would ignore that header as per HTTP 1.1 spec. That is a bug
in the server that the CXF client is hitting and a bug should be logged with
them.
> HTTP/2 - Downgrade protocol with server that doesn't aceept HTTP/2 under HTTP
> -
>
> Key: CXF-8923
> URL: https://issues.apache.org/jira/browse/CXF-8923
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.1
> Environment: * Client: Quarkus 3.1.0.Final (Quarkus CFX 2.1.0 -
> Apache CXF 4.0.1)
> * Server: SAP NetWeaver 7.5
>Reporter: Bruno
>Priority: Major
> Attachments: image-2023-09-01-12-01-31-850.png,
> image-2023-09-01-12-06-40-208.png
>
>
> h1. Problem
> When trying to consume a SOAP service with a server that doesn't accept
> HTTP/2 under HTTP, the Apache-CXF agent doesn't downgrade the protocol to
> resend the request with HTTP 1.1.
> h1. Context
> I'm trying to consume a SOAP service. The service is exposed via HTTP. The
> problem is that when consuming this service I get the following error:
> {code:java}
> Caused by: org.apache.cxf.transport.http.HTTPException: HTTP response '403:
> (POST
> http://productionServer/XISOAPAdapter/MessageServlet?senderParty=&senderService=BS_I4D_FI_100&receiverParty=&receiverService=&interface=SI_SAP_MaestroProveedores_sync_out&interfaceNamespace=http://imm.gub.uy/SAP/MaestroProveedores)
> 403' when communicating with
> http://productionServer/XISOAPAdapter/MessageServlet?senderParty=&senderService=BS_I4D_FI_100&receiverParty=&receiverService=&interface=SI_SAP_MaestroProveedores_sync_out&interfaceNamespace=http://imm.gub.uy/SAP/MaestroProveedores
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.doProcessResponseCode(HTTPConduit.java:1653)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1660)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1602)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1396)
> at
> org.apache.cxf.ext.logging.LoggingOutputStream.postClose(LoggingOutputStream.java:53)
> at
> org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:228)
> at
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at
> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:696)
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:63)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:528)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:439)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:354)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:312)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:140)
> ... 39 more
> {code}
> Further beyond the error, I used wireshark to access the request and
> response. The thing is that Apache is using HTTP/2 and the server doesn't
> accept this protocol, so it denys the request as we can see in this image:
> !image-2023-09-01-12-01-31-850.png|width=543,height=367!
> When I change the client to use HTTP 1.1, it works correctly:
> {code:java}
> Client client = ClientProxy.getClient(myService);
> HTTPConduit http = (HTTPConduit) client.getConduit();
> http.getClient().setVersion("1.1");
> {code}
> !image-2023-09-01-12-06-40-208.png|width=650,height=402!
> So, shouldn't it work just out of the box (the client negotating with the
> server) without changing the version to HTTP 1.1?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8896) http client sends some strange HTTP/1.1 and HTTP/2 mix headers
[
https://issues.apache.org/jira/browse/CXF-8896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17740589#comment-17740589
]
Daniel Kulp commented on CXF-8896:
--
It IS using HTTP 1.1 by default, but with the option to upgrade to HTTP/2.
The headers above are all valid HTTP 1.1 headers. If the server is rejecting
something in the above, that is a bug in the server, not CXF.
> http client sends some strange HTTP/1.1 and HTTP/2 mix headers
> --
>
> Key: CXF-8896
> URL: https://issues.apache.org/jira/browse/CXF-8896
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.2
>Reporter: Jim Ma
>Priority: Major
> Fix For: 4.0.3, 4.1.0
>
>
> From CXF 4.0.1, without the force http version with
>
> {code:java}
> ((BindingProvider)port).getRequestContext().put("org.apache.cxf.transport.http.forceVersion",
> "1.1"), {code}
> The http client sends request with strange headers :
> {code:java}
> POST /jaxws-securityDomain2/authz HTTP/1.1
> Connection: Upgrade, HTTP2-Settings
> Content-Length: 207
> Host: 127.0.0.1:23088
> HTTP2-Settings: AAEAAEIBAAMAAABkAAQBAAUAAEAA
> Upgrade: h2c
> Accept: */*
> Content-Type: text/xml; charset=UTF-8
> SOAPAction: ""
> User-Agent: Apache-CXF/4.0.1 {code}
> This works in CXF 4.0.0 and this commit seems introduce issue:
> [https://github.com/apache/cxf/commit/9b36a4bc996615e0ed02795c74167586a2bb11df]
>
> If force the HTTP/1.1 with property :
> org.apache.cxf.transport.http.forceVersion , it works. But this is a backward
> compatible issue and we should still support HTTP/1.1 by default.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8896) http client sends some strange HTTP/1.1 and HTTP/2 mix headers
[
https://issues.apache.org/jira/browse/CXF-8896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17740397#comment-17740397
]
Daniel Kulp commented on CXF-8896:
--
Those headers are correct and mark the request as upgradable to HTTP/2 if the
server supports it and allows it to work for both HTTP 1.1 and 2. Your PR
would remove this and thus would not upgrade to HTTP/2.
> http client sends some strange HTTP/1.1 and HTTP/2 mix headers
> --
>
> Key: CXF-8896
> URL: https://issues.apache.org/jira/browse/CXF-8896
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.2
>Reporter: Jim Ma
>Priority: Major
> Fix For: 4.0.3, 4.1.0
>
>
> From CXF 4.0.1, without the force http version with
>
> {code:java}
> ((BindingProvider)port).getRequestContext().put("org.apache.cxf.transport.http.forceVersion",
> "1.1"), {code}
> The http client sends request with strange headers :
> {code:java}
> POST /jaxws-securityDomain2/authz HTTP/1.1
> Connection: Upgrade, HTTP2-Settings
> Content-Length: 207
> Host: 127.0.0.1:23088
> HTTP2-Settings: AAEAAEIBAAMAAABkAAQBAAUAAEAA
> Upgrade: h2c
> Accept: */*
> Content-Type: text/xml; charset=UTF-8
> SOAPAction: ""
> User-Agent: Apache-CXF/4.0.1 {code}
> This works in CXF 4.0.0 and this commit seems introduce issue:
> [https://github.com/apache/cxf/commit/9b36a4bc996615e0ed02795c74167586a2bb11df]
>
> If force the HTTP/1.1 with property :
> org.apache.cxf.transport.http.forceVersion , it works. But this is a backward
> compatible issue and we should still support HTTP/1.1 by default.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8846) Get rid of EasyMock in cxf-rt-bindings-soap
[ https://issues.apache.org/jira/browse/CXF-8846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp updated CXF-8846: - Fix Version/s: (was: 4.0.2) (was: 3.6.2) > Get rid of EasyMock in cxf-rt-bindings-soap > --- > > Key: CXF-8846 > URL: https://issues.apache.org/jira/browse/CXF-8846 > Project: CXF > Issue Type: Sub-task >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8606) Introduce HTTP/2 Transport: client-side support
[ https://issues.apache.org/jira/browse/CXF-8606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-8606. -- Fix Version/s: 3.6.0 4.0.1 Assignee: Daniel Kulp (was: Andriy Redko) Resolution: Fixed This is now done on 3.6.0 and 4.0.1 by leveraging the HttpClient classes built into the JDK. Updates to optionally use Http Components can be done for a future version. > Introduce HTTP/2 Transport: client-side support > --- > > Key: CXF-8606 > URL: https://issues.apache.org/jira/browse/CXF-8606 > Project: CXF > Issue Type: Sub-task >Affects Versions: 3.4.5 >Reporter: Andriy Redko >Assignee: Daniel Kulp >Priority: Major > Fix For: 3.6.0, 4.0.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8606) Introduce HTTP/2 Transport: client-side support
[ https://issues.apache.org/jira/browse/CXF-8606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp updated CXF-8606: - Fix Version/s: (was: 3.6.0) (was: 4.0.1) > Introduce HTTP/2 Transport: client-side support > --- > > Key: CXF-8606 > URL: https://issues.apache.org/jira/browse/CXF-8606 > Project: CXF > Issue Type: Sub-task >Affects Versions: 3.4.5 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8799) Unxepected URLEncode in MTOM Content-Id
[
https://issues.apache.org/jira/browse/CXF-8799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-8799.
--
Resolution: Fixed
> Unxepected URLEncode in MTOM Content-Id
> ---
>
> Key: CXF-8799
> URL: https://issues.apache.org/jira/browse/CXF-8799
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.5.4, 3.4.9
>Reporter: Andriy Redko
>Priority: Major
> Fix For: 4.0.0, 3.6.0, 3.5.5, 3.4.10
>
>
> Commit
> https://github.com/apache/cxf/commit/ffba34eed2d5b4af22a93c100e4687e234d53b28#diff-e3efb80d0a98bbbd7f6eddd3c021c5fb5ab05ea2ee8d97dc68026f6345e5a509
> by @reta had changed how `Content-Id` is being dumped to headers.
> First of all, thank you for the bold point of doing this, referring to the
> RFCs.
> Let's have a look at the line 243 in particular
> Provided that `attachmentId` is of format `uuid@domain` it works as
> exepected, however, `attachmentId` is being generated by CXF in routine
> https://github.com/apache/cxf/blob/2ad9d0b2eef17c0d57d3cb96f3b2cecd1e704869/core/src/main/java/org/apache/cxf/attachment/AttachmentUtil.java#L230
> which results in `uuid@urn:xml:namespace` on some inputs.
> This input leads to the Header being URL encoded.
> Issues with this header are known for a while
> https://issues.apache.org/jira/browse/CXF-2669
> What's important is how do the SOAP servers treat URL-encoded `Content-Id`.
> In my experience, IRS.gov does not match
> {noformat}
> Content-ID:
> <3315f978-0190-4bc2-8a97-f766a78a7946-1@urn%3Aus%3Agov%3Atreasury%3Airs%3Acommon>
> with previously defined reference{noformat}
> {noformat}
> http://www.w3.org/2004/08/xop/include";
> href="cid:3315f978-0190-4bc2-8a97-f766a78a7946-1@urn%3Aus%3Agov%3Atreasury%3Airs%3Acommon"/>
> which is basically the same and _should_ match.{noformat}
> That said, it's well-known issue in the wild
> 1. https://access.redhat.com/solutions/2062163
> 2. https://access.redhat.com/solutions/4076871
> The latter points to the fact that there should be no URL-encoded symbols in
> `Content-Id`, which is met by @reta's commit.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8798) UDPDestination throws NPE under some conditions
[
https://issues.apache.org/jira/browse/CXF-8798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-8798.
--
Resolution: Fixed
> UDPDestination throws NPE under some conditions
> ---
>
> Key: CXF-8798
> URL: https://issues.apache.org/jira/browse/CXF-8798
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.5.4, 3.4.9
>Reporter: Andriy Redko
>Priority: Major
> Fix For: 4.0.0, 3.6.0, 3.5.5, 3.4.10
>
>
> {noformat}
> javax.xml.ws.WebServiceException: java.lang.NullPointerException
> at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:373)
> at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:255)
> at
> org.apache.cxf.ws.discovery.internal.WSDiscoveryServiceImpl.startup(WSDiscoveryServiceImpl.java:258)
> at
> org.apache.cxf.ws.discovery.internal.WSDiscoveryServiceImpl.serverStarted(WSDiscoveryServiceImpl.java:153)
> at
> org.apache.cxf.ws.discovery.listeners.WSDiscoveryServerListener.startServer(WSDiscoveryServerListener.java:73)
> at
> org.apache.cxf.bus.managers.ServerLifeCycleManagerImpl.startServer(ServerLifeCycleManagerImpl.java:61)
> at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:150)
> at
> org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:220)
> at
> org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211)
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.cxf.transport.udp.UDPDestination.findNetworkInterface(UDPDestination.java:205)
> at
> org.apache.cxf.transport.udp.UDPDestination.activate(UDPDestination.java:169)
> at
> org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:53)
> at
> org.apache.cxf.binding.AbstractBindingFactory.addListener(AbstractBindingFactory.java:95)
> at
> org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFactory.java:894)
> at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:130)
> at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:364)
> {noformat}
> * Protect against a null pointer when running on a Windows 11 PC on a
> corporate VPN
> * Null pointer caused by interface "TAP-Windows Adaptor V9
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8796) IllegalArgumentException: argument type mismatch with code first RPC when parameter omitted
[
https://issues.apache.org/jira/browse/CXF-8796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-8796.
--
Resolution: Fixed
> IllegalArgumentException: argument type mismatch with code first RPC when
> parameter omitted
> ---
>
> Key: CXF-8796
> URL: https://issues.apache.org/jira/browse/CXF-8796
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
>Affects Versions: 3.5.4
>Reporter: Alexander Ziubin
>Priority: Major
> Fix For: 3.5.5, 3.4.10
>
> Attachments: RpcSoapBindingArgumentTypeMismatch.zip, allocate.xml
>
>
> When migrating legacy code-first RPC Web application from Axis to CXF, I
> found an issue with SOAP binding. CXF is passing
> MessageContentsList.REMOVED_MARKER instead of absent parameter producing
> "argument type mismatch while invoking ... with params ... java.lang.Object"
> response faultstring and "java.lang.IllegalArgumentException: argument type
> mismatch" message in the log.
> {code:java}
> @WebService(targetNamespace = "http://test.apache.org/";)
> @SOAPBinding(style = javax.jws.soap.SOAPBinding.Style.RPC, use =
> javax.jws.soap.SOAPBinding.Use.LITERAL)
> public class SoapBindingArgumentTypeMismatch {
> public boolean allocate(Integer projectId,
> Integer[] targetIds,
> Integer[] parameterIds) {
> return targetIds == null;
> }
> }{code}
> Expected behavior of this sample Web service is to return true, when the
> targetIds parameter is absent in the SOAP request, but instead, CXF produces
> exception and fault response. Below is a sample SOAP request:
> {code:xml}
> http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:test="http://test.apache.org/";
> xmlns:SOAP-ENC = "http://schemas.xmlsoap.org/soap/encoding/";
> xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance";>
>
>
>
> 1
>
> 222
>
>
>
> {code}
> Everything else works as expected with CXF and this issue is the only
> blocker. I did some research and found that bean validation is also affected
> for both hibernate-validator and Apache bval bean validation providers.
> I verified the behavior with CXF 3.5.2 and 3.5.4, but it seems that other
> versions have this issue too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8796) IllegalArgumentException: argument type mismatch with code first RPC when parameter omitted
[
https://issues.apache.org/jira/browse/CXF-8796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated CXF-8796:
-
Fix Version/s: 3.5.5
3.4.10
> IllegalArgumentException: argument type mismatch with code first RPC when
> parameter omitted
> ---
>
> Key: CXF-8796
> URL: https://issues.apache.org/jira/browse/CXF-8796
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
>Affects Versions: 3.5.4
>Reporter: Alexander Ziubin
>Priority: Major
> Fix For: 3.5.5, 3.4.10
>
> Attachments: RpcSoapBindingArgumentTypeMismatch.zip, allocate.xml
>
>
> When migrating legacy code-first RPC Web application from Axis to CXF, I
> found an issue with SOAP binding. CXF is passing
> MessageContentsList.REMOVED_MARKER instead of absent parameter producing
> "argument type mismatch while invoking ... with params ... java.lang.Object"
> response faultstring and "java.lang.IllegalArgumentException: argument type
> mismatch" message in the log.
> {code:java}
> @WebService(targetNamespace = "http://test.apache.org/";)
> @SOAPBinding(style = javax.jws.soap.SOAPBinding.Style.RPC, use =
> javax.jws.soap.SOAPBinding.Use.LITERAL)
> public class SoapBindingArgumentTypeMismatch {
> public boolean allocate(Integer projectId,
> Integer[] targetIds,
> Integer[] parameterIds) {
> return targetIds == null;
> }
> }{code}
> Expected behavior of this sample Web service is to return true, when the
> targetIds parameter is absent in the SOAP request, but instead, CXF produces
> exception and fault response. Below is a sample SOAP request:
> {code:xml}
> http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:test="http://test.apache.org/";
> xmlns:SOAP-ENC = "http://schemas.xmlsoap.org/soap/encoding/";
> xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance";>
>
>
>
> 1
>
> 222
>
>
>
> {code}
> Everything else works as expected with CXF and this issue is the only
> blocker. I did some research and found that bean validation is also affected
> for both hibernate-validator and Apache bval bean validation providers.
> I verified the behavior with CXF 3.5.2 and 3.5.4, but it seems that other
> versions have this issue too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8702) Graceful shutdown : Error 404 with "Can't find the request for XXXXX's Observer" on - Springboot + CXF Server
[
https://issues.apache.org/jira/browse/CXF-8702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-8702.
--
Fix Version/s: 3.5.3
Assignee: Daniel Kulp
Resolution: Fixed
> Graceful shutdown : Error 404 with "Can't find the request for X's
> Observer" on - Springboot + CXF Server
> -
>
> Key: CXF-8702
> URL: https://issues.apache.org/jira/browse/CXF-8702
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.5.2
>Reporter: Thomas MAUGIN
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: 3.5.3
>
> Attachments: cxf-shutdown.zip, flood_requests.jmx
>
>
> h2. General Description :
> Issue happens on all our Springboot (tomcat) + CXF app.
> Spring boot version : 2.4.13 (same on 2.6.7) / CXF version : 3.5.1 (same on
> 3.4.4, 3.5.2)
> Java 1.8.0_312 and Java 11.0.15
>
> Integration is done with
> {{org.apache.cxf.cxf-spring-boot-starter-jaxrs-3.5.1.jar}} and
> {{org.apache.cxf.cxf-spring-boot-autoconfigure-3.5.1.jar}}
>
> On each graceful shutdown that is happening under a moderate load, a few
> requests are being rejected in 404 by the service.
> The corresponding log is {{"Can't find the request for X's Observer"}}
> X is the full request that has been rejected.
> The http response body answer for the call is {{No service was
> found.}}
> h2. Integration :
>
> CXF server is started like this :
>
> {code:java}
> @Bean
> public Server flowManagementServiceRsServer() {
> final JAXRSServerFactoryBean endpoint = new JAXRSServerFactoryBean();
> endpoint.setBus(bus);
> endpoint.setAddress("/");
> endpoint.setServiceBean(new Service());
> return endpoint.create();
> }
> {code}
>
> Shutdown is managed by spring boot with "new" graceful shutdown
> {{server.shutdown=graceful}} and
> {{spring.lifecycle.timeout-per-shutdown-phase=25s}}
>
> h2. Reproduction :
> Having a performance test on an endpoint (for example
> [http://localhost:8080/services/request]) and stopping gracefully, the app
> allow to reproduce the issue at will.
> See cxf-shutdown.zip project to reproduce.
>
> Use the following command just before trying to shutdown :
> {code:java}
> seq 1 2000 | xargs -I $ -n1 -P10 curl
> [http://127.0.0.1:8080/services/request]
> {code}
> Or see the JMeter project to do the same.
> h2. Logs and trace :
> {code:java}
>
> . _ __ _ _
> /
> / __{_}'{_} __ _ {_}({_})_ __ __ _ \ \ \ \
> ( ( )___ | '_ | '{_}| | '{_} \/ _` | \ \ \ \
>
> / __{_})| |{_})| | | | | || (_| | ) ) ) )
> ' |___{_}| .{_}{_}|{_}| |{_}|{_}| |{_}_{_}, | / / / /
> =|{_}|==|{_}_{_}/=/{_}/{_}/{_}/
> :: Spring Boot :: (v2.6.7)
> 2022-05-09 18:00:05.456 INFO 706858 — [ main]
> org.example.Application : Starting Application using Java
> 11.0.15 on LT-XXX with PID 706858
> (/home/user/workspace/git/cxf-shutdown/target/classes started by user in
> /home/user/workspace/git/cxf-shutdown)
> 2022-05-09 18:00:05.459 INFO 706858 — [ main]
> org.example.Application : No active profile set, falling
> back to 1 default profile: "default"
> 2022-05-09 18:00:06.719 INFO 706858 — [ main]
> o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat initialized with port(s):
> 8080 (http)
> 2022-05-09 18:00:06.728 INFO 706858 — [ main]
> o.apache.catalina.core.StandardService : Starting service [Tomcat]
> 2022-05-09 18:00:06.729 INFO 706858 — [ main]
> org.apache.catalina.core.StandardEngine : Starting Servlet engine: [Apache
> Tomcat/9.0.62]
> 2022-05-09 18:00:06.795 INFO 706858 — [ main]
> o.a.c.c.C.[Tomcat].[localhost].[/] : Initializing Spring embedded
> WebApplicationContext
> 2022-05-09 18:00:06.795 INFO 706858 — [ main]
> w.s.c.ServletWebServerApplicationContext : Root WebApplicationContext:
> initialization completed in 1285 ms
> 2022-05-09 18:00:07.042 INFO 706858 — [ main]
> org.apache.cxf.endpoint.ServerImpl : Setting the server's publish
> address to be /
> 2022-05-09 18:00:07.400 INFO 706858 — [ main]
> o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat started on port(s): 8080
> (http) with context path ''
> 2022-05-09 18:00:07.444 INFO 706858 — [ main]
> org.example.Application : Started Application in 2.393
> seconds (JVM running for 3.103)
> 2022-05-09 18:00:18.867 INFO 706858 — [ionShutdownHook]
> o.s.b.w.e.tomcat.GracefulShutdown : Commencing graceful shutdown.
> Waiting for active requests to complete
> 2022-05-09 18:00:18.867 WARN 706858 — [io-8080-exec-10]
[jira] [Updated] (CXF-8690) Refactor org.apache.cxf.common.util package
[
https://issues.apache.org/jira/browse/CXF-8690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated CXF-8690:
-
Fix Version/s: (was: 3.5.2)
> Refactor org.apache.cxf.common.util package
>
>
> Key: CXF-8690
> URL: https://issues.apache.org/jira/browse/CXF-8690
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.5.2
>Reporter: Fanyi
>Priority: Major
> Attachments: CXF-CachedClass-java.png,
> CXF-XmlSchemaPrimitiveUtils-java.png
>
>
> *Issue Description*
> Package *__ _org.apache.cxf.common.util_* __ is a promiscuous package, and
> groups together miscellaneous functionalities that might be useful to
> different subsystems. This means the cohesion between classes in the package
> is low. However, since the project has grown larger, this package structure
> is becoming increasingly hard to navigate. We found that Class
> _*CachedClass*_ and *_XmlSchemaPrimitiveUtils_* is not used by classes in
> their package _{*}org.apache.cxf.common.util{*}._ Moreover, there are
> dependencies between the above two classes and other packages.
> Location: The source file can be found at path File
> /core/src/main/java/org/apache/cxf/common/util/CachedClass.java
> /core/src/main/java/org/apache/cxf/common/util/XmlSchemaPrimitiveUtils.java
>
> *Refactoring suggestions*
>
> To avoid making *_org.apache.cxf.common.util_* too big and unmanageable, we
> suggest to move class *_CachedClass_* into package
> \{_}*org.apache.cxf.common.jaxb*{_},and move class
> *_XmlSchemaPrimitiveUtils_* into package
> *{_}org.apache.cxf.jaxrs.model.wadl{_}.*
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CXF-8641) NPE on NamePasswordCallbackHandler
[
https://issues.apache.org/jira/browse/CXF-8641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated CXF-8641:
-
Fix Version/s: 3.3.13
> NPE on NamePasswordCallbackHandler
> --
>
> Key: CXF-8641
> URL: https://issues.apache.org/jira/browse/CXF-8641
> Project: CXF
> Issue Type: Bug
> Components: Core
>Reporter: Jan Filipski
>Assignee: Freeman Yue Fang
>Priority: Major
> Fix For: 3.3.13, 3.4.6, 3.5.1, 4.0.0
>
>
> If Basic Auth password is empty, AbstractHTTPDestination sets password to
> null.
> Later, if NamePasswordCallbackHandler is used, it calls String.toCharArray()
> on null password.
> Standard authentication error should be present, without NullPointerException
> Stacktrace looks like that
> {code:java}
> org.apache.cxf.interceptor.security.AuthenticationException: Authentication
> failed: java.lang.NullPointerException
> at
> org.apache.cxf.interceptor.security.NamePasswordCallbackHandler.handle(NamePasswordCallbackHandler.java:67)
> at
> java.base/javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:904)
> at
> java.base/javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:901)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at
> java.base/javax.security.auth.login.LoginContext$SecureCallbackHandler.handle(LoginContext.java:901)
> at
> org.apache.karaf.jaas.modules.ldap.LDAPLoginModule.doLogin(LdapLoginModule.java:49)
> at
> org.apache.karaf.jaas.modules.ldap.LDAPLoginModule.login(LdapLoginModule.java:37)
> at
> org.apache.karaf.jaas.boot.ProxyLoginModule.login(ProxyLoginModule.java:83)
> at
> java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:726)
> at
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:665)
> at
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:663)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at
> java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:663)
> at
> java.base/javax.security.auth.login.LoginContext.login(LoginContext.java:574)
> at
> org.apache.cxf.interceptor.security.JAASLoginInterceptor.handleMessage(JAASLoginInterceptor.java:140)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
> at
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:225)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:301)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:220)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:276)
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:763)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1631)
> at
> org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:226)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1618)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:549)
> at
> org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:602)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1363)
> at
> org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:298)
> at
> or
[jira] [Commented] (CXF-8638) Website releases / downloads page has wrong version text
[ https://issues.apache.org/jira/browse/CXF-8638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17472872#comment-17472872 ] Daniel Kulp commented on CXF-8638: -- This should be fixed now. The website seems to be deployed again. > Website releases / downloads page has wrong version text > > > Key: CXF-8638 > URL: https://issues.apache.org/jira/browse/CXF-8638 > Project: CXF > Issue Type: Bug > Components: Documentation >Reporter: Eric Schwarzenbach >Assignee: Andriy Redko >Priority: Major > > No simple way to contact someone about basic mistrakes on the web site, so > this seems to be the easiest way to let someone know. > The paragraphs of text under 3.5 and 3.4 releases both list a version that > differs from the version in the heading. FFS. > https://cxf.apache.org/download.html -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CXF-8584) cxf-specs feature should use jakarta.mail instead of jakarta.mail-api
[
https://issues.apache.org/jira/browse/CXF-8584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated CXF-8584:
-
Fix Version/s: (was: 3.4.5)
(was: 3.3.12)
> cxf-specs feature should use jakarta.mail instead of jakarta.mail-api
> -
>
> Key: CXF-8584
> URL: https://issues.apache.org/jira/browse/CXF-8584
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Affects Versions: 3.4.4, 3.3.11
>Reporter: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 3.5.0
>
>
> In order to avoid conflict with camel features, {{cxf-specs}} feature should
> install {{jakarta.mail}} bundle instead of {{jakarta.mail-api}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CXF-8543) CXF SOAP 1.1 problem while 1.2 works
[
https://issues.apache.org/jira/browse/CXF-8543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-8543.
--
Fix Version/s: Invalid
Resolution: Not A Problem
Invalid WSDL for rpc/lit. Not a problem in CXF.
> CXF SOAP 1.1 problem while 1.2 works
>
>
> Key: CXF-8543
> URL: https://issues.apache.org/jira/browse/CXF-8543
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.4.3
>Reporter: Harri Pesonen
>Assignee: Freeman Yue Fang
>Priority: Major
> Fix For: Invalid
>
> Attachments: IciSystemService.wsdl
>
>
> I have a C# SOAP Service, and I generated CXF client (and server) from WSDL.
> Problem is that SOAP 1.1 port does not work in certain cases, while SOAP 1.2
> port seems to work always (but the C# service did not support SOAP 1.2
> originally, because SOAPAction is given differently).
> The error is:
> {code}
> org.apache.cxf.interceptor.Fault: Unmarshalling Error: unexpected element
> (uri:"urn:IciSystemInterface", local:"response").
> Expected elements are
> <\{urn:IciSystemInterface}message>,<\{urn:IciSystemInterface}productName>,<\{urn:IciSystemInterface}iciVersion>,<\{urn:IciSystemInterface}productVersion>,<\{urn:IciSystemInterface}iciMessageGroups>
>
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:931)
> {code}
> SOAP 1.1 payload is:
> {code}
>
> http://schemas.xmlsoap.org/soap/envelope/";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";>
>
>
>
>
> WicomOII
>
> IciGroupUser
> IciGroupTelephony
> IciGroupMessaging
> IciGroupChat
> IciGroupActionRouting
> IciGroupMonitoring
>
> 999.999.999.999
> 3.01
>
>
>
>
> {code}
> So there is extra node before , etc, and it
> fails on that. It does not expect to have . Similar payload works
> fine in SOAP 1.2 case:
> {code}
>
> http://www.w3.org/2003/05/soap-envelope";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";>
>
>
>
>
> WicomOII
>
> IciGroupUser
> IciGroupTelephony
> IciGroupMessaging
> IciGroupChat
> IciGroupActionRouting
> IciGroupMonitoring
>
> 999.999.999.999
> 3.01
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CXF-8242) Stop blocking executor thread on microprofile rest asynchronous call
[ https://issues.apache.org/jira/browse/CXF-8242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp updated CXF-8242: - Fix Version/s: (was: 3.2.13) > Stop blocking executor thread on microprofile rest asynchronous call > -- > > Key: CXF-8242 > URL: https://issues.apache.org/jira/browse/CXF-8242 > Project: CXF > Issue Type: Bug > Components: MicroProfile >Affects Versions: 3.3.5, 3.2.12 >Reporter: Baptiste AIGLIN >Assignee: Andriy Redko >Priority: Critical > Fix For: 3.4.0, 3.3.7 > > Attachments: cxf-microprofile.zip > > Time Spent: 20m > Remaining Estimate: 0h > > Hello, while digging into the way implementation for microprofile was done to > understand how I can override the default executor and how it is used behind > the scene, I found that the microprofile futures are actually created using > CompletableFuture.supplyAsync using the given executor or default one defined > by CXF and calling wait on it. If not mistaken this should block the executor > thread until it is resumed by async handler. This is a major issue for us as > we were expecting pure asynchronous processing to avoid defining executors > with many threads. > If everything I say is correct I have tried to implement a naive > implementation creating a future using constructor that is not waiting but > will be completed by asynchronous handler -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CXF-8242) Stop blocking executor thread on microprofile rest asynchronous call
[ https://issues.apache.org/jira/browse/CXF-8242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp updated CXF-8242: - Fix Version/s: (was: 3.2.13) (was: 3.3.6) 3.3.7 > Stop blocking executor thread on microprofile rest asynchronous call > -- > > Key: CXF-8242 > URL: https://issues.apache.org/jira/browse/CXF-8242 > Project: CXF > Issue Type: Bug > Components: MicroProfile >Affects Versions: 3.3.5, 3.2.12 >Reporter: Baptiste AIGLIN >Assignee: Andriy Redko >Priority: Critical > Fix For: 3.4.0, 3.3.7 > > Attachments: cxf-microprofile.zip > > Time Spent: 10m > Remaining Estimate: 0h > > Hello, while digging into the way implementation for microprofile was done to > understand how I can override the default executor and how it is used behind > the scene, I found that the microprofile futures are actually created using > CompletableFuture.supplyAsync using the given executor or default one defined > by CXF and calling wait on it. If not mistaken this should block the executor > thread until it is resumed by async handler. This is a major issue for us as > we were expecting pure asynchronous processing to avoid defining executors > with many threads. > If everything I say is correct I have tried to implement a naive > implementation creating a future using constructor that is not waiting but > will be completed by asynchronous handler -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CXF-8079) Introduce an example for using the WSAT transaction in CXF
[ https://issues.apache.org/jira/browse/CXF-8079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16892880#comment-16892880 ] Daniel Kulp commented on CXF-8079: -- Just to let you know, I've looked at this, but I do need to get a clarification from Apache Legal before I merge it.The Narayana Transaction Manager is LGPL which is not something we're allowed to link to for any core, non-optional, functionality in an Apache project. Since this is entirely in the scope of an example and not really a core part of the project, it SHOULDN'T be an issue, but I want to verify with legal first. > Introduce an example for using the WSAT transaction in CXF > -- > > Key: CXF-8079 > URL: https://issues.apache.org/jira/browse/CXF-8079 > Project: CXF > Issue Type: Improvement >Reporter: Zheng Feng >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > First I get the idea from [https://cxf.apache.org/getting-involved.html] and > it is lacked of supporting the web service transaction currently. Also I just > worked with the narayana team before and we have the xts subsystem > integration with the jboss-as container. So it could be great to introduce an > example to show how to integration with narayana to support the transaction > between two cxf web services. Anyway, I know that it is few interest in WS > transactions from the customs or the community. But I expect the people could > learn from this quickstart that we have this capability to support the > transaction within the CXF. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (CXF-8051) Request gets corrupted when calling a stateful streamed secure conversation
[ https://issues.apache.org/jira/browse/CXF-8051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853180#comment-16853180 ] Daniel Kulp commented on CXF-8051: -- That "632" is the size for the next chunk for the chunked transfer encoding. Thus, it looks correct.You could try turning off the chunking if the requests are relatively small (aka: not megabytes in size). The middle layer network component might not then be fiddling with the chunking. > Request gets corrupted when calling a stateful streamed secure conversation > --- > > Key: CXF-8051 > URL: https://issues.apache.org/jira/browse/CXF-8051 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Affects Versions: 3.3.2 > Environment: The request is running in a console application hosted > in Netbeans on Windows Server 2012 R2. The service is a .NET WCF service on > Windows Server 2012 R2. >Reporter: Henning Normann >Priority: Major > Attachments: EcBad.txt, EcGood.txt > > > The request to a streamed secure conversation web service gets corrupted if > the service (.NET WCF) is configured as stateless (with a stateful token > carrying the state in soap cookies). If the service as configured as stateful > (no soap cookies), the request is valid. When it's corrupted, a tree digit > number is inserted in the Content-Transfer-Encoding header. A corrupt (search > for 632) and a valid request are attached. The requests were recorded by > Wireshark on the service host server. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-8044) Setting compiler-fork to true is causing problems with Dynamic client
Daniel Kulp created CXF-8044: Summary: Setting compiler-fork to true is causing problems with Dynamic client Key: CXF-8044 URL: https://issues.apache.org/jira/browse/CXF-8044 Project: CXF Issue Type: Bug Components: Simple Frontend Affects Versions: 3.3.2 Reporter: Daniel Kulp Assignee: Daniel Kulp Fix For: 3.3.3 The simple frontend's DynamicClient, when it detects it is running on Java9+, sets the system property org.apache.cxf.common.util.Compiler-fork to true. This causes a variety of problems on Java 11 systems, in particularly on Windows. There should be no need to set that and there isn't a way currently to NOT set it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-8028) Performance problem with very big request
[
https://issues.apache.org/jira/browse/CXF-8028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-8028.
--
Resolution: Fixed
Fix Version/s: 3.3.2
> Performance problem with very big request
> --
>
> Key: CXF-8028
> URL: https://issues.apache.org/jira/browse/CXF-8028
> Project: CXF
> Issue Type: Bug
> Components: Core, JAX-WS Runtime
>Affects Versions: 3.3.0
>Reporter: Gilles Diacon
>Assignee: Daniel Kulp
>Priority: Critical
> Fix For: 3.3.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am using CXF as webservice client for years and since the migration of my
> application from Java 8 to Java 11 I have noticed a performance degradation
> on very big request
> after digging in the code I found following methods in {{DOMUtils.java}}
> {code:java}
> /**
> * Try to get the DOM Node from the SAAJ Node with JAVA9 afterwards
> * @param node The original node we need check
> * @return The DOM node
> */
> public static Node getDomElement(Node node) {
> if (node != null && isJava9SAAJ()) {
> //java9plus hack
> try {
> Method method = node.getClass().getMethod("getDomElement");
> node = (Node)method.invoke(node);
> } catch (NoSuchMethodException e) {
> //best effort to try, do nothing if NoSuchMethodException
> } catch (Exception e) {
> throw new RuntimeException(e);
> }
> }
> return node;
> }
> {code}
> CXF-7270 + CXF-7683 + CXF-7741 + CXF-7847
> when {{getDomelement()}} method doesn't exist on the Node, an exception of
> type {{NoSuchMethodException}} is created which normally takes 1 milliseconds
> (mainly used to fill the {{stacktrace}})
> (similar problem for {{getDomDocumentFragment()}} method)
> but if the document is really big and contains more than 30'000 elements, the
> repetitive creation of this exception could cost a some seconds ...
> I have fixed this performance by caching node without {{getDomElement()}}
> method to avoid repetitive exception but I am not sure if it's a good solution
> can you help me with this performance problem?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (CXF-8028) Performance problem with very big request
[
https://issues.apache.org/jira/browse/CXF-8028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp reassigned CXF-8028:
Assignee: Daniel Kulp
> Performance problem with very big request
> --
>
> Key: CXF-8028
> URL: https://issues.apache.org/jira/browse/CXF-8028
> Project: CXF
> Issue Type: Bug
> Components: Core, JAX-WS Runtime
>Affects Versions: 3.3.0
>Reporter: Gilles Diacon
>Assignee: Daniel Kulp
>Priority: Critical
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am using CXF as webservice client for years and since the migration of my
> application from Java 8 to Java 11 I have noticed a performance degradation
> on very big request
> after digging in the code I found following methods in {{DOMUtils.java}}
> {code:java}
> /**
> * Try to get the DOM Node from the SAAJ Node with JAVA9 afterwards
> * @param node The original node we need check
> * @return The DOM node
> */
> public static Node getDomElement(Node node) {
> if (node != null && isJava9SAAJ()) {
> //java9plus hack
> try {
> Method method = node.getClass().getMethod("getDomElement");
> node = (Node)method.invoke(node);
> } catch (NoSuchMethodException e) {
> //best effort to try, do nothing if NoSuchMethodException
> } catch (Exception e) {
> throw new RuntimeException(e);
> }
> }
> return node;
> }
> {code}
> CXF-7270 + CXF-7683 + CXF-7741 + CXF-7847
> when {{getDomelement()}} method doesn't exist on the Node, an exception of
> type {{NoSuchMethodException}} is created which normally takes 1 milliseconds
> (mainly used to fill the {{stacktrace}})
> (similar problem for {{getDomDocumentFragment()}} method)
> but if the document is really big and contains more than 30'000 elements, the
> repetitive creation of this exception could cost a some seconds ...
> I have fixed this performance by caching node without {{getDomElement()}}
> method to avoid repetitive exception but I am not sure if it's a good solution
> can you help me with this performance problem?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7953) make corba binding working with JDK11
[ https://issues.apache.org/jira/browse/CXF-7953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812849#comment-16812849 ] Daniel Kulp commented on CXF-7953: -- Or we can do what I did and and the -npa flag to the xjc plugin to have it NOT generate the package-info.java and instead fully populate all the annotations. :) > make corba binding working with JDK11 > - > > Key: CXF-7953 > URL: https://issues.apache.org/jira/browse/CXF-7953 > Project: CXF > Issue Type: Wish >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Minor > Fix For: 3.3.2 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7979) Issues when an operation's input and output should have different policies
[
https://issues.apache.org/jira/browse/CXF-7979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16800631#comment-16800631
]
Daniel Kulp commented on CXF-7979:
--
In some cases, the DispatchImpl can deduce an operation name from the message.
If you look into DispatchImpl, if the WSDL_OPERATION isn't set, it does call
off to the calculateOpName method to try and calculate one. I'm not sure why
that's not working in your case. For certain types of payload we cannot do
that without breaking streaming so its not completely reliable. However, a
SOAPMessage should be completely doable without breaking streaming as it's
already in a DOM.
> Issues when an operation's input and output should have different policies
> --
>
> Key: CXF-7979
> URL: https://issues.apache.org/jira/browse/CXF-7979
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.3.0
> Environment: Tested with CXF 3.3.0, a reproducing example and unit
> test can be found here: https://github.com/netmikey/cxf-security-test
>Reporter: Mike M.
>Assignee: Colm O hEigeartaigh
>Priority: Major
>
> We think we might have found an issue in the way WSDL-Embedded WebService
> Security Policies are interpreted at runtime.
> We are in contract-first mode, but don't use generated JAXB bindings. We use
> a {{@WebServiceProvider}} implementation as a dynamic server and use
> {{javax.xml.ws.Dispatch}} to build a dynamic client.
> The issue happens when we try to apply different WSS-Policies to an
> operation's {{wsdl:input}} and {{wsdl:output}}, so e.g. having the request
> secured but the response non-secured.
> We see different behavior depending on where we put the
> {{wsp:PolicyReference}} within the WSDL, but we didn't manage to make it
> work: either the client doesn't encrypt the request at all, or the server
> encrypts the response as well.
> I created a small but fully functional project on GitHub that contains a unit
> test which demonstrates the behavior (be sure to check the project's README).
> Please have a look at: https://github.com/netmikey/cxf-security-test
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CXF-7953) make corba binding working with JDK11
[ https://issues.apache.org/jira/browse/CXF-7953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-7953. -- Resolution: Fixed Fix Version/s: 3.3.2 > make corba binding working with JDK11 > - > > Key: CXF-7953 > URL: https://issues.apache.org/jira/browse/CXF-7953 > Project: CXF > Issue Type: Wish >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Minor > Fix For: 3.3.2 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-7985) Blocking Class.forName calls on JAX-RS dispatch path
[ https://issues.apache.org/jira/browse/CXF-7985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-7985. -- Resolution: Fixed > Blocking Class.forName calls on JAX-RS dispatch path > > > Key: CXF-7985 > URL: https://issues.apache.org/jira/browse/CXF-7985 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.3.0 >Reporter: Daniel Kulp >Assignee: Daniel Kulp >Priority: Major > Fix For: 3.3.1 > > > The detection for whether JAXB and activation are available on the classpath > occurs for every request which is expensive and is also synchronized. This > information should be cached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7985) Blocking Class.forName calls on JAX-RS dispatch path
Daniel Kulp created CXF-7985: Summary: Blocking Class.forName calls on JAX-RS dispatch path Key: CXF-7985 URL: https://issues.apache.org/jira/browse/CXF-7985 Project: CXF Issue Type: Bug Components: JAX-RS Affects Versions: 3.3.0 Reporter: Daniel Kulp Assignee: Daniel Kulp Fix For: 3.3.1 The detection for whether JAXB and activation are available on the classpath occurs for every request which is expensive and is also synchronized. This information should be cached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7943) MAPCodec: Memory leak due to growing uncorrelatedExchanges
[ https://issues.apache.org/jira/browse/CXF-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16750465#comment-16750465 ] Daniel Kulp commented on CXF-7943: -- I've seen this reported before and every time I've investigated it's due to whatever "load tester" they were using not doing WS-Addressing properly and sticking bogus values in for the message-ids and RelatesTo headers for ws-addressing. If the RelatesTo doesn't properly match what the client is sending, then it cannot be correlated and the messages would not be removed from the Map. Thus, we would definitely need to see request/response messages. > MAPCodec: Memory leak due to growing uncorrelatedExchanges > -- > > Key: CXF-7943 > URL: https://issues.apache.org/jira/browse/CXF-7943 > Project: CXF > Issue Type: Bug >Affects Versions: 3.2.0 > Environment: CXF 3.2.0, JDK 1.8 >Reporter: Sean >Priority: Major > Attachments: histogram.PNG, leak_suspect_1.PNG, mapcodec_leak.png > > > When running load tests, my system begin to get memory leak after 4 hours or > so. When analyzing the heap dump using VisualVM (please see attachments), I > can see that a ConcurrentHashMap is taking up 1.7 GB of space in the heap, as > well as being the main "suspect" for this leak. This leads me to believe that > it is the uncorrelatedExchanges attribute since this map is being reference > from the MAPCodec class. > I believe that the map, in my case, for whatever reason, does not always > remove the Exchange after the synchronous request/responses are done, however > I could be wrong. > > IF this is indeed a bug, what could the cause of this be, as well as any work > around? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7940) FileUtils.delete dramatically slowdown WildFly server shutdown
[
https://issues.apache.org/jira/browse/CXF-7940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16740514#comment-16740514
]
Daniel Kulp commented on CXF-7940:
--
Just a note: with the removal of this, if there are temp files that are locked
due to streams not being closed properly, they may remain after shutdown. The
purpose of that line was to hopefully get the file streams and such garbage
collected and finalized so that the files can be removed. With this change,
if the delete fails, it will likely just keep the files around. (and this is
really just Windows issue as all the unix's can delete open files)
> FileUtils.delete dramatically slowdown WildFly server shutdown
> --
>
> Key: CXF-7940
> URL: https://issues.apache.org/jira/browse/CXF-7940
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.0.0-milestone1, 3.3.0
> Environment: *OS*: Windows
> *AppServer*: WildFly 10.0.0.1.Final
> *CXF*: cxf-core-3.1.6
> *jbossws-cxf*: jbossws-cxf-server-5.1.5.Final
>Reporter: Viacheslav
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 3.3.0
>
>
> *Brief introduction:*
> We use WildFly server.
> As we know, WildFly based on JBoss Application Server.
> WildFly have an integration with Apache CXF through
> "[jbossws-cxf|https://github.com/jbossws/jbossws-cxf]"; project.
> When WildFly server is stops we see repeated invokes of
> WSDLFilePublisher.java#unpublishWsdlFiles that invoke FileUtils#removeDir
> *Cause of problems:*
> When the method FileUtils#removeDir is invoked then we see the invoke of
> FileUtils#delete:
> https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/helpers/FileUtils.java#L254.
> We see some strange code:
> {code:java}
> public static void delete(File f, boolean inShutdown) {
> if (!f.delete()) {
> if (isWindows()) {
> System.gc();
> }
> {code}
> This leads to dramatically slowdown of WildFly server shutdown on Windows
> systems.
> For example, our WildFly server stops in 2781ms without this call AND stops
> in 119882ms with this call (~ 43 times slower).
> *Questions:*
> What is the reason of this code?
> Is it bug? What are the disadvantages of removing this code?
> Last changes of this code from Git Blame:
> [commit|https://github.com/apache/cxf/commit/88a9451b92180609b7bb93d0314bc8384f0c24a4#diff-b620deea897fb467b6f42abd1c32b7f2R138].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CXF-7875) ServiceList doesn't use proper bus to query if swagger/wadl is available.
[ https://issues.apache.org/jira/browse/CXF-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-7875. -- Resolution: Fixed > ServiceList doesn't use proper bus to query if swagger/wadl is available. > - > > Key: CXF-7875 > URL: https://issues.apache.org/jira/browse/CXF-7875 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 3.2.6 >Reporter: Daniel Kulp >Assignee: Daniel Kulp >Priority: Major > Fix For: 3.2.7 > > > The FormattedServiceListWriter always uses the bus of the service list to > query if swagger and wadl are available. However, for swagger in particular, > those could be features registered on the bus that created the service > itself. Thus, the links do not show properly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7875) ServiceList doesn't use proper bus to query if swagger/wadl is available.
Daniel Kulp created CXF-7875: Summary: ServiceList doesn't use proper bus to query if swagger/wadl is available. Key: CXF-7875 URL: https://issues.apache.org/jira/browse/CXF-7875 Project: CXF Issue Type: Bug Components: Transports Affects Versions: 3.2.6 Reporter: Daniel Kulp Assignee: Daniel Kulp Fix For: 3.2.7 The FormattedServiceListWriter always uses the bus of the service list to query if swagger and wadl are available. However, for swagger in particular, those could be features registered on the bus that created the service itself. Thus, the links do not show properly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7806) Add option to create JWT access tokens without persisting them
[ https://issues.apache.org/jira/browse/CXF-7806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp updated CXF-7806: - Fix Version/s: (was: 3.2.6) > Add option to create JWT access tokens without persisting them > -- > > Key: CXF-7806 > URL: https://issues.apache.org/jira/browse/CXF-7806 > Project: CXF > Issue Type: Task >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Attachments: CXF-7806-RT.patch, CXF-7806-systests.patch > > > Right now for the OAuth 2.0 data provider, we can issue access tokens in JWT > format by specifying the "useJwtFormatForAccessTokens" property. However this > persists the encoded JWT token, something that is problematic with the JPA > provider as the Id column of the AccessToken class can't handle the size of > the token. > I propose to add a new property called "persistJwtEncoding" to be used in > conjunction with "useJwtFormatForAccessTokens". By default > "persistJwtEncoding" is true for backwards compatibility reasons. > When "persistJwtEncoding" is false, then the AccessToken that is persisted > just contains the Id (opaque String) as for the > non-useJwtFormatForAccessTokens case. However, the JWT-encoded access token > is returned to the client. > For the AbstractAccessTokenValidator and the TokenIntrospectionService, we > can also set "persistJwtEncoding" to false to validate and parse the received > token into a JWTToken. The Id is then extracted from the token and used to > retrieve the access token from storage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-7811) _wadl links missing in OSGi containers
[ https://issues.apache.org/jira/browse/CXF-7811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-7811. -- Resolution: Fixed > _wadl links missing in OSGi containers > -- > > Key: CXF-7811 > URL: https://issues.apache.org/jira/browse/CXF-7811 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.2.5 >Reporter: Daniel Kulp >Assignee: Daniel Kulp >Priority: Major > Fix For: 3.2.6 > > > When run in OSGi, the services list is missing the _wadl links. The _wadl > URL's also don't work anymore. They worked in previous versions of CXF -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7811) _wadl links missing in OSGi containers
Daniel Kulp created CXF-7811: Summary: _wadl links missing in OSGi containers Key: CXF-7811 URL: https://issues.apache.org/jira/browse/CXF-7811 Project: CXF Issue Type: Bug Components: JAX-RS Affects Versions: 3.2.5 Reporter: Daniel Kulp Assignee: Daniel Kulp Fix For: 3.2.6 When run in OSGi, the services list is missing the _wadl links. The _wadl URL's also don't work anymore. They worked in previous versions of CXF -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-7798) Mapping of SOAP Faults in Asynchronous JAX-WS Client
[
https://issues.apache.org/jira/browse/CXF-7798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-7798.
--
Resolution: Fixed
Assignee: Daniel Kulp
Fix Version/s: 3.3.0
3.2.6
> Mapping of SOAP Faults in Asynchronous JAX-WS Client
>
>
> Key: CXF-7798
> URL: https://issues.apache.org/jira/browse/CXF-7798
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.2.5
>Reporter: Giedrius Noreikis
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: 3.2.6, 3.3.0
>
>
> When a SOAP fault is received, asynchronous JAX-WS client throws
> {{ExecutionException}} with a CXF-specific {{SoapFault}} as its cause:
> {code:java}
> Caused by: java.util.concurrent.ExecutionException:
> org.apache.cxf.binding.soap.SoapFault: ...
> at org.apache.cxf.endpoint.ClientCallback.get(ClientCallback.java:147)
> at
> org.apache.cxf.jaxws.JaxwsResponseCallback.get(JaxwsResponseCallback.java:49)
> ...
> {code}
> Instead, the cause of {{ExecutionException}} is supposed to contain an
> instance of {{javax.xml.ws.soap.SOAPFaultException}} in this case, as the
> mapping should be identical for both asynchronous and synchronous cases.
> Steps to reproduce:
> # Create and publish a service:
> TestService.java:
> {code:java}
> package test;
> import javax.jws.WebMethod;
> import javax.jws.WebService;
> @WebService
> public interface TestService {
> @WebMethod
> void test();
> }
> {code}
> TestServiceImpl.java:
> {code:java}
> package test;
> import javax.jws.WebService;
> import javax.xml.ws.Endpoint;
> @WebService(endpointInterface = "test.TestService")
> public class TestServiceImpl implements TestService {
> @Override
> public void test() {
> throw new IllegalArgumentException("test");
> }
> public static void main(String[] args) {
> Endpoint.publish("http://localhost:/service/test";, new
> TestServiceImpl());
> }
> }
> {code}
> # Generate a client:
> {code}
> wsimport -b bindings.xml -keep http://localhost:/service/test?wsdl
> {code}
> bindings.xml:
> {code:xml}
> http://schemas.xmlsoap.org/wsdl/";
> xmlns="http://java.sun.com/xml/ns/jaxws";>
>node="wsdl:definitions/wsdl:portType[@name='TestService']/wsdl:operation[@name='test']">
> true
>
>
> {code}
> # Use the service:
> {code:java}
> try {
> testService.test();
> } catch (SOAPFaultException e) {
> System.out.println("good");
> }
> try {
> testService.testAsync().get();
> } catch (ExecutionException e) {
> if (e.getCause() instanceof SOAPFaultException) {
> System.out.println("good");
> } else {
> System.out.println("bad"); // fails with CXF
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7785) org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'cxf' available
[
https://issues.apache.org/jira/browse/CXF-7785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16546793#comment-16546793
]
Daniel Kulp commented on CXF-7785:
--
If you use a bus name other than the default ("cxf"), you can specify a servlet
param to the CXFServlet of "bus" with the name of the bus to use.
> org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean
> named 'cxf' available
> --
>
> Key: CXF-7785
> URL: https://issues.apache.org/jira/browse/CXF-7785
> Project: CXF
> Issue Type: Bug
> Components: Bus, Integration
>Affects Versions: 3.2.5
> Environment: I am using JDK 1.8.0_144, Apache CXF 3.2.5, Tomcat
> 8.0.5, and Spring 5.0.4 for this sample project.
>Reporter: Nitin Bhardwaj
>Priority: Minor
> Attachments: application-context.xml, cxf-beans.xml,
> cxf-beans_BUS.xml, dispatcher-servlet.xml, springcxfserver.zip, web.xml
>
>
> I successfully published a simple JAX-WS web-service using Apache CXF Spring
> configuration. I am now trying to configure an inbound interceptor for that
> service. The Interceptor works fine when I use the following configuration:
> {color:#205081} {color:#205081} implementor="com.nit.ws.service.impl.HelloWorldServiceImpl"
> address="/HelloWorldService">{color}
> {color:#205081} {color}
> {color:#205081} {color}
> {color:#205081} {color}
> {color:#205081} {color}
> {color:#205081} class="com.nit.ws.security.HttpAuthHeaderInterceptor" />{color}
> However, if I try to configure the interceptor using a CXF Bus instead of
> above configuration like below:
> {color:#205081} {color:#205081} implementor="com.nit.ws.service.impl.HelloWorldServiceImpl"
> address="/HelloWorldService"/>{color}
> {color:#205081} {color}
> {color:#205081} {color}
> {color:#205081} {color}
> {color:#205081} {color}
> {color:#205081} {color}
> {color:#205081} class="com.nit.ws.security.HttpAuthHeaderInterceptor" />{color}
> *Then it throws the following exception in Tomcat 8 server when I hit the
> WSDL([http://localhost:8080/springcxfserver/services/HelloWorldService?wsdl):*]
> {color:#ff}*org.springframework.beans.factory.NoSuchBeanDefinitionException:
> No bean named 'cxf' available*
> org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanDefinition(DefaultListableBeanFactory.java:686)
>
> org.springframework.beans.factory.support.AbstractBeanFactory.getMergedLocalBeanDefinition(AbstractBeanFactory.java:1205)
>
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:292)
>
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:205)
>
> org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1091)
> org.apache.cxf.transport.servlet.CXFServlet.loadBus(CXFServlet.java:80)
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.init(CXFNonSpringServlet.java:83)
>
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:503)
>
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:74){color}
> The *HttpAuthHeaderInterceptor* extends
> {color:#205081}org.apache.cxf.binding.soap.interceptor.AbstractSoapInterceptor{color}
> and it just prints "Hello World" on the console in case of successful
> execution as defined above.
> I am trying to use Bus configuration so that all the JAX-WS endpoints can be
> configured using the same bus configuration to allow applying common
> interceptors to all of them without duplicating the configuration in each
> element.
> I've attached the web.xml, application-context.xml, cxf-beans.xml, and
> dispatcher-servlet.xml with this ticket for ready reference. The
> configurations described above have been defined inside cxf-beans.xml which
> is imported by application-context.xml.[^application-context.xml]
> I am using JDK 1.8.0_144, Apache CXF 3.2.5, Tomcat 8.0.5, and Spring 5.0.4
> for this sample project.
> The pom.xml snippet for Apache CXF dependencies is as follows:
> {color:#205081} {color}
> {color:#205081} {color}
> {color:#205081} {color}
> {color:#205081} org.apache.cxf{color}
> {color:#205081} cxf-rt-frontend-jaxws{color}
> {color:#205081} 3.2.5{color}
> {color:#205081} {color}
>
> {color:#205081}{color}
> {color:#205081} org.apache.cxf{color}
> {color:#205081} cxf-rt-transports-http{color}
> {color:#205081} 3.2.5{color}
> {color:#205081} {color}
> {color:#205081} {color}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CXF-7795) Unmarshalling exception
[
https://issues.apache.org/jira/browse/CXF-7795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-7795.
--
Resolution: Not A Bug
Assignee: Daniel Kulp
Fix Version/s: Invalid
> Unmarshalling exception
> ---
>
> Key: CXF-7795
> URL: https://issues.apache.org/jira/browse/CXF-7795
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
>Affects Versions: 3.2.4
>Reporter: Vijay Nadipalli
>Assignee: Daniel Kulp
>Priority: Critical
> Fix For: Invalid
>
>
> We are getting scema validation error ( Unmarshalling exception )for type
> CustomInteger when value its empty or null.
> XSD:
> nillable="true">
>
>
> "URN" is the name of a flex field that can be imported or
> exported.
>
>
>
>
>
>
>
>
>
> +Generated binding class (JAXB):+
> public static class CustomInteger {
> @XmlValue
> protected BigInteger value;
> @XmlAttribute(name = "name")
> protected String name;
> /**
> * Gets the value of the value property.
> *
> * @return
> * possible object is
> * \{@link BigInteger }
> *
> */
> public BigInteger getValue() {
> return value;
> }
> /**
> * Sets the value of the value property.
> *
> * @param value
> * allowed object is
> * \{@link BigInteger }
> *
> */
> public void setValue(BigInteger value) {
> this.value = value;
> }
> /**
> * Gets the value of the name property.
> *
> * @return
> * possible object is
> * \{@link String }
> *
> */
> public String getName() {
> return name;
> }
> }
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CXF-7796) Support setting outbound network interface for UDP transport
[ https://issues.apache.org/jira/browse/CXF-7796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-7796. -- Resolution: Fixed > Support setting outbound network interface for UDP transport > > > Key: CXF-7796 > URL: https://issues.apache.org/jira/browse/CXF-7796 > Project: CXF > Issue Type: Improvement > Components: Transports >Reporter: Daniel Kulp >Assignee: Daniel Kulp >Priority: Major > Fix For: 3.2.6 > > > The multicast UDP transport just uses whatever the JVM decides is the default > interface and there is no way to specify which interface to use for the > multicast traffic. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-7794) BigInteger Binding classes cxf interceptor error
[ https://issues.apache.org/jira/browse/CXF-7794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-7794. -- Resolution: Not A Bug Assignee: Daniel Kulp Fix Version/s: Invalid > BigInteger Binding classes cxf interceptor error > - > > Key: CXF-7794 > URL: https://issues.apache.org/jira/browse/CXF-7794 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime, JAXB Databinding >Affects Versions: 3.2.4 >Reporter: Rajesh >Assignee: Daniel Kulp >Priority: Major > Fix For: Invalid > > Attachments: CXF Binding Issue.txt, CXFBindingIssue.docx > > Original Estimate: 20h > Remaining Estimate: 20h > > Problem is when I' m not passing customIngeger value which is BigInteger Type > in soap request I'm getting cxf interceptor error .if I change binding class > datatype from BigInteger to String to same attribute I'm able to test it out. > Why for big integer data types cxf is throwing interceptor error though its > optional parameter.Find the details in attachments > > Any help would be appreciated. > Thank you. > [ > |https://s1.ariba.com/Buyer/soap/cisco-child-T/PaymentRealTimeExport_v2?wsdl&validate=false] > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7794) BigInteger Binding classes cxf interceptor error
[
https://issues.apache.org/jira/browse/CXF-7794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16546779#comment-16546779
]
Daniel Kulp commented on CXF-7794:
--
An xsd:integer (which is the base type in your schema) has a lexical format of:
{code}
integer has a lexical representation consisting of a finite-length sequence of
one or more decimal digits (#x30-#x39) with an optional leading sign
{code}
An empty element does NOT fit that lexical representation (one or more). The
error is completely correct.
> BigInteger Binding classes cxf interceptor error
> -
>
> Key: CXF-7794
> URL: https://issues.apache.org/jira/browse/CXF-7794
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime, JAXB Databinding
>Affects Versions: 3.2.4
>Reporter: Rajesh
>Priority: Major
> Attachments: CXF Binding Issue.txt, CXFBindingIssue.docx
>
> Original Estimate: 20h
> Remaining Estimate: 20h
>
> Problem is when I' m not passing customIngeger value which is BigInteger Type
> in soap request I'm getting cxf interceptor error .if I change binding class
> datatype from BigInteger to String to same attribute I'm able to test it out.
> Why for big integer data types cxf is throwing interceptor error though its
> optional parameter.Find the details in attachments
>
> Any help would be appreciated.
> Thank you.
> [
> |https://s1.ariba.com/Buyer/soap/cisco-child-T/PaymentRealTimeExport_v2?wsdl&validate=false]
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CXF-7796) Support setting outbound network interface for UDP transport
Daniel Kulp created CXF-7796: Summary: Support setting outbound network interface for UDP transport Key: CXF-7796 URL: https://issues.apache.org/jira/browse/CXF-7796 Project: CXF Issue Type: Improvement Components: Transports Reporter: Daniel Kulp Assignee: Daniel Kulp Fix For: 3.2.6 The multicast UDP transport just uses whatever the JVM decides is the default interface and there is no way to specify which interface to use for the multicast traffic. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7787) NullPointerException from wsdl2java
[
https://issues.apache.org/jira/browse/CXF-7787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541687#comment-16541687
]
Daniel Kulp commented on CXF-7787:
--
Honestly, I'm not exactly sure if the wsdl/schema is valid. The schema for
which there is no targetNamespace on it also declares
elementFormDefault="qualified". Qualified elements require a namespace. From
the schema spec:
{code}
A non-·absent· value of the {target namespace} property provides for
·validation· of namespace-qualified element information items. ·Absent· values
of {target namespace} ·validate· unqualified items.
{code}
> NullPointerException from wsdl2java
> ---
>
> Key: CXF-7787
> URL: https://issues.apache.org/jira/browse/CXF-7787
> Project: CXF
> Issue Type: Test
> Environment: CXF 3.2.5
> Java 8
>Reporter: James Main
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.2.6, 3.1.17
>
> Attachments: LabResultsService.singleWsdl
>
>
> I am trying to generate Java code against my wsdl file using the wsdl2java
> utility. I can't figure out where I am going wrong.
> Here is the command line arguments I am using -->
> $ ./wsdl2java.bat -d /c/Users/jmain/generated -client -exsh false -dns true
> -dex true -validate -verbose
> /c/Users/jmain/workspace-hub-hhcc/hub/src/main/resources/wsdl/hhcc/LabResultsService.singleWsdl
>
> And here is the output -->
> Loading FrontEnd jaxws ...
> Loading DataBinding jaxb ...
> wsdl2java -d C:/Users/jmain/generated -client -exsh false -dns true -dex true
> -validate -verbose
> C:/Users/jmain/workspace-hub-hhcc/hub/src/main/resources/wsdl/hhcc/LabResultsService.singleWsdl
> wsdl2java - Apache CXF 3.2.5
> WSDLToJava Error: java.lang.NullPointerException
> org.apache.cxf.tools.common.ToolException: java.lang.NullPointerException
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:420)
> 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)
> Caused by: java.lang.NullPointerException
> at
> org.apache.cxf.common.xmlschema.SchemaCollection.getSchemaByTargetNamespace(SchemaCollection.java:164)
> at
> org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding$3.resolveResource(JAXBDataBinding.java:991)
> at
> com.sun.org.apache.xerces.internal.util.DOMEntityResolverWrapper.resolveEntity(DOMEntityResolverWrapper.java:117)
> at
> com.sun.org.apache.xerces.internal.impl.XMLEntityManager.resolveEntity(XMLEntityManager.java:1081)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.resolveDocument(XMLSchemaLoader.java:657)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.resolveSchema(XSDHandler.java:2056)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:1012)
> at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:623)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadSchema(XMLSchemaLoader.java:613)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:572)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:538)
> at
> com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:255)
> at
> javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:638)
> at
> org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.validateSchema(JAXBDataBinding.java:1006)
> at
> org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.addSchemasForServiceInfos(JAXBDataBinding.java:729)
> at
> org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.addSchemas(JAXBDataBinding.java:712)
> at
> org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:441)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.generateTypes(WSDLToJavaContainer.java:723)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:267)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:164)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:412)
> ... 4 more
> I've attached the WSDL file.
> Any ideas?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CXF-7719) Remove date filed from the @Generated annotation if suppress-generated-date is enabled
[ https://issues.apache.org/jira/browse/CXF-7719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp updated CXF-7719: - Fix Version/s: (was: 3.2.5) > Remove date filed from the @Generated annotation if suppress-generated-date > is enabled > -- > > Key: CXF-7719 > URL: https://issues.apache.org/jira/browse/CXF-7719 > Project: CXF > Issue Type: Improvement > Components: Tooling >Affects Versions: 3.2.4 >Reporter: Dmitry Volodin >Priority: Trivial > > The @Generated annotation also contains 'date' filed which is set to current > date on each build. It's better to skip this field if > 'suppress-generated-date' is enabled. > I will fix this, when CXF-7708 will be merged to avoid conflicts. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7317) Non-URL encoded Content-Id href does not seem be serialized by CXF's AttachmentSerializer
[ https://issues.apache.org/jira/browse/CXF-7317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp updated CXF-7317: - Fix Version/s: 3.1.16 > Non-URL encoded Content-Id href does not seem be serialized by CXF's > AttachmentSerializer > - > > Key: CXF-7317 > URL: https://issues.apache.org/jira/browse/CXF-7317 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.10 >Reporter: Viral Gohel >Assignee: Dennis Kieselhorst >Priority: Major > Fix For: 3.1.16, 3.2.5 > > Attachments: mtomExample.war > > > CXF-6484 states that, > >> URL-encoded content ID for MTOM attachments causes problems with web > >> service clients. This is effectively a regression on: > https://issues.apache.org/jira/browse/CXF-2669 > For example, If the namespace is "https://cxf.apache.org/"; for the service > endpoint, then the content id is now: > 5726d366-df25-4945-9f3b-3003a2ae8a70-3@http%3A%2F%2Fcxf.apache.org%2F > It was previously: > 5726d366-df25-4945-9f3b-3003a2ae8a7...@cxf.apache.org > Hence, > Actual results: > Content Id contains the full namespace (as URL) which is URL encoded: > 5726d366-df25-4945-9f3b-3003a2ae8a70-3@http%3A%2F%2Fcxf.apache.org%2F > Expected results: > Content id does not require encoding and only contains hostname: > 5726d366-df25-4945-9f3b-3003a2ae8a7...@cxf.apache.org > With the attached reproducer, here's what the results looks like, > Actual Result - > href="cid:0842d204-23ec-4b6f-955b-0e38a4c2f35a-1@urn%3Awsc.td.com%2Fcis%2F2010%2F01%2F19 > Expected Result - > href="cid:0842d204-23ec-4b6f-955b-0e38a4c2f35a-1@urn:Awsc.td.com/cis/2010/01/19 > The difference here compared to the fix for CXF-6484, is that a non-url > encoded href using namespace with 'urn:' for the attachments is used. > For example, like the below in the @WebService class, > @WebService(targetNamespace = "urn:wsc.td.com/cis/2010/01/19") > To me, it seems that the fix for CXF-6484 does not work for non-url encoded > href. > I.e After the fix of CXF-6484, > Actual Result - > href="cid:0842d204-23ec-4b6f-955b-0e38a4c2f35a-1@urn%3Awsc.td.com%2Fcis%2F2010%2F01%2F19 > Expected Result - > href="cid:0842d204-23ec-4b6f-955b-0e38a4c2f35a-1@urn:Awsc.td.com/cis/2010/01/19 > It looks like CXF's AttachmentSerializer is not able to serialize the forward > slashes(/) or the AttachmentUtil needs to be changed. > I am not sure if the proper urn: namespaces should be of format, i.e > urn:com.namespace.someResource or it can be also like, > urn:com/namespace/someResource. > Can we make CXF to interpret and display the href in the Content-Id with > non-url namespace as > cid:0842d204-23ec-4b6f-955b-0e38a4c2f35a-1@urn:Awsc.td.com/cis/2010/01/19 ? > instead of > href="cid:0842d204-23ec-4b6f-955b-0e38a4c2f35a-1@urn%3Awsc.td.com%2Fcis%2F2010%2F01%2F19 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7704) False positive warning log: "Unable to recognize the addressing policy"
[ https://issues.apache.org/jira/browse/CXF-7704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp updated CXF-7704: - Fix Version/s: 3.1.16 > False positive warning log: "Unable to recognize the addressing policy" > --- > > Key: CXF-7704 > URL: https://issues.apache.org/jira/browse/CXF-7704 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.2.4 >Reporter: Reguel Wermelinger >Priority: Minor > Fix For: 3.1.16, 3.2.5 > > Attachments: greet-policy-wsaddressing.wsdl > > > CXF Client Calls to a service with a WS-Addressing policy fails with "Unable > to recognize the addressing policy". Even tough the policy works and the > required interceptors are correctly instantiated. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXFXJC-26) cxf-xjc-plugin generated source encoding problem
[
https://issues.apache.org/jira/browse/CXFXJC-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXFXJC-26.
---
Resolution: Fixed
Assignee: Daniel Kulp
Fix Version/s: 3.2.2
I added an encoding configuration for the plugin which will read the default
from project.build.sourceEncoding.
You can work around this by adding extensionArgs to the xsdOption:
{noformat}
-encoding
UTF-8
{noformat}
> cxf-xjc-plugin generated source encoding problem
>
>
> Key: CXFXJC-26
> URL: https://issues.apache.org/jira/browse/CXFXJC-26
> Project: CXF XJC Utils
> Issue Type: Bug
> Components: Maven Plugin
> Environment: Apache Maven 3.2.5
> (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
> Maven home: C:\devenv\apache-maven-3.2.5
> Java version: 1.8.0_162, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_162\jre
> Default locale: en_DE, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos"
>Reporter: Bernd Eckenfels
>Assignee: Daniel Kulp
>Priority: Minor
> Labels: i18n
> Fix For: 3.2.2
>
>
> When using cxf-xjc-plugin:3.1.0:xsdtojava on my german Windows 10 the
> generated source code uses german language comments with the word "für"
> (umlaut). The source seems to be in latin1 whereas the project is configured
> to use UTF-8 source encoding. For this reason the following processing steps
> (compiler warn and javadoc error) fail because of invalid UTF-8 sequences. It
> should allow to define the encoding and default to the maven.source.encoding.
> I also did not find a way to actually generate english comments
> (MAVEN_OPTS=-Duser.language=en does help).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Moved] (CXFXJC-26) cxf-xjc-plugin generated source encoding problem
[ https://issues.apache.org/jira/browse/CXFXJC-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp moved CXF-7755 to CXFXJC-26: Estimated Complexity: (was: Unknown) Component/s: (was: JAXB Databinding) Maven Plugin Key: CXFXJC-26 (was: CXF-7755) Project: CXF XJC Utils (was: CXF) > cxf-xjc-plugin generated source encoding problem > > > Key: CXFXJC-26 > URL: https://issues.apache.org/jira/browse/CXFXJC-26 > Project: CXF XJC Utils > Issue Type: Bug > Components: Maven Plugin > Environment: Apache Maven 3.2.5 > (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00) > Maven home: C:\devenv\apache-maven-3.2.5 > Java version: 1.8.0_162, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.8.0_162\jre > Default locale: en_DE, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos" >Reporter: Bernd Eckenfels >Priority: Minor > Labels: i18n > > When using cxf-xjc-plugin:3.1.0:xsdtojava on my german Windows 10 the > generated source code uses german language comments with the word "für" > (umlaut). The source seems to be in latin1 whereas the project is configured > to use UTF-8 source encoding. For this reason the following processing steps > (compiler warn and javadoc error) fail because of invalid UTF-8 sequences. It > should allow to define the encoding and default to the maven.source.encoding. > I also did not find a way to actually generate english comments > (MAVEN_OPTS=-Duser.language=en does help). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-7754) WrappedAttachments.toArray failure
[ https://issues.apache.org/jira/browse/CXF-7754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-7754. -- Resolution: Fixed Assignee: Daniel Kulp Fix Version/s: 3.2.5 3.1.16 > WrappedAttachments.toArray failure > -- > > Key: CXF-7754 > URL: https://issues.apache.org/jira/browse/CXF-7754 > Project: CXF > Issue Type: Bug >Reporter: Daniel Kulp >Assignee: Daniel Kulp >Priority: Major > Fix For: 3.1.16, 3.2.5 > > > If you put a Map into the JAX-WS context for attachment, > then later query the attachments, the resulting WrappedAttachments has a > toArray method that will fail if passed an improper sized array. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7754) WrappedAttachments.toArray failure
Daniel Kulp created CXF-7754: Summary: WrappedAttachments.toArray failure Key: CXF-7754 URL: https://issues.apache.org/jira/browse/CXF-7754 Project: CXF Issue Type: Bug Reporter: Daniel Kulp If you put a Map into the JAX-WS context for attachment, then later query the attachments, the resulting WrappedAttachments has a toArray method that will fail if passed an improper sized array. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7741) ensure we can build CXF with JDK11
[ https://issues.apache.org/jira/browse/CXF-7741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16506059#comment-16506059 ] Daniel Kulp commented on CXF-7741: -- This is definitely something to target for 3.3.Adding a bunch of deps for 3.2 is likely not a great idea, but definitely worth it for 3.3. > ensure we can build CXF with JDK11 > -- > > Key: CXF-7741 > URL: https://issues.apache.org/jira/browse/CXF-7741 > Project: CXF > Issue Type: Task >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > Attachments: CXF-7741.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-7751) Codegen plugin can't work with empty extraarg tag
[
https://issues.apache.org/jira/browse/CXF-7751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-7751.
--
Resolution: Fixed
> Codegen plugin can't work with empty extraarg tag
> -
>
> Key: CXF-7751
> URL: https://issues.apache.org/jira/browse/CXF-7751
> Project: CXF
> Issue Type: Bug
> Components: Build system
>Affects Versions: 3.1.6, 3.2.4
>Reporter: Sergey Pushkin
>Assignee: Daniel Kulp
>Priority: Critical
> Fix For: 3.1.16, 3.2.5
>
>
>
> I use cxf codegen plugin and i have separate maven profile to generate code
> by wsdl. My problem in extraarg tag.
> i have soap connectors, that have pom where is configuration of codegen
> plugin. When project runnnig with generate code by wsdl profile
> ${wsdl.extraarg.keep} equal "-keep." And that good work.
> When runnig another maven profile my ${wsdl.extraarg.keep} don't initialize
> and in codegen in extraarg put emty string " ".
> {code:java}
>
> org.apache.cxf
> cxf-codegen-plugin
> 3.1.6
>
>
> generate-sources
> generate-sources
>
> src/main/java
>
>
>
> ../wsdl//ReferenceDataService.wsdl
>
>
> ${wsdl.extraarg.keep}
>
>
>
> UTF-8
>
>
> wsdl2java
>
>
>
>
> {code}
> In result i have error.
> [ERROR] Failed to execute goal
> org.apache.cxf:cxf-codegen-plugin:3.1.6:wsdl2java (generate-sources) on
> project test-project: Execution generate-sources of goal
> org.apache.cxf:cxf-codegen-plugin:3.1.6:wsdl2java failed:
> org.apache.cxf.tools.common.toolspec.parser.BadUsageException: Unexpected
> argument:
> [file:/C:/Projects/test/backend/soap-connectors/wsdl/ReferenceDataService.wsdl|file:///C:/Projects/test/backend/soap-connectors/wsdl/ReferenceDataService.wsdl]
> it's couse emppty is "The path and name of the WSDL file to use in generating
> the code."
> Okey. I cheat and use that:
> {code:java}
>
> org.apache.cxf
> cxf-codegen-plugin
> 3.2.4
>
>
> generate-sources
> generate-sources
>
> src/main/java
>
>
>
> ../wsdl//ReferenceDataService.wsdl
>
>
>
> ../wsdl//ReferenceDataService.wsdl
> ${wsdl.extraarg.keep}
>
>
>
> UTF-8
>
>
> wsdl2java
>
>
>
> {code}
> In result i have error "Unexpected argument" with empty string.
> [ERROR] Failed to execute goal
> org.apache.cxf:cxf-codegen-plugin:3.2.4:wsdl2java (generate-sources) on
> project test-project: Execution generate-sources of goal
> org.apache.cxf:cxf-codegen-plugin:3.2.4:wsdl2java failed:
> org.apache.cxf.tools.common.toolspec.parser.BadUsageException: Unexpected
> argument:
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CXF-6747) XSD to Java problem with enums
[
https://issues.apache.org/jira/browse/CXF-6747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated CXF-6747:
-
Attachment: Screen Shot 2018-05-04 at 10.21.49 AM.png
> XSD to Java problem with enums
> --
>
> Key: CXF-6747
> URL: https://issues.apache.org/jira/browse/CXF-6747
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
>Affects Versions: 3.0.1
>Reporter: Dusan Slivka
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: Invalid
>
> Attachments: Screen Shot 2018-05-04 at 10.15.22 AM.png, Screen Shot
> 2018-05-04 at 10.21.49 AM.png
>
>
> Starting with version 3, roundtrip wsdl -> Java -> wsdl produces output wsdl
> different from wsdl on input, if there are enums used. For example, I have
> the folowing XSD type in source wsdl:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> which produces (cxf-codegen-plugin:3.0.5:wsdl2java) the following Java code:
> {code:java}
> @XmlAccessorType(XmlAccessType.FIELD)
> @XmlType(name = "DigestType", propOrder = {
> "digestValue",
> "digestType"
> })public class DigestType {
> protected String digestValue;
> @XmlSchemaType(name = "string") // WHY??
> protected ChecksumType digestType;
> }
> {code}
> And resulting wsdl for published service looks like this:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> The problem is caused by @XmlSchemaType(name = "string") annotation. I think
> resulting wsdl should be equal to source wsdl.
> See also:
> [https://github.com/gf-metro/jaxb/issues/21]
> [http://stackoverflow.com/questions/33346803/how-to-tell-jaxb-not-to-generate-xmlschematype-annotation]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-6747) XSD to Java problem with enums
[
https://issues.apache.org/jira/browse/CXF-6747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16463933#comment-16463933
]
Daniel Kulp commented on CXF-6747:
--
It seems to be working... If I remove the -Xbug986 from some of our poms,
there definitely are changes to the generated code.
!Screen Shot 2018-05-04 at 10.15.22 AM.png!
> XSD to Java problem with enums
> --
>
> Key: CXF-6747
> URL: https://issues.apache.org/jira/browse/CXF-6747
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
>Affects Versions: 3.0.1
>Reporter: Dusan Slivka
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: Invalid
>
> Attachments: Screen Shot 2018-05-04 at 10.15.22 AM.png
>
>
> Starting with version 3, roundtrip wsdl -> Java -> wsdl produces output wsdl
> different from wsdl on input, if there are enums used. For example, I have
> the folowing XSD type in source wsdl:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> which produces (cxf-codegen-plugin:3.0.5:wsdl2java) the following Java code:
> {code:java}
> @XmlAccessorType(XmlAccessType.FIELD)
> @XmlType(name = "DigestType", propOrder = {
> "digestValue",
> "digestType"
> })public class DigestType {
> protected String digestValue;
> @XmlSchemaType(name = "string") // WHY??
> protected ChecksumType digestType;
> }
> {code}
> And resulting wsdl for published service looks like this:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> The problem is caused by @XmlSchemaType(name = "string") annotation. I think
> resulting wsdl should be equal to source wsdl.
> See also:
> [https://github.com/gf-metro/jaxb/issues/21]
> [http://stackoverflow.com/questions/33346803/how-to-tell-jaxb-not-to-generate-xmlschematype-annotation]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CXF-6747) XSD to Java problem with enums
[
https://issues.apache.org/jira/browse/CXF-6747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated CXF-6747:
-
Attachment: Screen Shot 2018-05-04 at 10.15.22 AM.png
> XSD to Java problem with enums
> --
>
> Key: CXF-6747
> URL: https://issues.apache.org/jira/browse/CXF-6747
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
>Affects Versions: 3.0.1
>Reporter: Dusan Slivka
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: Invalid
>
> Attachments: Screen Shot 2018-05-04 at 10.15.22 AM.png
>
>
> Starting with version 3, roundtrip wsdl -> Java -> wsdl produces output wsdl
> different from wsdl on input, if there are enums used. For example, I have
> the folowing XSD type in source wsdl:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> which produces (cxf-codegen-plugin:3.0.5:wsdl2java) the following Java code:
> {code:java}
> @XmlAccessorType(XmlAccessType.FIELD)
> @XmlType(name = "DigestType", propOrder = {
> "digestValue",
> "digestType"
> })public class DigestType {
> protected String digestValue;
> @XmlSchemaType(name = "string") // WHY??
> protected ChecksumType digestType;
> }
> {code}
> And resulting wsdl for published service looks like this:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> The problem is caused by @XmlSchemaType(name = "string") annotation. I think
> resulting wsdl should be equal to source wsdl.
> See also:
> [https://github.com/gf-metro/jaxb/issues/21]
> [http://stackoverflow.com/questions/33346803/how-to-tell-jaxb-not-to-generate-xmlschematype-annotation]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (CXF-7720) Header values are lost
[ https://issues.apache.org/jira/browse/CXF-7720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp reassigned CXF-7720: Assignee: Daniel Kulp (was: Colm O hEigeartaigh) > Header values are lost > --- > > Key: CXF-7720 > URL: https://issues.apache.org/jira/browse/CXF-7720 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 3.2.4 > Environment: Windows 7 > Java 1.8.0_152 > SoapUI 5.2.1 >Reporter: Vladimir Bogatyrov >Assignee: Daniel Kulp >Priority: Major > Attachments: consumer.zip, rest_mock_provider_soapui_project.xml > > > When a request is made by WebClient to a service that returns several headers > of the same name but with different cases, e.g.: > "Set-Cookie" with value "aaa" > "set-cookie" with value "bbb" > "SET-COOKIE" with value "ccc" > then the response object contains only one header value, all other values are > lost. > The issue is not reproducible in all cases, but only with some service > providers and is probably caused by low-level details of provider > implementation. > > In the attachment there is a SoapUI REST mock service and CXF WebClient-based > consumer with which the issue is reproducible. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CXF-7720) Header values are lost
[ https://issues.apache.org/jira/browse/CXF-7720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16453218#comment-16453218 ] Daniel Kulp edited comment on CXF-7720 at 4/25/18 11:11 PM: Actually, just changed the server side to send different case headers instead of all three being the "proper" Set-Cookie and the test does fail. I'll take a look tomorrow. It's definitely an issue on the server side as it's only sending a single Set-Cookie header back: ``` HTTP/1.1 200 OK Date: Wed, 25 Apr 2018 23:10:06 GMT Set-Cookie: COOKIETWO=dummy2; expires=Sat, 20-Nov-2010 19:11:32 GMT; Path=/ BookId: 123 MAP-NAME: javax.ws.rs.core.MultivaluedMap Content-Length: 0 Server: Jetty(9.4.8.v20171121) ``` was (Author: dkulp): Actually, just changed the server side to send different case headers instead of all three being the "proper" Set-Cookie and the test does fail. I'll take a look tomorrow. > Header values are lost > --- > > Key: CXF-7720 > URL: https://issues.apache.org/jira/browse/CXF-7720 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 3.2.4 > Environment: Windows 7 > Java 1.8.0_152 > SoapUI 5.2.1 >Reporter: Vladimir Bogatyrov >Assignee: Colm O hEigeartaigh >Priority: Major > Attachments: consumer.zip, rest_mock_provider_soapui_project.xml > > > When a request is made by WebClient to a service that returns several headers > of the same name but with different cases, e.g.: > "Set-Cookie" with value "aaa" > "set-cookie" with value "bbb" > "SET-COOKIE" with value "ccc" > then the response object contains only one header value, all other values are > lost. > The issue is not reproducible in all cases, but only with some service > providers and is probably caused by low-level details of provider > implementation. > > In the attachment there is a SoapUI REST mock service and CXF WebClient-based > consumer with which the issue is reproducible. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CXF-7720) Header values are lost
[
https://issues.apache.org/jira/browse/CXF-7720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16453218#comment-16453218
]
Daniel Kulp edited comment on CXF-7720 at 4/25/18 11:11 PM:
Actually, just changed the server side to send different case headers instead
of all three being the "proper" Set-Cookie and the test does fail. I'll take
a look tomorrow. It's definitely an issue on the server side as it's only
sending a single Set-Cookie header back:
{code:java}
HTTP/1.1 200 OK
Date: Wed, 25 Apr 2018 23:10:06 GMT
Set-Cookie: COOKIETWO=dummy2; expires=Sat, 20-Nov-2010 19:11:32 GMT; Path=/
BookId: 123
MAP-NAME: javax.ws.rs.core.MultivaluedMap
Content-Length: 0
Server: Jetty(9.4.8.v20171121)
{code}
was (Author: dkulp):
Actually, just changed the server side to send different case headers instead
of all three being the "proper" Set-Cookie and the test does fail. I'll take
a look tomorrow. It's definitely an issue on the server side as it's only
sending a single Set-Cookie header back:
```
HTTP/1.1 200 OK
Date: Wed, 25 Apr 2018 23:10:06 GMT
Set-Cookie: COOKIETWO=dummy2; expires=Sat, 20-Nov-2010 19:11:32 GMT; Path=/
BookId: 123
MAP-NAME: javax.ws.rs.core.MultivaluedMap
Content-Length: 0
Server: Jetty(9.4.8.v20171121)
```
> Header values are lost
> ---
>
> Key: CXF-7720
> URL: https://issues.apache.org/jira/browse/CXF-7720
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 3.2.4
> Environment: Windows 7
> Java 1.8.0_152
> SoapUI 5.2.1
>Reporter: Vladimir Bogatyrov
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Attachments: consumer.zip, rest_mock_provider_soapui_project.xml
>
>
> When a request is made by WebClient to a service that returns several headers
> of the same name but with different cases, e.g.:
> "Set-Cookie" with value "aaa"
> "set-cookie" with value "bbb"
> "SET-COOKIE" with value "ccc"
> then the response object contains only one header value, all other values are
> lost.
> The issue is not reproducible in all cases, but only with some service
> providers and is probably caused by low-level details of provider
> implementation.
>
> In the attachment there is a SoapUI REST mock service and CXF WebClient-based
> consumer with which the issue is reproducible.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7720) Header values are lost
[ https://issues.apache.org/jira/browse/CXF-7720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16453218#comment-16453218 ] Daniel Kulp commented on CXF-7720: -- Actually, just changed the server side to send different case headers instead of all three being the "proper" Set-Cookie and the test does fail. I'll take a look tomorrow. > Header values are lost > --- > > Key: CXF-7720 > URL: https://issues.apache.org/jira/browse/CXF-7720 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 3.2.4 > Environment: Windows 7 > Java 1.8.0_152 > SoapUI 5.2.1 >Reporter: Vladimir Bogatyrov >Assignee: Colm O hEigeartaigh >Priority: Major > Attachments: consumer.zip, rest_mock_provider_soapui_project.xml > > > When a request is made by WebClient to a service that returns several headers > of the same name but with different cases, e.g.: > "Set-Cookie" with value "aaa" > "set-cookie" with value "bbb" > "SET-COOKIE" with value "ccc" > then the response object contains only one header value, all other values are > lost. > The issue is not reproducible in all cases, but only with some service > providers and is probably caused by low-level details of provider > implementation. > > In the attachment there is a SoapUI REST mock service and CXF WebClient-based > consumer with which the issue is reproducible. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7720) Header values are lost
[ https://issues.apache.org/jira/browse/CXF-7720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16453214#comment-16453214 ] Daniel Kulp commented on CXF-7720: -- We have a test case that does check to make sure three separate Set-Cookie headers are returned properly. See: https://github.com/apache/cxf/blob/master/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/JAXRSClientServerBookTest.java#L930 > Header values are lost > --- > > Key: CXF-7720 > URL: https://issues.apache.org/jira/browse/CXF-7720 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 3.2.4 > Environment: Windows 7 > Java 1.8.0_152 > SoapUI 5.2.1 >Reporter: Vladimir Bogatyrov >Assignee: Colm O hEigeartaigh >Priority: Major > Attachments: consumer.zip, rest_mock_provider_soapui_project.xml > > > When a request is made by WebClient to a service that returns several headers > of the same name but with different cases, e.g.: > "Set-Cookie" with value "aaa" > "set-cookie" with value "bbb" > "SET-COOKIE" with value "ccc" > then the response object contains only one header value, all other values are > lost. > The issue is not reproducible in all cases, but only with some service > providers and is probably caused by low-level details of provider > implementation. > > In the attachment there is a SoapUI REST mock service and CXF WebClient-based > consumer with which the issue is reproducible. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7710) ClientImpl is memory-leak prone
[ https://issues.apache.org/jira/browse/CXF-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16450371#comment-16450371 ] Daniel Kulp commented on CXF-7710: -- I believe this was fixed as part of CXF-7591 (although that was never marked resolved as the user never responded affirmative). CXF 3.2.4 definitely has that change. A call to client.getResponseContext().clear() will completely remove the item from the map. > ClientImpl is memory-leak prone > --- > > Key: CXF-7710 > URL: https://issues.apache.org/jira/browse/CXF-7710 > Project: CXF > Issue Type: Bug >Reporter: Facundo Velazquez >Priority: Critical > Attachments: heapdump_Leak_Suspects.zip, leak capture.png > > > In the Mule ESB we are seeing a memory leak caused by non-released objects in > the > org.apache.cxf.endpoint.ClientImpl. > After some research, I could see that the requestContext and the > responseContext have a thread local implementation. As our code calls the > client from different threads, in a high load scenario, lots of entries will > be put in the requestContext map. Take into account that we clean each > requestContext value (that is an EchoContext object), but an entry per thread > is kept alive in the requestContext map (with an empty EchoContext map). > You'll able to see in the attached files that this is causing a memory leak. > Even in my tests trying to reproduce the issue, I've obtained a fatal > OutOfMemoryError. > Looking at the code, I've seen that the request context is a WeakHashMap, > however the keys are threads. I supposed the purpose of this implementation > is that entries can be removed when necessary by the garbage collector. > However, if the threads are pooled (which is our case), strong references > will be pointing to them, and will be never collected. > I suppose an easy solution could be to use the thread names as keys instead > threads objects directly. If this approach is taken, consider using string > constructors to wrap the literal name for ensuring its garbage collection > (since this is another well-know issue --> > [https://stackoverflow.com/questions/14494875/weakreference-string-didnt-garbage-collected-how|https://stackoverflow.com/questions/14494875/weakreference-string-didnt-garbage-collected-how).] > ). > Another solution, that entails more changes, would be to use a Guava Cache, > setting an expiration time. > If the first approach is implemented, could you provide a way to clean the > requestContext programmatically?, so in this way, we don't have to depend on > the garbage collection process. > Thank you very much. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-7679) PhaseManager is not loaded in bus Extension
[
https://issues.apache.org/jira/browse/CXF-7679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-7679.
--
Resolution: Not A Problem
Assignee: Daniel Kulp
Fix Version/s: Invalid
> PhaseManager is not loaded in bus Extension
> ---
>
> Key: CXF-7679
> URL: https://issues.apache.org/jira/browse/CXF-7679
> Project: CXF
> Issue Type: Bug
> Components: Bus
>Affects Versions: 3.2.2
>Reporter: satishbt
>Assignee: Daniel Kulp
>Priority: Major
> Labels: maven
> Fix For: Invalid
>
>
> I am using below packages
>
>
> org.apache.cxf
> cxf-rt-rs-client
> ${cxf.rs.version}
>
>
> org.apache.cxf
> cxf-rt-frontend-jaxrs
> ${cxf.rs.version}
>
>
> and
> maven-shade-plugin
> 2.4.3
> to package the my module jar .
> doing a simple rest call.
> return (DeviceTerminal) webClient.path("device").query("tac",
> tacInfo)
> .get(DeviceTerminal.class);
> });
>
> Problem i am seeing is when i run the jar and make rest call getting a
> nullpointer exception due to phasemanager.class is not there in the extension
> but i could see that bus-extensions.txt has the entry.
> I could run the test case from intellij ide but when run the application from
> command line. I am getting the below error.
> 593 [vert.x-eventloop-thread-0] DEBUG com.telus.handler.RestHttpErrorHandler
> - Handling REST API error ' (ContextMap={})
> java.lang.NullPointerException: null
> at
> org.apache.cxf.jaxrs.client.AbstractClient.setupOutInterceptorChain(AbstractClient.java:941)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> org.apache.cxf.jaxrs.client.AbstractClient.createMessage(AbstractClient.java:1013)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> org.apache.cxf.jaxrs.client.WebClient.finalizeMessage(WebClient.java:1075)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> org.apache.cxf.jaxrs.client.WebClient.doChainedInvocation(WebClient.java:1048)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:897)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:866)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at org.apache.cxf.jaxrs.client.WebClient.invoke(WebClient.java:431)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at org.apache.cxf.jaxrs.client.WebClient.get(WebClient.java:611)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> com.telus.simota.client.ris.RISClientService.lambda$getDeviceTerminalForaGivenTac$0(RISClientService.java:23)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> com.telus.simota.client.APIClientComponent.sendRequest(APIClientComponent.java:32)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> com.telus.simota.client.ris.RISClientService.getDeviceTerminalForaGivenTac(RISClientService.java:20)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> com.telus.simota.add.handler.DeviceSwapEventHandler.handle(DeviceSwapEventHandler.java:41)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at io.vertx.ext.web.impl.RouteImpl.handleContext(RouteImpl.java:219)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> io.vertx.ext.web.impl.RoutingContextImplBase.iterateNext(RoutingContextImplBase.java:120)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> io.vertx.ext.web.impl.RoutingContextImpl.next(RoutingContextImpl.java:120)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> com.telus.simota.transform.NotificationRequest.handle(NotificationRequest.java:48)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at io.vertx.ext.web.impl.RouteImpl.handleContext(RouteImpl.java:219)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> io.vertx.ext.web.impl.RoutingContextImplBase.iterateNext(RoutingContextImplBase.java:120)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> io.vertx.ext.web.impl.RoutingContextImpl.next(RoutingContextImpl.java:120)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> com.telus.handler.validators.XMLContentValidator.validateContent(XMLContentValidator.java:76)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at io.vertx.ext.web.impl.RouteImpl.handleContext(RouteImpl.java:219)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> io.vertx.ext.web.impl.RoutingContextImplBase.iterateNext(RoutingContextImplBase.java:120)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> io.vertx.ext.web.impl.RoutingContextImpl.next(RoutingContextImpl.java:120)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> io.vertx.ext.web.handler.impl.BodyHandlerImpl.handle(BodyHandlerImpl.java:82)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> io.vertx.ext.web.handler.impl.BodyHandlerImpl.handle(BodyHandlerImpl.java:42)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at io.vertx.ext.web.impl.RouteI
[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] [Resolved] (CXF-7676) TCK: An Entity OutputStream is not set before ClientRequestFilterInterceptor.handleMessage() processes a user's ClientRequestFilter which modifies the EntityStream via Cl
[ https://issues.apache.org/jira/browse/CXF-7676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-7676. -- Resolution: Fixed Assignee: Daniel Kulp > TCK: An Entity OutputStream is not set before > ClientRequestFilterInterceptor.handleMessage() processes a user's > ClientRequestFilter which modifies the EntityStream via > ClientRequestContext.setEntityStream() > --- > > Key: CXF-7676 > URL: https://issues.apache.org/jira/browse/CXF-7676 > Project: CXF > Issue Type: Bug > Components: JAX-RS > Environment: all versions, any environment >Reporter: Adam Anderson >Assignee: Daniel Kulp >Priority: Major > Fix For: 3.2.3 > > Original Estimate: 1h > Remaining Estimate: 1h > > CXF is failing a test in both the JAXRS 2.0 and 2.1 TCKs where a user creates > a ClientRequestFilter which wraps the EntityStream in the filter() method via > ClientRequestContext.setEntityStream(). > CXF uses Phases to order the interceptors in the PhaseInterceptorChain. > [http://cxf.apache.org/docs/interceptors.html] > A customer's client filter code gets executed in > ClientRequestFilterInterceptor.handleMessage() during the PRE_LOGICAL phase > of the outgoing chain. > We don't actually create the entity output stream until HTTPConduit.prepare() > which is called by MessageSenderInterceptor.handleMessage() during the > PREPARE_SEND phase of the outgoing chain. > As a result, any interaction/modification of the entity stream by the user > gets overwritten. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7679) PhaseManager is not loaded in bus Extension
[
https://issues.apache.org/jira/browse/CXF-7679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated CXF-7679:
-
Fix Version/s: (was: 3.2.3)
> PhaseManager is not loaded in bus Extension
> ---
>
> Key: CXF-7679
> URL: https://issues.apache.org/jira/browse/CXF-7679
> Project: CXF
> Issue Type: Bug
> Components: Bus
>Affects Versions: 3.2.2
>Reporter: satishbt
>Priority: Major
> Labels: maven
>
> I am using below packages
>
>
> org.apache.cxf
> cxf-rt-rs-client
> ${cxf.rs.version}
>
>
> org.apache.cxf
> cxf-rt-frontend-jaxrs
> ${cxf.rs.version}
>
>
> and
> maven-shade-plugin
> 2.4.3
> to package the my module jar .
> doing a simple rest call.
> return (DeviceTerminal) webClient.path("device").query("tac",
> tacInfo)
> .get(DeviceTerminal.class);
> });
>
> Problem i am seeing is when i run the jar and make rest call getting a
> nullpointer exception due to phasemanager.class is not there in the extension
> but i could see that bus-extensions.txt has the entry.
> I could run the test case from intellij ide but when run the application from
> command line. I am getting the below error.
> 593 [vert.x-eventloop-thread-0] DEBUG com.telus.handler.RestHttpErrorHandler
> - Handling REST API error ' (ContextMap={})
> java.lang.NullPointerException: null
> at
> org.apache.cxf.jaxrs.client.AbstractClient.setupOutInterceptorChain(AbstractClient.java:941)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> org.apache.cxf.jaxrs.client.AbstractClient.createMessage(AbstractClient.java:1013)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> org.apache.cxf.jaxrs.client.WebClient.finalizeMessage(WebClient.java:1075)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> org.apache.cxf.jaxrs.client.WebClient.doChainedInvocation(WebClient.java:1048)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:897)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:866)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at org.apache.cxf.jaxrs.client.WebClient.invoke(WebClient.java:431)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at org.apache.cxf.jaxrs.client.WebClient.get(WebClient.java:611)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> com.telus.simota.client.ris.RISClientService.lambda$getDeviceTerminalForaGivenTac$0(RISClientService.java:23)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> com.telus.simota.client.APIClientComponent.sendRequest(APIClientComponent.java:32)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> com.telus.simota.client.ris.RISClientService.getDeviceTerminalForaGivenTac(RISClientService.java:20)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> com.telus.simota.add.handler.DeviceSwapEventHandler.handle(DeviceSwapEventHandler.java:41)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at io.vertx.ext.web.impl.RouteImpl.handleContext(RouteImpl.java:219)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> io.vertx.ext.web.impl.RoutingContextImplBase.iterateNext(RoutingContextImplBase.java:120)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> io.vertx.ext.web.impl.RoutingContextImpl.next(RoutingContextImpl.java:120)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> com.telus.simota.transform.NotificationRequest.handle(NotificationRequest.java:48)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at io.vertx.ext.web.impl.RouteImpl.handleContext(RouteImpl.java:219)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> io.vertx.ext.web.impl.RoutingContextImplBase.iterateNext(RoutingContextImplBase.java:120)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> io.vertx.ext.web.impl.RoutingContextImpl.next(RoutingContextImpl.java:120)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> com.telus.handler.validators.XMLContentValidator.validateContent(XMLContentValidator.java:76)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at io.vertx.ext.web.impl.RouteImpl.handleContext(RouteImpl.java:219)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> io.vertx.ext.web.impl.RoutingContextImplBase.iterateNext(RoutingContextImplBase.java:120)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> io.vertx.ext.web.impl.RoutingContextImpl.next(RoutingContextImpl.java:120)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> io.vertx.ext.web.handler.impl.BodyHandlerImpl.handle(BodyHandlerImpl.java:82)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> io.vertx.ext.web.handler.impl.BodyHandlerImpl.handle(BodyHandlerImpl.java:42)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at io.vertx.ext.web.impl.RouteImpl.handleContext(RouteImpl.java:219)
> ~[MS-APIGateway-1.0.0-microsvc-fat.jar:?]
> at
> io.vertx.ext.web.impl.RoutingCont
[jira] [Resolved] (CXF-7669) Cxf encodes escape caracters twice in JDK9.0.5 and JDK8_161
[
https://issues.apache.org/jira/browse/CXF-7669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-7669.
--
Resolution: Fixed
> Cxf encodes escape caracters twice in JDK9.0.5 and JDK8_161
> ---
>
> Key: CXF-7669
> URL: https://issues.apache.org/jira/browse/CXF-7669
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Mark Czubin
>Assignee: Daniel Kulp
>Priority: Critical
> Fix For: 3.2.3
>
> Attachments: ExampleService.wsdl
>
>
> When our response text contains escape characters then those will be encoded
> twice.
> For example when I return "hello > world". Cxf will encode this as "hello &>
> world"
> {code:java}
> hello &> world{code}
>
> Below a test with all the interceptors used in our setup on production:
> {code:java}
> package be.vlaanderen.omgeving.rest.controller.parameter.v1;
> import org.apache.cxf.Bus;
> import org.apache.cxf.BusFactory;
> import org.apache.cxf.binding.Binding;
> import org.apache.cxf.binding.BindingFactory;
> import org.apache.cxf.binding.BindingFactoryManager;
> import org.apache.cxf.binding.soap.SoapMessage;
> import org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor;
> import org.apache.cxf.endpoint.Endpoint;
> import org.apache.cxf.endpoint.EndpointException;
> import org.apache.cxf.endpoint.EndpointImpl;
> import org.apache.cxf.jaxb.JAXBDataBinding;
> import org.apache.cxf.message.Exchange;
> import org.apache.cxf.message.ExchangeImpl;
> import org.apache.cxf.message.MessageImpl;
> import org.apache.cxf.phase.PhaseInterceptorChain;
> import org.apache.cxf.service.Service;
> import org.apache.cxf.service.model.BindingOperationInfo;
> import org.apache.cxf.service.model.EndpointInfo;
> import org.apache.cxf.staxutils.StaxUtils;
> import org.apache.cxf.wsdl.interceptors.BareOutInterceptor;
> import org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor;
> import org.apache.cxf.wsdl11.WSDLServiceFactory;
> import org.junit.Test;
> import javax.xml.bind.JAXBContext;
> import javax.xml.bind.JAXBException;
> import javax.xml.namespace.QName;
> import javax.xml.stream.XMLInputFactory;
> import javax.xml.stream.XMLOutputFactory;
> import javax.xml.stream.XMLStreamException;
> import javax.xml.stream.XMLStreamReader;
> import javax.xml.stream.XMLStreamWriter;
> import java.io.ByteArrayInputStream;
> import java.io.ByteArrayOutputStream;
> import java.util.List;
> import java.util.TreeSet;
> import static java.util.Collections.emptyList;
> import static
> org.apache.cxf.interceptor.AbstractOutDatabindingInterceptor.OUT_BUFFERING;
> import static org.assertj.core.api.Assertions.assertThat;
> import static org.mockito.BDDMockito.given;
> import static org.mockito.Mockito.mock;
> public class CxfIsUnstable {
> CxfFacade cxf = new CxfFacade();
> @Test
> public void
> givenAResponseWithAmpersans_whenMarshallingToXml_theAmpersandAreEncoded_onlyOnce()
> throws Exception {
> cxf.setupExampleService();
> String request = cxf.demarshallRequest("hello &
> world");
> assertThat(request).isEqualTo("hello & world");
> String responseXml = cxf.marshallResponse("hello & world");
> assertThat(responseXml).isEqualTo("hello &
> world<");
> }
> static class CxfFacade {
> private final SAAJOutInterceptor saajOutInterceptor = new
> SAAJOutInterceptor();
> private final BareOutInterceptor outInterceptor = new
> BareOutInterceptor();
> private final DocLiteralInInterceptor inInterceptor = new
> DocLiteralInInterceptor();
> private SoapMessage message;
> private List messageContents;
> public String demarshallRequest(String input) throws
> XMLStreamException {
> message.setContent(XMLStreamReader.class,
> XMLInputFactory.newInstance().createXMLStreamReader(new
> ByteArrayInputStream(input.getBytes(;
>
> StaxUtils.skipToStartOfElement(message.getContent(XMLStreamReader.class));
> inInterceptor.handleMessage(message);
> assertThat(message.getContent(Exception.class)).isNull();
> messageContents = message.getContent(List.class);
> String requestContent = (String) messageContents.get(0);
> saajOutInterceptor.handleMessage(message);
> return requestContent;
> }
> public String marshallResponse(String responseBody) throws Exception {
> messageContents.set(0, responseBody);
> ByteArrayOutputStream boas = new ByteArrayOutputStream();
> XMLOutputFactory xmlOutputFactory =
> XMLOutputFactory.newInstance();
> XMLStreamWriter output =
> xmlOutputFactory.createXMLStreamWriter(boas);
> message.setContent(XMLStreamWriter.class, output);
> mess
[jira] [Updated] (CXF-7669) Cxf encodes escape caracters twice in JDK9.0.5 and JDK8_161
[
https://issues.apache.org/jira/browse/CXF-7669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated CXF-7669:
-
Fix Version/s: (was: NeedMoreInfo)
3.2.3
> Cxf encodes escape caracters twice in JDK9.0.5 and JDK8_161
> ---
>
> Key: CXF-7669
> URL: https://issues.apache.org/jira/browse/CXF-7669
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Mark Czubin
>Assignee: Daniel Kulp
>Priority: Critical
> Fix For: 3.2.3
>
> Attachments: ExampleService.wsdl
>
>
> When our response text contains escape characters then those will be encoded
> twice.
> For example when I return "hello > world". Cxf will encode this as "hello &>
> world"
> {code:java}
> hello &> world{code}
>
> Below a test with all the interceptors used in our setup on production:
> {code:java}
> package be.vlaanderen.omgeving.rest.controller.parameter.v1;
> import org.apache.cxf.Bus;
> import org.apache.cxf.BusFactory;
> import org.apache.cxf.binding.Binding;
> import org.apache.cxf.binding.BindingFactory;
> import org.apache.cxf.binding.BindingFactoryManager;
> import org.apache.cxf.binding.soap.SoapMessage;
> import org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor;
> import org.apache.cxf.endpoint.Endpoint;
> import org.apache.cxf.endpoint.EndpointException;
> import org.apache.cxf.endpoint.EndpointImpl;
> import org.apache.cxf.jaxb.JAXBDataBinding;
> import org.apache.cxf.message.Exchange;
> import org.apache.cxf.message.ExchangeImpl;
> import org.apache.cxf.message.MessageImpl;
> import org.apache.cxf.phase.PhaseInterceptorChain;
> import org.apache.cxf.service.Service;
> import org.apache.cxf.service.model.BindingOperationInfo;
> import org.apache.cxf.service.model.EndpointInfo;
> import org.apache.cxf.staxutils.StaxUtils;
> import org.apache.cxf.wsdl.interceptors.BareOutInterceptor;
> import org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor;
> import org.apache.cxf.wsdl11.WSDLServiceFactory;
> import org.junit.Test;
> import javax.xml.bind.JAXBContext;
> import javax.xml.bind.JAXBException;
> import javax.xml.namespace.QName;
> import javax.xml.stream.XMLInputFactory;
> import javax.xml.stream.XMLOutputFactory;
> import javax.xml.stream.XMLStreamException;
> import javax.xml.stream.XMLStreamReader;
> import javax.xml.stream.XMLStreamWriter;
> import java.io.ByteArrayInputStream;
> import java.io.ByteArrayOutputStream;
> import java.util.List;
> import java.util.TreeSet;
> import static java.util.Collections.emptyList;
> import static
> org.apache.cxf.interceptor.AbstractOutDatabindingInterceptor.OUT_BUFFERING;
> import static org.assertj.core.api.Assertions.assertThat;
> import static org.mockito.BDDMockito.given;
> import static org.mockito.Mockito.mock;
> public class CxfIsUnstable {
> CxfFacade cxf = new CxfFacade();
> @Test
> public void
> givenAResponseWithAmpersans_whenMarshallingToXml_theAmpersandAreEncoded_onlyOnce()
> throws Exception {
> cxf.setupExampleService();
> String request = cxf.demarshallRequest("hello &
> world");
> assertThat(request).isEqualTo("hello & world");
> String responseXml = cxf.marshallResponse("hello & world");
> assertThat(responseXml).isEqualTo("hello &
> world<");
> }
> static class CxfFacade {
> private final SAAJOutInterceptor saajOutInterceptor = new
> SAAJOutInterceptor();
> private final BareOutInterceptor outInterceptor = new
> BareOutInterceptor();
> private final DocLiteralInInterceptor inInterceptor = new
> DocLiteralInInterceptor();
> private SoapMessage message;
> private List messageContents;
> public String demarshallRequest(String input) throws
> XMLStreamException {
> message.setContent(XMLStreamReader.class,
> XMLInputFactory.newInstance().createXMLStreamReader(new
> ByteArrayInputStream(input.getBytes(;
>
> StaxUtils.skipToStartOfElement(message.getContent(XMLStreamReader.class));
> inInterceptor.handleMessage(message);
> assertThat(message.getContent(Exception.class)).isNull();
> messageContents = message.getContent(List.class);
> String requestContent = (String) messageContents.get(0);
> saajOutInterceptor.handleMessage(message);
> return requestContent;
> }
> public String marshallResponse(String responseBody) throws Exception {
> messageContents.set(0, responseBody);
> ByteArrayOutputStream boas = new ByteArrayOutputStream();
> XMLOutputFactory xmlOutputFactory =
> XMLOutputFactory.newInstance();
> XMLStreamWriter output =
> xmlOutputFactory.createXMLStreamWriter(boas);
> message.setContent(XMLStr
[jira] [Reopened] (CXF-7669) Cxf encodes escape caracters twice in JDK9.0.5 and JDK8_161
[
https://issues.apache.org/jira/browse/CXF-7669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp reopened CXF-7669:
--
Assignee: Daniel Kulp (was: Freeman Fang)
I'm able to reproduce this with some of my tests. This is due to the changes
from CXF-7520 and actually one of the tests in that commit shows the issue.
The javascript test that was changed in that commit should NOT have been
changed as the output shows the double escape.
In CXF, we have 3 main ways we write XML out: direct to OutputStream, to Node,
and to XMLStreamWriter. The escape handler should only be set for the first
case. In the other two, it should not be escaping anything as the Node should
have the unescaped value or the XMLStreamWriter will escape things.
Anyway, I'm testing some fixes now.
> Cxf encodes escape caracters twice in JDK9.0.5 and JDK8_161
> ---
>
> Key: CXF-7669
> URL: https://issues.apache.org/jira/browse/CXF-7669
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Mark Czubin
>Assignee: Daniel Kulp
>Priority: Critical
> Fix For: NeedMoreInfo
>
> Attachments: ExampleService.wsdl
>
>
> When our response text contains escape characters then those will be encoded
> twice.
> For example when I return "hello > world". Cxf will encode this as "hello &>
> world"
> {code:java}
> hello &> world{code}
>
> Below a test with all the interceptors used in our setup on production:
> {code:java}
> package be.vlaanderen.omgeving.rest.controller.parameter.v1;
> import org.apache.cxf.Bus;
> import org.apache.cxf.BusFactory;
> import org.apache.cxf.binding.Binding;
> import org.apache.cxf.binding.BindingFactory;
> import org.apache.cxf.binding.BindingFactoryManager;
> import org.apache.cxf.binding.soap.SoapMessage;
> import org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor;
> import org.apache.cxf.endpoint.Endpoint;
> import org.apache.cxf.endpoint.EndpointException;
> import org.apache.cxf.endpoint.EndpointImpl;
> import org.apache.cxf.jaxb.JAXBDataBinding;
> import org.apache.cxf.message.Exchange;
> import org.apache.cxf.message.ExchangeImpl;
> import org.apache.cxf.message.MessageImpl;
> import org.apache.cxf.phase.PhaseInterceptorChain;
> import org.apache.cxf.service.Service;
> import org.apache.cxf.service.model.BindingOperationInfo;
> import org.apache.cxf.service.model.EndpointInfo;
> import org.apache.cxf.staxutils.StaxUtils;
> import org.apache.cxf.wsdl.interceptors.BareOutInterceptor;
> import org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor;
> import org.apache.cxf.wsdl11.WSDLServiceFactory;
> import org.junit.Test;
> import javax.xml.bind.JAXBContext;
> import javax.xml.bind.JAXBException;
> import javax.xml.namespace.QName;
> import javax.xml.stream.XMLInputFactory;
> import javax.xml.stream.XMLOutputFactory;
> import javax.xml.stream.XMLStreamException;
> import javax.xml.stream.XMLStreamReader;
> import javax.xml.stream.XMLStreamWriter;
> import java.io.ByteArrayInputStream;
> import java.io.ByteArrayOutputStream;
> import java.util.List;
> import java.util.TreeSet;
> import static java.util.Collections.emptyList;
> import static
> org.apache.cxf.interceptor.AbstractOutDatabindingInterceptor.OUT_BUFFERING;
> import static org.assertj.core.api.Assertions.assertThat;
> import static org.mockito.BDDMockito.given;
> import static org.mockito.Mockito.mock;
> public class CxfIsUnstable {
> CxfFacade cxf = new CxfFacade();
> @Test
> public void
> givenAResponseWithAmpersans_whenMarshallingToXml_theAmpersandAreEncoded_onlyOnce()
> throws Exception {
> cxf.setupExampleService();
> String request = cxf.demarshallRequest("hello &
> world");
> assertThat(request).isEqualTo("hello & world");
> String responseXml = cxf.marshallResponse("hello & world");
> assertThat(responseXml).isEqualTo("hello &
> world<");
> }
> static class CxfFacade {
> private final SAAJOutInterceptor saajOutInterceptor = new
> SAAJOutInterceptor();
> private final BareOutInterceptor outInterceptor = new
> BareOutInterceptor();
> private final DocLiteralInInterceptor inInterceptor = new
> DocLiteralInInterceptor();
> private SoapMessage message;
> private List messageContents;
> public String demarshallRequest(String input) throws
> XMLStreamException {
> message.setContent(XMLStreamReader.class,
> XMLInputFactory.newInstance().createXMLStreamReader(new
> ByteArrayInputStream(input.getBytes(;
>
> StaxUtils.skipToStartOfElement(message.getContent(XMLStreamReader.class));
> inInterceptor.handleMessage(message);
> assertThat(message.getContent(Exception.class)).isNull();
> messageContents = messag
[jira] [Commented] (CXF-7668) Support Servlet API 3.0
[
https://issues.apache.org/jira/browse/CXF-7668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16387983#comment-16387983
]
Daniel Kulp commented on CXF-7668:
--
Just a note that I changed the title. We should still run on Servlet 3, but
we will need to continue to build with 3.1 as we should still be able to
leverage the NIO stuff in 3.1 if those API's are available.
> Support Servlet API 3.0
>
>
> Key: CXF-7668
> URL: https://issues.apache.org/jira/browse/CXF-7668
> Project: CXF
> Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
>
> {color:#80}When deploying cxf 3.2 on tomcat 7, it breaks because of a
> hard dependency {color}{color:#80}on Servlet 3.1 classes in
> Servlet3ContinuationProvider
> {color}{color:#80}(javax.servlet.WriteListener), which results in
> ClassNotFound at runtime. {color}{color:#80}At some point JAX-RS 2.1 API
> dropped NIO support and the dependecy on Servlet 3.1 API as well, right
> before releasing the spec (commit reference
> {color}+[https://github.com/jax-rs/api/commit/a4faa965bbe4d058caa41f56f712fa52fc9600fe#diff-bb05b5ab9309760c3271445278116a2f]+{color:#80}).
> {color}
> {color:#80}The Servlet 3.0 should be the base line.{color}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CXF-7668) Support Servlet API 3.0
[
https://issues.apache.org/jira/browse/CXF-7668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated CXF-7668:
-
Summary: Support Servlet API 3.0 (was: Downgrade the Servlet API to
Servlet 3.0)
> Support Servlet API 3.0
>
>
> Key: CXF-7668
> URL: https://issues.apache.org/jira/browse/CXF-7668
> Project: CXF
> Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
>
> {color:#80}When deploying cxf 3.2 on tomcat 7, it breaks because of a
> hard dependency {color}{color:#80}on Servlet 3.1 classes in
> Servlet3ContinuationProvider
> {color}{color:#80}(javax.servlet.WriteListener), which results in
> ClassNotFound at runtime. {color}{color:#80}At some point JAX-RS 2.1 API
> dropped NIO support and the dependecy on Servlet 3.1 API as well, right
> before releasing the spec (commit reference
> {color}+[https://github.com/jax-rs/api/commit/a4faa965bbe4d058caa41f56f712fa52fc9600fe#diff-bb05b5ab9309760c3271445278116a2f]+{color:#80}).
> {color}
> {color:#80}The Servlet 3.0 should be the base line.{color}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7653) Null pointer in JaxwsResponseCallback
[
https://issues.apache.org/jira/browse/CXF-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16387900#comment-16387900
]
Daniel Kulp commented on CXF-7653:
--
Freeman, the issue is that the ClientProxyFactoryBean, not being JAX-WS,
doesn't support the @SOAPBinding(parameterStyle =
SOAPBinding.ParameterStyle.BARE) annotation. Thus, it's properly expecting a
response. If you change the test to use the JaxWsProxyFactoryBean which does
handle that annotation, the test passes.
> Null pointer in JaxwsResponseCallback
> -
>
> Key: CXF-7653
> URL: https://issues.apache.org/jira/browse/CXF-7653
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.10
> Environment: AIX
>Reporter: Neal Johnson
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: 3.1.15, 3.2.3
>
>
> Occasionally we'll get a null pointer in the JAXWS code.
> Caused by: java.lang.NullPointerException
> at
> org.apache.cxf.jaxws.JaxwsResponseCallback.get(JaxwsResponseCallback.java:49)
> When we receive a SOAP message with an empty body (example below) the
> (T)callback.get()[0] line in JaxwsResponseCallback throws a null pointer
> exception. We're still unsure why we're getting a message with an empty body
> in the first place, and if that's AIX related or we're just lucky in other
> operating systems.
> {{http://www.w3.org/2003/05/soap-envelope";>}}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{}}
> We did some debugging and checked where our code diverged between the two
> types of messages. The below chunk of code is where it starts to unravel.
> {code:java|title=Code from within
> DocLiteralInInterceptor.java|borderStyle=solid}
> MessageContentsList parameters = new MessageContentsList();
> Exchange exchange = message.getExchange();
> BindingOperationInfo bop = exchange.getBindingOperationInfo();
> boolean client = isRequestor(message);
> //if body is empty and we have BindingOperationInfo, we do not need to match
> //operation anymore, just return
> if (bop != null && !StaxUtils.toNextElement(xmlReader)) {
> // body may be empty for partial response to decoupled request
> return;
> }
> ...
> // Lots of logic
> ...
> message.setContent(List.class, parameters);
> {code}
> ~~~
> When we do a StaxUtils.toNextElement that returns false, as it hits the end
> of the body immediately. This causes it to return without setting the
> MessageContentsList as a list on the message. Later, when the code tries to
> do a .getContent(List) it doesn't find anything, and this leads to it setting
> null as the first element returned on callback.get()[0].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7662) Problem writing SAAJ model to stream: Error writing request body to server
[
https://issues.apache.org/jira/browse/CXF-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16382294#comment-16382294
]
Daniel Kulp commented on CXF-7662:
--
This is occurring while writing to the output stream to send the data to the
server. It seems like the connection to the server is having an issue. You
would need to check the logs on the server side to see if there is anything of
importance there.
> Problem writing SAAJ model to stream: Error writing request body to server
> --
>
> Key: CXF-7662
> URL: https://issues.apache.org/jira/browse/CXF-7662
> Project: CXF
> Issue Type: Bug
> Components: Integration
>Affects Versions: 2.7.5
>Reporter: antoine charles
>Priority: Major
> Attachments: stack.txt
>
>
> We have a web portal calling regularly a service using cxf.
> Its production environment.
> Its has been working a for a while... And suddendly we had the stack trace
> bellow and also in PJ..
> Please can you help us to understand what happened , why and how to fix it
> 2018-02-27 15:31:11,891 plpriws303-Site Centralisé Divulgation
> AMF-ad9ac493-2751-451e-a8eb-dd4531c71096-POST [normal:view:RESSRC] WARN
> [org.apache.cxf.phase.PhaseInterceptorChain] Interceptor for
> {[http://desjardins.com/divulgations/schemas/v1]}
> DesjServiceDivulgation#
> {[http://desjardins.com/ServiceReglementaire.ServiceDivulgationAMF/schemas/v1]}
> deposerDocument has thrown exception, unwinding now:
> org.apache.cxf.binding.soap.SoapFault: Problem writing SAAJ model to stream:
> Error writing request body to server
> at
> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:221)
> at
> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:172)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271)
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:463)
>
> .
> Caused by: com.ctc.wstx.exc.WstxIOException: Error writing request body to
> server
> at
> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java:462)
> at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:676)
> at org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:652)
> at
> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEndingInterceptor.handleMessage(SAAJOutInterceptor.java:212)
> ... 196 more
> Caused by: java.io.IOException: Error writing request body to server
> at
> sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.checkError(HttpURLConnection.java:3253)
> at
> sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.write(HttpURLConnection.java:3236)
> at
> org.apache.cxf.io.CacheAndWriteOutputStream.write(CacheAndWriteOutputStream.java:71)
> at
> org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:51)
> at
> org.apache.cxf.io.AbstractThresholdOutputStream.write(AbstractThresholdOutputStream.java:69)
> at com.ctc.wstx.io.UTF8Writer.write(UTF8Writer.java:143)
> at com.ctc.wstx.sw.BufferingXmlWriter.writeRaw(BufferingXmlWriter.java:269)
> at
> com.ctc.wstx.sw.BufferingXmlWriter.writeCharacters(BufferingXmlWriter.java:568)
> at
> com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java:460)
> ... 199 more
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CXF-7653) Null pointer in JaxwsResponseCallback
[
https://issues.apache.org/jira/browse/CXF-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-7653.
--
Resolution: Fixed
Assignee: Daniel Kulp
> Null pointer in JaxwsResponseCallback
> -
>
> Key: CXF-7653
> URL: https://issues.apache.org/jira/browse/CXF-7653
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.10
> Environment: AIX
>Reporter: Neal Johnson
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: 3.1.15, 3.2.3
>
>
> Occasionally we'll get a null pointer in the JAXWS code.
> Caused by: java.lang.NullPointerException
> at
> org.apache.cxf.jaxws.JaxwsResponseCallback.get(JaxwsResponseCallback.java:49)
> When we receive a SOAP message with an empty body (example below) the
> (T)callback.get()[0] line in JaxwsResponseCallback throws a null pointer
> exception. We're still unsure why we're getting a message with an empty body
> in the first place, and if that's AIX related or we're just lucky in other
> operating systems.
> {{http://www.w3.org/2003/05/soap-envelope";>}}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{}}
> We did some debugging and checked where our code diverged between the two
> types of messages. The below chunk of code is where it starts to unravel.
> {code:java|title=Code from within
> DocLiteralInInterceptor.java|borderStyle=solid}
> MessageContentsList parameters = new MessageContentsList();
> Exchange exchange = message.getExchange();
> BindingOperationInfo bop = exchange.getBindingOperationInfo();
> boolean client = isRequestor(message);
> //if body is empty and we have BindingOperationInfo, we do not need to match
> //operation anymore, just return
> if (bop != null && !StaxUtils.toNextElement(xmlReader)) {
> // body may be empty for partial response to decoupled request
> return;
> }
> ...
> // Lots of logic
> ...
> message.setContent(List.class, parameters);
> {code}
> ~~~
> When we do a StaxUtils.toNextElement that returns false, as it hits the end
> of the body immediately. This causes it to return without setting the
> MessageContentsList as a list on the message. Later, when the code tries to
> do a .getContent(List) it doesn't find anything, and this leads to it setting
> null as the first element returned on callback.get()[0].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CXF-7522) WSRM - Exponential backoff not configurable for Redelivery
[ https://issues.apache.org/jira/browse/CXF-7522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-7522. -- Resolution: Fixed Assignee: Daniel Kulp Fix Version/s: 3.2.3 3.1.15 > WSRM - Exponential backoff not configurable for Redelivery > -- > > Key: CXF-7522 > URL: https://issues.apache.org/jira/browse/CXF-7522 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.1.12 >Reporter: Gergan Dimitrov >Assignee: Daniel Kulp >Priority: Critical > Fix For: 3.1.15, 3.2.3 > > > For RedeliverCandidate, the exponential backoff is not configurable - the > hardcoded default value 2 is always used. Please make this value configurable. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-7508) WSRM - CloseSequenceResponse does not have acknowledgments
[
https://issues.apache.org/jira/browse/CXF-7508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-7508.
--
Resolution: Fixed
Assignee: Daniel Kulp
Fix Version/s: 3.2.3
3.1.15
> WSRM - CloseSequenceResponse does not have acknowledgments
> --
>
> Key: CXF-7508
> URL: https://issues.apache.org/jira/browse/CXF-7508
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 3.1.12
>Reporter: Gergan Dimitrov
>Assignee: Daniel Kulp
>Priority: Blocker
> Fix For: 3.1.15, 3.2.3
>
>
> In the RMOutInterceptor, the addAcknowledgements() method is called, only if
> it is for application message, or explictly required sequence acknowledgment:
> boolean isAck = constants.getSequenceAckAction().equals(action);
> if (isApplicationMessage || isAck) {
> Bu the WSRM specification says that the destination MUST return
> acknowledgment for the received messages, when CloseSequence is received:
> Upon receipt of this message (CloseSequence), or subsequent to the RM
> Destination closing the Sequence of its own volition, the RM Destination MUST
> include a final SequenceAcknowledgement (within which the RM Destination MUST
> include the Final element) header block on any messages associated with the
> Sequence destined to the RM Source, including the CloseSequenceResponse
> message or on any Sequence fault Transmitted to the RM Source.
> CXF does not include final ack neither in CloseSequenceResponse, nor in
> TerminateSequenceResponse (which might not be sent, if client does not
> terminate). Therefore, the ack should be sent immediately to the
> CloseSequenceResponse.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CXF-7471) WSRM - Use createResendCandidate() instead of constructor directly
[ https://issues.apache.org/jira/browse/CXF-7471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-7471. -- Resolution: Fixed Assignee: Daniel Kulp Fix Version/s: 3.2.3 3.1.15 > WSRM - Use createResendCandidate() instead of constructor directly > -- > > Key: CXF-7471 > URL: https://issues.apache.org/jira/browse/CXF-7471 > Project: CXF > Issue Type: Improvement > Components: WS-* Components >Affects Versions: 3.1.12 >Reporter: Gergan Dimitrov >Assignee: Daniel Kulp >Priority: Minor > Fix For: 3.1.15, 3.2.3 > > Original Estimate: 1h > Remaining Estimate: 1h > > In the RetransmissionQueueImpl, cacheUnacknowledged() method, line 350, the > resend candidate is created with constructor directly: > candidate = new ResendCandidate(message); > I see there is a method createResendCandidate, which can be extended, but its > used only for tests. As I need custom logic in the resend candidate, but I > want to reuse the rest of the functionality, it would be good if this method > is used instead of the constructor directly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-7048) Response does not include SequenceAcknowledgement
[ https://issues.apache.org/jira/browse/CXF-7048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-7048. -- Resolution: Fixed Assignee: Daniel Kulp Fix Version/s: 3.2.3 3.1.15 > Response does not include SequenceAcknowledgement > - > > Key: CXF-7048 > URL: https://issues.apache.org/jira/browse/CXF-7048 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.1.7 > Environment: JBoss EAP 6, Windows 7, Java 7, Visual Studio 12, CXF > 3.1.7 >Reporter: Andy Zhang >Assignee: Daniel Kulp >Priority: Blocker > Fix For: 3.1.15, 3.2.3 > > > I have a CXF web service, deployed to JBoss, and a dot net client. The > deliveryAssurance is AtMostOnce. > When the service is fast and the response includes SequenceAcknowledgement. > But when the service is slow the client usually sends retransmissions. The > response corresponding to the retransmission only includes the > SequenceAcknowledgement. When the request is successfully processed the > response is sent back to client without SequenceAcknowledgement. But the > client expects it always in the response. If the client does not find > SequenceAcknowledgement it returns a fault to the server saying "A reply > message was received with no acknowledgement." The client will keep waiting > till it times out. > Similarly the response of CloseSequence and TerminateSequence do not have > expected SequenceAcknowledgement either. > Could you please always include the SequenceAcknowledgement in the responses > if applicable? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-7470) WSRM - Cannot set target for recovered source sequence
[ https://issues.apache.org/jira/browse/CXF-7470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-7470. -- Resolution: Fixed Assignee: Daniel Kulp Fix Version/s: 3.2.2 > WSRM - Cannot set target for recovered source sequence > -- > > Key: CXF-7470 > URL: https://issues.apache.org/jira/browse/CXF-7470 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.1.12 >Reporter: Gergan Dimitrov >Assignee: Daniel Kulp >Priority: Critical > Fix For: 3.2.2 > > Original Estimate: 1h > Remaining Estimate: 1h > > When source sequence is recovered during client creation, we cannot set the > target property, as its setter method is package private. If we have sequence > with only one message, and we get acknowledgment for the last message, in the > SourceSequence.setAcknowledged(...) method, there is a check on line 167: > if (null == target) > As the target is null, the api does not automatically send close and > terminate sequence messages. > So several options here: > 1) Make the setTarget method public, or at least protected > 2) Allow setting the property from constructor > 3) Set the property from current endpoint's URL, during recovery. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7653) Null pointer in JaxwsResponseCallback
[
https://issues.apache.org/jira/browse/CXF-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373890#comment-16373890
]
Daniel Kulp commented on CXF-7653:
--
If the WSDL for the operation states that the body should have content, than an
exception should be thrown. Probably some sort of validation exception or
IllegalArguementException or something. An NPE is probably not ideal, or if
it is an NPE, at least put a better description in the message.
> Null pointer in JaxwsResponseCallback
> -
>
> Key: CXF-7653
> URL: https://issues.apache.org/jira/browse/CXF-7653
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.10
> Environment: AIX
>Reporter: Neal Johnson
>Priority: Major
>
> Occasionally we'll get a null pointer in the JAXWS code.
> Caused by: java.lang.NullPointerException
> at
> org.apache.cxf.jaxws.JaxwsResponseCallback.get(JaxwsResponseCallback.java:49)
> When we receive a SOAP message with an empty body (example below) the
> (T)callback.get()[0] line in JaxwsResponseCallback throws a null pointer
> exception. We're still unsure why we're getting a message with an empty body
> in the first place, and if that's AIX related or we're just lucky in other
> operating systems.
> {{http://www.w3.org/2003/05/soap-envelope";>}}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{}}
> We did some debugging and checked where our code diverged between the two
> types of messages. The below chunk of code is where it starts to unravel.
> {code:java|title=Code from within
> DocLiteralInInterceptor.java|borderStyle=solid}
> MessageContentsList parameters = new MessageContentsList();
> Exchange exchange = message.getExchange();
> BindingOperationInfo bop = exchange.getBindingOperationInfo();
> boolean client = isRequestor(message);
> //if body is empty and we have BindingOperationInfo, we do not need to match
> //operation anymore, just return
> if (bop != null && !StaxUtils.toNextElement(xmlReader)) {
> // body may be empty for partial response to decoupled request
> return;
> }
> ...
> // Lots of logic
> ...
> message.setContent(List.class, parameters);
> {code}
> ~~~
> When we do a StaxUtils.toNextElement that returns false, as it hits the end
> of the body immediately. This causes it to return without setting the
> MessageContentsList as a list on the message. Later, when the code tries to
> do a .getContent(List) it doesn't find anything, and this leads to it setting
> null as the first element returned on callback.get()[0].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7653) Null pointer in JaxwsResponseCallback
[
https://issues.apache.org/jira/browse/CXF-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16371927#comment-16371927
]
Daniel Kulp commented on CXF-7653:
--
Is a soap message with an empty body valid at this point? If not, then an
exception should be raised. Whether that should be an NPE or other is a good
question, but an exception is the correct behavior.
> Null pointer in JaxwsResponseCallback
> -
>
> Key: CXF-7653
> URL: https://issues.apache.org/jira/browse/CXF-7653
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.10
> Environment: AIX
>Reporter: Neal Johnson
>Priority: Major
>
> Occasionally we'll get a null pointer in the JAXWS code.
> Caused by: java.lang.NullPointerException
> at
> org.apache.cxf.jaxws.JaxwsResponseCallback.get(JaxwsResponseCallback.java:49)
> When we receive a SOAP message with an empty body (example below) the
> (T)callback.get()[0] line in JaxwsResponseCallback throws a null pointer
> exception. We're still unsure why we're getting a message with an empty body
> in the first place, and if that's AIX related or we're just lucky in other
> operating systems.
> {{http://www.w3.org/2003/05/soap-envelope";>}}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{}}
> We did some debugging and checked where our code diverged between the two
> types of messages. The below chunk of code is where it starts to unravel.
> {code:java|title=Code from within
> DocLiteralInInterceptor.java|borderStyle=solid}
> MessageContentsList parameters = new MessageContentsList();
> Exchange exchange = message.getExchange();
> BindingOperationInfo bop = exchange.getBindingOperationInfo();
> boolean client = isRequestor(message);
> //if body is empty and we have BindingOperationInfo, we do not need to match
> //operation anymore, just return
> if (bop != null && !StaxUtils.toNextElement(xmlReader)) {
> // body may be empty for partial response to decoupled request
> return;
> }
> ...
> // Lots of logic
> ...
> message.setContent(List.class, parameters);
> {code}
> ~~~
> When we do a StaxUtils.toNextElement that returns false, as it hits the end
> of the body immediately. This causes it to return without setting the
> MessageContentsList as a list on the message. Later, when the code tries to
> do a .getContent(List) it doesn't find anything, and this leads to it setting
> null as the first element returned on callback.get()[0].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7641) BareOutInterceptor seems to be taking lot of time
[ https://issues.apache.org/jira/browse/CXF-7641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16361210#comment-16361210 ] Daniel Kulp commented on CXF-7641: -- Long times spent in that interceptor are normally caused by slow network IO and/or slow processing on the other side of the connection.Basically, in that interceptor is where the data is being written out to the OutputStream. If the server is busy and cannot process the request or the network connection is slow, that would appear as time spent in the BareOutInterceptor. > BareOutInterceptor seems to be taking lot of time > -- > > Key: CXF-7641 > URL: https://issues.apache.org/jira/browse/CXF-7641 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 2.7.6 >Reporter: ANURAG SHRIVASTAVA >Priority: Major > > Team, > > we are using Apache CXF 2.7.6 and we are seeing when SOAP Payload is big then > BareOutInterceptor is taking almost 5 seconds. > > Line 71870: *09:56:33.131* [http-bio-8110-exec-1] DEBUG > o.a.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on interceptor > org.apache.cxf.interceptor.*BareOutInterceptor*@658b9781 > Line 71873: *09:56:38.532* [http-bio-8110-exec-1] DEBUG > o.a.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on interceptor > org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor$SoapOutEndingInterceptor@9dde9a4 > Line 71874: 09:56:38.532 [http-bio-8110-exec-1] DEBUG > o.a.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on interceptor > org.apache.cxf.interceptor.AttachmentOutInterceptor$AttachmentOutEndingInterceptor@73543007 > Line 71875: 09:56:39.954 [http-bio-8110-exec-1] DEBUG > o.a.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on interceptor > org.apache.cxf.interceptor.StaxOutEndingInterceptor@43b91daa > Line 71876: 09:56:39.954 [http-bio-8110-exec-1] DEBUG > o.a.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on interceptor > org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor@3ac8c8db > > > > Please suggest can which scenario it can take this much of time > > Anurag -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7621) Facing issue while upgrading to Java 8 and Webspehre 8.5.5.11
[ https://issues.apache.org/jira/browse/CXF-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16352767#comment-16352767 ] Daniel Kulp commented on CXF-7621: -- And if that doesn't work... create a FULL maven project with wsdl and such that can reproduce it. Looking at stack traces in this case is almost pointless. > Facing issue while upgrading to Java 8 and Webspehre 8.5.5.11 > - > > Key: CXF-7621 > URL: https://issues.apache.org/jira/browse/CXF-7621 > Project: CXF > Issue Type: Bug >Reporter: Kirti >Priority: Major > Fix For: NeedMoreInfo > > Attachments: VioWSWeb_build.xml, pom.xml > > > Hi, > *I am working on upgrading java from 6 to 8 and WebSphere from 8.5.5.3 to > 8.5.5.11 . Facing below issue while hitting web services wsdl.* > *Currently we are using spring 2.5 and apache cxf 2.3.9. Please suggest.* > *2018-01-22 13:40:16,046 [server.startup : 2] ERROR > org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:331) > - Context initializat* > *ion failed* > *org.springframework.beans.factory.BeanCreationException: Error creating > bean with name 'BOSService': Invocation of init method failed; nested > exception is javax.xml.ws.* > *WebServiceException: > org.apache.cxf.service.factory.ServiceConstructionException* > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1572) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:539) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:476) > at > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:303) > at > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230) > at > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:299) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194) > at > org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:755) > at > org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:762) > at > org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:480) > at > org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:434) > at > org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:306) > at > org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:106) > at > com.vesystems.ws.services.impl.CustomContextLoaderListener.contextInitialized(Unknown > Source) > at > com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1732) > at com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:415) > at > com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:88) > at > com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication(VirtualHostImpl.java:171) > at com.ibm.ws.webcontainer.WSWebContainer.addWebApp(WSWebContainer.java:904) > at > com.ibm.ws.webcontainer.WSWebContainer.addWebApplication(WSWebContainer.java:789) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7621) Facing issue while upgrading to Java 8 and Webspehre 8.5.5.11
[ https://issues.apache.org/jira/browse/CXF-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16352761#comment-16352761 ] Daniel Kulp commented on CXF-7621: -- Change the "fork" flag to once instead of always. I think there is a bug in the docs as "always" isn't a recognized value. It's true/false/once > Facing issue while upgrading to Java 8 and Webspehre 8.5.5.11 > - > > Key: CXF-7621 > URL: https://issues.apache.org/jira/browse/CXF-7621 > Project: CXF > Issue Type: Bug >Reporter: Kirti >Priority: Major > Fix For: NeedMoreInfo > > Attachments: VioWSWeb_build.xml, pom.xml > > > Hi, > *I am working on upgrading java from 6 to 8 and WebSphere from 8.5.5.3 to > 8.5.5.11 . Facing below issue while hitting web services wsdl.* > *Currently we are using spring 2.5 and apache cxf 2.3.9. Please suggest.* > *2018-01-22 13:40:16,046 [server.startup : 2] ERROR > org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:331) > - Context initializat* > *ion failed* > *org.springframework.beans.factory.BeanCreationException: Error creating > bean with name 'BOSService': Invocation of init method failed; nested > exception is javax.xml.ws.* > *WebServiceException: > org.apache.cxf.service.factory.ServiceConstructionException* > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1572) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:539) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:476) > at > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:303) > at > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230) > at > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:299) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194) > at > org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:755) > at > org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:762) > at > org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:480) > at > org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:434) > at > org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:306) > at > org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:106) > at > com.vesystems.ws.services.impl.CustomContextLoaderListener.contextInitialized(Unknown > Source) > at > com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1732) > at com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:415) > at > com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:88) > at > com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication(VirtualHostImpl.java:171) > at com.ibm.ws.webcontainer.WSWebContainer.addWebApp(WSWebContainer.java:904) > at > com.ibm.ws.webcontainer.WSWebContainer.addWebApplication(WSWebContainer.java:789) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
