[jira] [Resolved] (CXF-8117) Make dependencies optional
[ https://issues.apache.org/jira/browse/CXF-8117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-8117. --- Resolution: Information Provided > Make dependencies optional > -- > > Key: CXF-8117 > URL: https://issues.apache.org/jira/browse/CXF-8117 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 3.3.3 >Reporter: David J. M. Karlsen >Assignee: Freeman Fang >Priority: Trivial > > cxf-core has dependencies to: > +- org.jacorb:jacorb-omgapi:jar:3.7:compile > [INFO] | | +- > org.apache.geronimo.specs:geronimo-jta_1.1_spec:jar:1.1.1:compile > [INFO] | | \- > org.jboss.spec.javax.rmi:jboss-rmi-api_1.0_spec:jar:1.0.6.Final:compile > can these be made optional? I don't think they are needed in most cases. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CXF-8118) CXF LoggingInInterceptor: CachedWriter leaks
[ https://issues.apache.org/jira/browse/CXF-8118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-8118. --- Fix Version/s: 3.3.4 3.2.11 3.4.0 Resolution: Fixed > CXF LoggingInInterceptor: CachedWriter leaks > > > Key: CXF-8118 > URL: https://issues.apache.org/jira/browse/CXF-8118 > Project: CXF > Issue Type: Bug >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > Fix For: 3.4.0, 3.2.11, 3.3.4 > > > when Reader is dectected in Message, will create CachedWriter for logging, > but never close this CachedWriter. Which will cause there's always a > reference in CachedWriter.streamList(never empty), so can't delete the tmp > file on the disk -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CXF-8118) CXF LoggingInInterceptor: CachedWriter leaks
[ https://issues.apache.org/jira/browse/CXF-8118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned CXF-8118: - Assignee: Freeman Fang > CXF LoggingInInterceptor: CachedWriter leaks > > > Key: CXF-8118 > URL: https://issues.apache.org/jira/browse/CXF-8118 > Project: CXF > Issue Type: Bug >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > > when Reader is dectected in Message, will create CachedWriter for logging, > but never close this CachedWriter. Which will cause there's always a > reference in CachedWriter.streamList(never empty), so can't delete the tmp > file on the disk -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CXF-8117) Make dependencies optional
[ https://issues.apache.org/jira/browse/CXF-8117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16931676#comment-16931676 ] Freeman Fang commented on CXF-8117: --- The main idea here isn't necessary or not for most users, it's about to keep same behaviour as previous jdk even using jdk11. > Make dependencies optional > -- > > Key: CXF-8117 > URL: https://issues.apache.org/jira/browse/CXF-8117 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 3.3.3 >Reporter: David J. M. Karlsen >Assignee: Freeman Fang >Priority: Trivial > > cxf-core has dependencies to: > +- org.jacorb:jacorb-omgapi:jar:3.7:compile > [INFO] | | +- > org.apache.geronimo.specs:geronimo-jta_1.1_spec:jar:1.1.1:compile > [INFO] | | \- > org.jboss.spec.javax.rmi:jboss-rmi-api_1.0_spec:jar:1.0.6.Final:compile > can these be made optional? I don't think they are needed in most cases. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CXF-8117) Make dependencies optional
[ https://issues.apache.org/jira/browse/CXF-8117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16931511#comment-16931511 ] Freeman Fang commented on CXF-8117: --- So far I don't think we should mark this as optional. You can only see it as dependency when using jdk11. In previous JDK the corba api is available in JDK by default, and in JDK11 we want to simulate same behavior as before, so users don't need to explicitly add corba api(or any other JEE api removed from JDK11) by themselves as long as they have CXF dependencies. Best Regards Freeman > Make dependencies optional > -- > > Key: CXF-8117 > URL: https://issues.apache.org/jira/browse/CXF-8117 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 3.3.3 >Reporter: David J. M. Karlsen >Assignee: Freeman Fang >Priority: Trivial > > cxf-core has dependencies to: > +- org.jacorb:jacorb-omgapi:jar:3.7:compile > [INFO] | | +- > org.apache.geronimo.specs:geronimo-jta_1.1_spec:jar:1.1.1:compile > [INFO] | | \- > org.jboss.spec.javax.rmi:jboss-rmi-api_1.0_spec:jar:1.0.6.Final:compile > can these be made optional? I don't think they are needed in most cases. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (CXF-8117) Make dependencies optional
[ https://issues.apache.org/jira/browse/CXF-8117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned CXF-8117: - Assignee: Freeman Fang > Make dependencies optional > -- > > Key: CXF-8117 > URL: https://issues.apache.org/jira/browse/CXF-8117 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 3.3.3 >Reporter: David J. M. Karlsen >Assignee: Freeman Fang >Priority: Trivial > > cxf-core has dependencies to: > +- org.jacorb:jacorb-omgapi:jar:3.7:compile > [INFO] | | +- > org.apache.geronimo.specs:geronimo-jta_1.1_spec:jar:1.1.1:compile > [INFO] | | \- > org.jboss.spec.javax.rmi:jboss-rmi-api_1.0_spec:jar:1.0.6.Final:compile > can these be made optional? I don't think they are needed in most cases. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CXF-8112) Default WebApplicationExceptionMapper is preferred over custom one but Documentation states opposite
[
https://issues.apache.org/jira/browse/CXF-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929512#comment-16929512
]
Freeman Fang commented on CXF-8112:
---
[~dan...@peger.de], thanks, revised accordingly.
> Default WebApplicationExceptionMapper is preferred over custom one but
> Documentation states opposite
>
>
> Key: CXF-8112
> URL: https://issues.apache.org/jira/browse/CXF-8112
> Project: CXF
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 3.3.3
>Reporter: Daniel H. Peger
>Assignee: Freeman Fang
>Priority: Major
>
> The documentation on customizing the exception mapping in JAX-RS mentions
> that custom mappers will be preferred over the default
> {{WebApplicationExceptionMapper}}:
> {quote}Note that the custom WebApplicationException mapper, if registered,
> will be preferred to the default one.{quote}
> See
> https://cxf.apache.org/docs/jax-rs-basics.html#JAX-RSBasics-CustomizingdefaultWebApplicationExceptionmapper
> Lately I noticed that after upgrading CXF this is not true anymore for
> exception mappers that handle all kind of exceptions like
> {{ExceptionMapper}}.
> In CXF-6568 it is mentioned that a new property (actual property name seems
> to be {{default.wae.mapper.least.specific}}) was introduced to restore the
> previous behavior. I think this property should be mentioned on the JAX-RS
> basics page, as I didn't find any other resource pointing to this possibility.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Assigned] (CXF-8096) Adding LoggingFeature causes blocking read
[
https://issues.apache.org/jira/browse/CXF-8096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang reassigned CXF-8096:
-
Assignee: Freeman Fang
> Adding LoggingFeature causes blocking read
> --
>
> Key: CXF-8096
> URL: https://issues.apache.org/jira/browse/CXF-8096
> Project: CXF
> Issue Type: Bug
> Components: logging
>Affects Versions: 3.3.3
>Reporter: Krisztian Kurucz
>Assignee: Freeman Fang
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Adding org.apache.cxf.feature.LoggingFeature to WebClient feature affects the
> reading of the response is blocked until the stream will be closed.
> Without LoggingFeature the response's input stream can be get immediately for
> further processing.
> error-prone line in WireTapIn::handleInputStream(Message,
> InputStream)::Line92:
>
> {code:java}
> IOUtils.copyAtLeast(bis, bos, limit == -1 ? Integer.MAX_VALUE : limit);{code}
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (CXF-8096) Adding LoggingFeature causes blocking read
[
https://issues.apache.org/jira/browse/CXF-8096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang resolved CXF-8096.
---
Resolution: Information Provided
> Adding LoggingFeature causes blocking read
> --
>
> Key: CXF-8096
> URL: https://issues.apache.org/jira/browse/CXF-8096
> Project: CXF
> Issue Type: Bug
> Components: logging
>Affects Versions: 3.3.3
>Reporter: Krisztian Kurucz
>Assignee: Freeman Fang
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Adding org.apache.cxf.feature.LoggingFeature to WebClient feature affects the
> reading of the response is blocked until the stream will be closed.
> Without LoggingFeature the response's input stream can be get immediately for
> further processing.
> error-prone line in WireTapIn::handleInputStream(Message,
> InputStream)::Line92:
>
> {code:java}
> IOUtils.copyAtLeast(bis, bos, limit == -1 ? Integer.MAX_VALUE : limit);{code}
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Issue Comment Deleted] (CXF-6568) Default WebApplicationExceptionMapper should be optionally made less specific
[ https://issues.apache.org/jira/browse/CXF-6568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang updated CXF-6568: -- Comment: was deleted (was: Thanks for reporting this issue Document updated, should be published in a couple of hours) > Default WebApplicationExceptionMapper should be optionally made less specific > - > > Key: CXF-6568 > URL: https://issues.apache.org/jira/browse/CXF-6568 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin >Priority: Minor > Fix For: 3.1.3, 3.0.7 > > > Now that the default and custom providers are kept in a single > ProviderFactory with a parent-child relationship the default > WebApplicationExceptionMapper will win over custom providers which are less > specific (ex, RuntimeException mappers) but which expect to catch > WebApplicationException. > It is been confirmed on the spec experts list that it is expected that custom > mappers can catch WAE thrown by the runtime itself therefore the fact that > CXF uses WAE to enforce spec-related error conditions is sound. > There's no clarity though how the runtime is expected to manages such > runtime-originated WAEs - via its own WAE mapper or even RuntimeException > mapper or somehow else. > Therefore a property "make.default.wae.least.specific" is introduced to > ensure a CXF default WAE mapper is only used if no other custom mapper can > handle a given WAE to minimize any portability concerns. > This can be further addressed once we get more clarity on the issue -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CXF-8112) Default WebApplicationExceptionMapper is preferred over custom one but Documentation states opposite
[
https://issues.apache.org/jira/browse/CXF-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929288#comment-16929288
]
Freeman Fang commented on CXF-8112:
---
Thanks for reporting this issue
Document updated, should be published in a couple of hours
> Default WebApplicationExceptionMapper is preferred over custom one but
> Documentation states opposite
>
>
> Key: CXF-8112
> URL: https://issues.apache.org/jira/browse/CXF-8112
> Project: CXF
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 3.3.3
>Reporter: Daniel H. Peger
>Assignee: Freeman Fang
>Priority: Major
>
> The documentation on customizing the exception mapping in JAX-RS mentions
> that custom mappers will be preferred over the default
> {{WebApplicationExceptionMapper}}:
> {quote}Note that the custom WebApplicationException mapper, if registered,
> will be preferred to the default one.{quote}
> See
> https://cxf.apache.org/docs/jax-rs-basics.html#JAX-RSBasics-CustomizingdefaultWebApplicationExceptionmapper
> Lately I noticed that after upgrading CXF this is not true anymore for
> exception mappers that handle all kind of exceptions like
> {{ExceptionMapper}}.
> In CXF-6568 it is mentioned that a new property (actual property name seems
> to be {{default.wae.mapper.least.specific}}) was introduced to restore the
> previous behavior. I think this property should be mentioned on the JAX-RS
> basics page, as I didn't find any other resource pointing to this possibility.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CXF-6568) Default WebApplicationExceptionMapper should be optionally made less specific
[ https://issues.apache.org/jira/browse/CXF-6568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929286#comment-16929286 ] Freeman Fang commented on CXF-6568: --- Thanks for reporting this issue Document updated, should be published in a couple of hours > Default WebApplicationExceptionMapper should be optionally made less specific > - > > Key: CXF-6568 > URL: https://issues.apache.org/jira/browse/CXF-6568 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin >Priority: Minor > Fix For: 3.1.3, 3.0.7 > > > Now that the default and custom providers are kept in a single > ProviderFactory with a parent-child relationship the default > WebApplicationExceptionMapper will win over custom providers which are less > specific (ex, RuntimeException mappers) but which expect to catch > WebApplicationException. > It is been confirmed on the spec experts list that it is expected that custom > mappers can catch WAE thrown by the runtime itself therefore the fact that > CXF uses WAE to enforce spec-related error conditions is sound. > There's no clarity though how the runtime is expected to manages such > runtime-originated WAEs - via its own WAE mapper or even RuntimeException > mapper or somehow else. > Therefore a property "make.default.wae.least.specific" is introduced to > ensure a CXF default WAE mapper is only used if no other custom mapper can > handle a given WAE to minimize any portability concerns. > This can be further addressed once we get more clarity on the issue -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (CXF-8112) Default WebApplicationExceptionMapper is preferred over custom one but Documentation states opposite
[
https://issues.apache.org/jira/browse/CXF-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang resolved CXF-8112.
---
Resolution: Fixed
> Default WebApplicationExceptionMapper is preferred over custom one but
> Documentation states opposite
>
>
> Key: CXF-8112
> URL: https://issues.apache.org/jira/browse/CXF-8112
> Project: CXF
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 3.3.3
>Reporter: Daniel H. Peger
>Assignee: Freeman Fang
>Priority: Major
>
> The documentation on customizing the exception mapping in JAX-RS mentions
> that custom mappers will be preferred over the default
> {{WebApplicationExceptionMapper}}:
> {quote}Note that the custom WebApplicationException mapper, if registered,
> will be preferred to the default one.{quote}
> See
> https://cxf.apache.org/docs/jax-rs-basics.html#JAX-RSBasics-CustomizingdefaultWebApplicationExceptionmapper
> Lately I noticed that after upgrading CXF this is not true anymore for
> exception mappers that handle all kind of exceptions like
> {{ExceptionMapper}}.
> In CXF-6568 it is mentioned that a new property (actual property name seems
> to be {{default.wae.mapper.least.specific}}) was introduced to restore the
> previous behavior. I think this property should be mentioned on the JAX-RS
> basics page, as I didn't find any other resource pointing to this possibility.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CXF-8113) SocketTimeoutException when remote server closes connection after payload has been delivered
[
https://issues.apache.org/jira/browse/CXF-8113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16928041#comment-16928041
]
Freeman Fang commented on CXF-8113:
---
Yes, first glance it's a regression from httpcore-nio side, using latest CXF
3.3.3 and httpcore-nio 4.4.9, your test can pass.
> SocketTimeoutException when remote server closes connection after payload has
> been delivered
>
>
> Key: CXF-8113
> URL: https://issues.apache.org/jira/browse/CXF-8113
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.3.1
>Reporter: Brian B
>Priority: Major
> Attachments: asyncbugtest.zip
>
>
> Similar to CXF-7831, when using the Asynchronous Client HTTP Transport to
> handle soap web services, we get a SocketTimeout exception when a remote
> server closes the connection after the payload has been delivered.
> From my research, I'm honestly not sure if this is a CXF issue or an
> {{httpcore-nio}} issue. The fix in CXF-7831 to CXF's {{SharedInputBuffer}},
> and the fact that I do not directly consume httpcore-nio led me here first.
> The problem occurs when the client receives a TLS {{close_notify}} _after_
> the payload has been received. The payload must be larger than the allocated
> byte buffer receiving the decrypted payload (~16K in the default case). This
> results in decrypted data being available in the {{httpcore-nio}} library,
> but not immediately consumed.
> When these conditions are met, the following section of code is invoked:
>
> {{org.apache.cxf.transport.http.asyncclient.SharedInputBuffer#_consumeContent_:{color:#0747a6}111{color}}}:
> {code:java}
> if (!this.buffer.hasRemaining() && this.ioctrl != null && !this.endOfStream) {
> this.ioctrl.suspendInput();
> }
> {code}
> The suspension of input when combined with the connection close and the
> following change introduced in {{httpcore-nio}} 4.4.10 (and it's revised
> 4.4.11 version here) truly removes the {{READ}} {{EventMask}} from the
> underlying {{IOSessionImpl}}:
>
> {{org.apache.http.nio.reactor.ssl.SSLIOSession#_updateEventMask_:{color:#0747a6}402{color}}}
> {code:java}
> if (this.endOfStream && (this.appBufferStatus == null ||
> !this.appBufferStatus.hasBufferedInput())) {
> newMask = newMask & ~EventMask.READ;
> }
> {code}
> Once this happens, requests for input by
> {{SharedInputBuffer#_waitForData(int)_}} enter the {{_updateEventMask_}}
> method as expected, but the new {{httpcore-nio}} code above prevents the read
> operation from being reenabled despite the remainder of the decrypted payload
> being available in the {{SSLIOSession}} {{inPlain}} buffer. The call
> ultimately fails with a {{SocketTimeoutException}}.
> I created a unit test to demonstrate the failure and attached it to the JIRA.
> Given the complexity of the code and multiple buffers at play, I have not
> been able to come up with a fix beyond modifying the {{SSLIOSession}} code
> above to account for the buffered decrypted content - but I'm assuming that
> change was added for a reason and did not investigate the side effects of the
> modification. Please let me know if there's anything else you need from me.
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Assigned] (CXF-8112) Default WebApplicationExceptionMapper is preferred over custom one but Documentation states opposite
[
https://issues.apache.org/jira/browse/CXF-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang reassigned CXF-8112:
-
Assignee: Freeman Fang
> Default WebApplicationExceptionMapper is preferred over custom one but
> Documentation states opposite
>
>
> Key: CXF-8112
> URL: https://issues.apache.org/jira/browse/CXF-8112
> Project: CXF
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 3.3.3
>Reporter: Daniel H. Peger
>Assignee: Freeman Fang
>Priority: Major
>
> The documentation on customizing the exception mapping in JAX-RS mentions
> that custom mappers will be preferred over the default
> {{WebApplicationExceptionMapper}}:
> {quote}Note that the custom WebApplicationException mapper, if registered,
> will be preferred to the default one.{quote}
> See
> https://cxf.apache.org/docs/jax-rs-basics.html#JAX-RSBasics-CustomizingdefaultWebApplicationExceptionmapper
> Lately I noticed that after upgrading CXF this is not true anymore for
> exception mappers that handle all kind of exceptions like
> {{ExceptionMapper}}.
> In CXF-6568 it is mentioned that a new property (actual property name seems
> to be {{default.wae.mapper.least.specific}}) was introduced to restore the
> previous behavior. I think this property should be mentioned on the JAX-RS
> basics page, as I didn't find any other resource pointing to this possibility.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (CXF-8096) Adding LoggingFeature causes blocking read
[
https://issues.apache.org/jira/browse/CXF-8096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927108#comment-16927108
]
Freeman Fang edited comment on CXF-8096 at 9/10/19 11:17 PM:
-
Hi [~kkurucz],
I took a close look at the problem you described, IMO this is kind of by design.
About this method in your concern
{code}
IOUtils.copyAtLeast(bis, bos, limit == -1 ? Integer.MAX_VALUE : limit);
{code}
It's actually not "blocked until the stream will be closed." This method will
do
{code}
/**
* Copy at least the specified number of bytes from the input to the output
* or until the inputstream is finished.
* @param input
* @param output
* @param atLeast
* @throws IOException
*/
{code}
And by default When you enable logging feature, the "specified number of bytes"
is 48k, it's what will be printed out as log for the incoming message. Since
most message(at least in your testcase)'s size less than 48k, so it seems
"blocked until the stream will be closed." but this isn't true, it still use
streaming way to read rest of the inputstream if it's size > 48K and copy
inputstream to CachedOutStream which enable to re-read the stream so that we
can print out the log do need extra time to process.
Enable logging feature will give you more information, but it will add another
layer of process on the Incoming message steam, so it has detrimental impact on
performance, but this is by design and it's kind of trade-off.
Best Regards
Freeman
was (Author: ffang):
Hi [~kkurucz],
I took a close look at the problem you described, IMO this is kind of by design.
About this method in your concern
{code}
IOUtils.copyAtLeast(bis, bos, limit == -1 ? Integer.MAX_VALUE : limit);
{code}
It's actually not "blocked until the stream will be closed." This method will
do
{code}
/**
* Copy at least the specified number of bytes from the input to the output
* or until the inputstream is finished.
* @param input
* @param output
* @param atLeast
* @throws IOException
*/
{code}
And by default When you enable logging feature, the "specified number of bytes"
is 48k, it's what will be printed out as log for the incoming message. Since
most message(at least in your testcase)'s size less than 48k, so it seems
"blocked until the stream will be closed." but this isn't true, it still use
streaming way to read rest of the inputstream if it's size > 48K and copy
stream to cachedOut which enable to re-read it to print the log do need extra
time to process. Enable logging feature will give you more information, but it
will add another layer of process on the Incoming message steam, so it has
detrimental impact on performance, but this is by design and it's kind of
trade-off.
Best Regards
Freeman
> Adding LoggingFeature causes blocking read
> --
>
> Key: CXF-8096
> URL: https://issues.apache.org/jira/browse/CXF-8096
> Project: CXF
> Issue Type: Bug
> Components: logging
>Affects Versions: 3.3.3
>Reporter: Krisztian Kurucz
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Adding org.apache.cxf.feature.LoggingFeature to WebClient feature affects the
> reading of the response is blocked until the stream will be closed.
> Without LoggingFeature the response's input stream can be get immediately for
> further processing.
> error-prone line in WireTapIn::handleInputStream(Message,
> InputStream)::Line92:
>
> {code:java}
> IOUtils.copyAtLeast(bis, bos, limit == -1 ? Integer.MAX_VALUE : limit);{code}
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CXF-8096) Adding LoggingFeature causes blocking read
[
https://issues.apache.org/jira/browse/CXF-8096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927108#comment-16927108
]
Freeman Fang commented on CXF-8096:
---
Hi [~kkurucz],
I took a close look at the problem you described, IMO this is kind of by design.
About this method in your concern
{code}
IOUtils.copyAtLeast(bis, bos, limit == -1 ? Integer.MAX_VALUE : limit);
{code}
It's actually not "blocked until the stream will be closed." This method will
do
{code}
/**
* Copy at least the specified number of bytes from the input to the output
* or until the inputstream is finished.
* @param input
* @param output
* @param atLeast
* @throws IOException
*/
{code}
And by default When you enable logging feature, the "specified number of bytes"
is 48k, it's what will be printed out as log for the incoming message. Since
most message(at least in your testcase)'s size less than 48k, so it seems
"blocked until the stream will be closed." but this isn't true, it still use
streaming way to read rest of the inputstream if it's size > 48K and copy
stream to cachedOut which enable to re-read it to print the log do need extra
time to process. Enable logging feature will give you more information, but it
will add another layer of process on the Incoming message steam, so it has
detrimental impact on performance, but this is by design and it's kind of
trade-off.
Best Regards
Freeman
> Adding LoggingFeature causes blocking read
> --
>
> Key: CXF-8096
> URL: https://issues.apache.org/jira/browse/CXF-8096
> Project: CXF
> Issue Type: Bug
> Components: logging
>Affects Versions: 3.3.3
>Reporter: Krisztian Kurucz
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Adding org.apache.cxf.feature.LoggingFeature to WebClient feature affects the
> reading of the response is blocked until the stream will be closed.
> Without LoggingFeature the response's input stream can be get immediately for
> further processing.
> error-prone line in WireTapIn::handleInputStream(Message,
> InputStream)::Line92:
>
> {code:java}
> IOUtils.copyAtLeast(bis, bos, limit == -1 ? Integer.MAX_VALUE : limit);{code}
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (CXF-8105) introduce a property for JMS transport client to decide reset JMS connection or not when client timeout
[ https://issues.apache.org/jira/browse/CXF-8105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-8105. --- Fix Version/s: 3.3.4 3.2.11 3.4.0 Resolution: Fixed > introduce a property for JMS transport client to decide reset JMS connection > or not when client timeout > --- > > Key: CXF-8105 > URL: https://issues.apache.org/jira/browse/CXF-8105 > Project: CXF > Issue Type: Improvement >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > Fix For: 3.4.0, 3.2.11, 3.3.4 > > > When using JMS transport, the client can encounter receive timeout from time > to time. This timeout could be caused by the serious problem in broker(like > crash or restart), in which case a JMS connection reset is required. Or the > timeout could be just a request need a longer time to process it on the > server side, in this case a JMS connection reset is a overkill. > We should introduce a property to control this behavior, let end users to > decide which scenario fits their requirement. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CXF-8105) introduce a property for JMS transport client to decide reset JMS connection or not when client timeout
[ https://issues.apache.org/jira/browse/CXF-8105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16922464#comment-16922464 ] Freeman Fang commented on CXF-8105: --- [~coheigea], yes, will do > introduce a property for JMS transport client to decide reset JMS connection > or not when client timeout > --- > > Key: CXF-8105 > URL: https://issues.apache.org/jira/browse/CXF-8105 > Project: CXF > Issue Type: Improvement >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > > When using JMS transport, the client can encounter receive timeout from time > to time. This timeout could be caused by the serious problem in broker(like > crash or restart), in which case a JMS connection reset is required. Or the > timeout could be just a request need a longer time to process it on the > server side, in this case a JMS connection reset is a overkill. > We should introduce a property to control this behavior, let end users to > decide which scenario fits their requirement. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (CXF-8105) introduce a property for JMS transport client to decide reset JMS connection or not when client timeout
[ https://issues.apache.org/jira/browse/CXF-8105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned CXF-8105: - Assignee: Freeman Fang > introduce a property for JMS transport client to decide reset JMS connection > or not when client timeout > --- > > Key: CXF-8105 > URL: https://issues.apache.org/jira/browse/CXF-8105 > Project: CXF > Issue Type: Improvement >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > > When using JMS transport, the client can encounter receive timeout from time > to time. This timeout could be caused by the serious problem in broker(like > crash or restart), in which case a JMS connection reset is required. Or the > timeout could be just a request need a longer time to process it on the > server side, in this case a JMS connection reset is a overkill. > We should introduce a property to control this behavior, let end users to > decide which scenario fits their requirement. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (CXF-8105) introduce a property for JMS transport client to decide reset JMS connection or not when client timeout
Freeman Fang created CXF-8105: - Summary: introduce a property for JMS transport client to decide reset JMS connection or not when client timeout Key: CXF-8105 URL: https://issues.apache.org/jira/browse/CXF-8105 Project: CXF Issue Type: Improvement Reporter: Freeman Fang When using JMS transport, the client can encounter receive timeout from time to time. This timeout could be caused by the serious problem in broker(like crash or restart), in which case a JMS connection reset is required. Or the timeout could be just a request need a longer time to process it on the server side, in this case a JMS connection reset is a overkill. We should introduce a property to control this behavior, let end users to decide which scenario fits their requirement. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CXF-7910) Change JAX-WS javax to jakarta artifact dependencies
[ https://issues.apache.org/jira/browse/CXF-7910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16907698#comment-16907698 ] Freeman Fang commented on CXF-7910: --- Hi Guys, The last time I tried, there's still some issues in OSGi test, which should be saaj 1.5 bundle related. I will revisit when I get chance, and another pair of eyes is definitely welcome! Thanks! Freeman > Change JAX-WS javax to jakarta artifact dependencies > > > Key: CXF-7910 > URL: https://issues.apache.org/jira/browse/CXF-7910 > Project: CXF > Issue Type: Task > Components: JAX-WS Runtime >Reporter: Dennis Kieselhorst >Priority: Minor > Fix For: 3.4.0 > > Time Spent: 10m > Remaining Estimate: 0h > > See https://github.com/eclipse-ee4j/jax-ws-api/issues/46 > According to https://projects.eclipse.org/projects/ee4j.jaxws/ will be > released on 2018-12-14. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (CXF-8090) Warnings when using cxf-codegen-plugin
[ https://issues.apache.org/jira/browse/CXF-8090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-8090. --- Resolution: Fixed Fix Version/s: 3.3.4 > Warnings when using cxf-codegen-plugin > -- > > Key: CXF-8090 > URL: https://issues.apache.org/jira/browse/CXF-8090 > Project: CXF > Issue Type: Bug > Components: Build system >Affects Versions: 3.3.2 >Reporter: Atle Tokle >Assignee: Freeman Fang >Priority: Minor > Fix For: 3.3.4 > > > I get two warnings about deprecated properties when building with > cxf-codegen-plugin. > [WARNING] configuration key 'class.resource.loader.class' has been deprecated > in favor of 'resource.loader.class.class' > [WARNING] configuration key 'resource.loader' has been deprecated in favor > of 'resource.loaders' > > Not very important, but i prefere clean logs, and it should be easy to fix > It does probably come from org.apache.cxf.tools.common.VelocityGenerator -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (CXF-8090) Warnings when using cxf-codegen-plugin
[ https://issues.apache.org/jira/browse/CXF-8090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903992#comment-16903992 ] Freeman Fang commented on CXF-8090: --- This is caused by new properties name introduced since velocity 2.1 https://velocity.apache.org/engine/devel/configuration-property-changes-in-2.1.html > Warnings when using cxf-codegen-plugin > -- > > Key: CXF-8090 > URL: https://issues.apache.org/jira/browse/CXF-8090 > Project: CXF > Issue Type: Bug > Components: Build system >Affects Versions: 3.3.2 >Reporter: Atle Tokle >Assignee: Freeman Fang >Priority: Minor > > I get two warnings about deprecated properties when building with > cxf-codegen-plugin. > [WARNING] configuration key 'class.resource.loader.class' has been deprecated > in favor of 'resource.loader.class.class' > [WARNING] configuration key 'resource.loader' has been deprecated in favor > of 'resource.loaders' > > Not very important, but i prefere clean logs, and it should be easy to fix > It does probably come from org.apache.cxf.tools.common.VelocityGenerator -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (CXF-8090) Warnings when using cxf-codegen-plugin
[ https://issues.apache.org/jira/browse/CXF-8090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned CXF-8090: - Assignee: Freeman Fang > Warnings when using cxf-codegen-plugin > -- > > Key: CXF-8090 > URL: https://issues.apache.org/jira/browse/CXF-8090 > Project: CXF > Issue Type: Bug > Components: Build system >Affects Versions: 3.3.2 >Reporter: Atle Tokle >Assignee: Freeman Fang >Priority: Minor > > I get two warnings about deprecated properties when building with > cxf-codegen-plugin. > [WARNING] configuration key 'class.resource.loader.class' has been deprecated > in favor of 'resource.loader.class.class' > [WARNING] configuration key 'resource.loader' has been deprecated in favor > of 'resource.loaders' > > Not very important, but i prefere clean logs, and it should be easy to fix > It does probably come from org.apache.cxf.tools.common.VelocityGenerator -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (CXF-8088) ensure jaxrs endpoint can work correctly when using a shared bus exposed from another bundle
[ https://issues.apache.org/jira/browse/CXF-8088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-8088. --- Resolution: Fixed Fix Version/s: 3.2.10 3.3.3 > ensure jaxrs endpoint can work correctly when using a shared bus exposed from > another bundle > > > Key: CXF-8088 > URL: https://issues.apache.org/jira/browse/CXF-8088 > Project: CXF > Issue Type: Bug >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > Fix For: 3.3.3, 3.2.10 > > > major 2 issues > 1. not unregister the jaxrs endpoint correctly when stop the jaxrs endpoint > bundle. > 2. jaxrs binding should be added as bus extension so that the bus used by > jaxrs binding factory is always valid -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (CXF-8088) ensure jaxrs endpoint can work correctly when using a shared bus exposed from another bundle
Freeman Fang created CXF-8088: - Summary: ensure jaxrs endpoint can work correctly when using a shared bus exposed from another bundle Key: CXF-8088 URL: https://issues.apache.org/jira/browse/CXF-8088 Project: CXF Issue Type: Bug Reporter: Freeman Fang major 2 issues 1. not unregister the jaxrs endpoint correctly when stop the jaxrs endpoint bundle. 2. jaxrs binding should be added as bus extension so that the bus used by jaxrs binding factory is always valid -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (CXF-8088) ensure jaxrs endpoint can work correctly when using a shared bus exposed from another bundle
[ https://issues.apache.org/jira/browse/CXF-8088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned CXF-8088: - Assignee: Freeman Fang > ensure jaxrs endpoint can work correctly when using a shared bus exposed from > another bundle > > > Key: CXF-8088 > URL: https://issues.apache.org/jira/browse/CXF-8088 > Project: CXF > Issue Type: Bug >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > > major 2 issues > 1. not unregister the jaxrs endpoint correctly when stop the jaxrs endpoint > bundle. > 2. jaxrs binding should be added as bus extension so that the bus used by > jaxrs binding factory is always valid -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (CXF-8082) [Apache cxf 3.1.4] ConcurrentModificationException
[
https://issues.apache.org/jira/browse/CXF-8082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899094#comment-16899094
]
Freeman Fang commented on CXF-8082:
---
Hi [~Samadou],
As I pointed the doc here
https://cxf.apache.org/faq.html#FAQ-AreJAX-WSclientproxiesthreadsafe?
The cxf proxy isn't threadsafe for many cases, like
{code}
request context is PER INSTANCE. Thus, anything set there will affect requests
on other threads
{code}
including the
Message.PROTOCOL_HEADERS
you set there.
So I believe
{code}
((BindingProvider)proxy).getRequestContext().put("thread.local.request.context",
"true");
{code}
which can make request context threadsafe could address this issue.
Freeman
> [Apache cxf 3.1.4] ConcurrentModificationException
> --
>
> Key: CXF-8082
> URL: https://issues.apache.org/jira/browse/CXF-8082
> Project: CXF
> Issue Type: Bug
> Components: Bus
>Affects Versions: 3.1.4
>Reporter: SARE Samadou
>Priority: Blocker
>
> Scenario: we have an exception with the following stack trace in one a batch
> processing using spring batch. This batch use 4 concurrents thread , each of
> them make processiing in separate partition
> Caused by: java.util.ConcurrentModificationException: null
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1442)
> at java.util.HashMap$EntryIterator.next(HashMap.java:1476)
> at java.util.HashMap$EntryIterator.next(HashMap.java:1474)
> at java.util.AbstractMap.putAll(AbstractMap.java:280)
> at java.util.TreeMap.putAll(TreeMap.java:327)
> at
> org.apache.cxf.transport.http.Headers.getSetProtocolHeaders(Headers.java:249)
> at org.apache.cxf.transport.http.Headers.(Headers.java:90)
> at
> org.apache.cxf.transport.http.HTTPConduit.setHeadersByAuthorizationPolicy(HTTPConduit.java:787)
> at org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:556)
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:46)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:324)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:277)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:139)
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (CXF-8082) [Apache cxf 3.1.4] ConcurrentModificationException
[ https://issues.apache.org/jira/browse/CXF-8082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-8082. --- Resolution: Information Provided > [Apache cxf 3.1.4] ConcurrentModificationException > -- > > Key: CXF-8082 > URL: https://issues.apache.org/jira/browse/CXF-8082 > Project: CXF > Issue Type: Bug > Components: Bus >Affects Versions: 3.1.4 >Reporter: SARE Samadou >Priority: Blocker > > Scenario: we have an exception with the following stack trace in one a batch > processing using spring batch. This batch use 4 concurrents thread , each of > them make processiing in separate partition > Caused by: java.util.ConcurrentModificationException: null > at java.util.HashMap$HashIterator.nextNode(HashMap.java:1442) > at java.util.HashMap$EntryIterator.next(HashMap.java:1476) > at java.util.HashMap$EntryIterator.next(HashMap.java:1474) > at java.util.AbstractMap.putAll(AbstractMap.java:280) > at java.util.TreeMap.putAll(TreeMap.java:327) > at > org.apache.cxf.transport.http.Headers.getSetProtocolHeaders(Headers.java:249) > at org.apache.cxf.transport.http.Headers.(Headers.java:90) > at > org.apache.cxf.transport.http.HTTPConduit.setHeadersByAuthorizationPolicy(HTTPConduit.java:787) > at org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:556) > at > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:46) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:324) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:277) > at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96) > at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:139) -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (CXF-8084) Wrong adress for endpoints is generated with autoRewriteSoapAddressForAllServices
[ https://issues.apache.org/jira/browse/CXF-8084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-8084. --- Resolution: Information Provided > Wrong adress for endpoints is generated with > autoRewriteSoapAddressForAllServices > - > > Key: CXF-8084 > URL: https://issues.apache.org/jira/browse/CXF-8084 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.3.2 >Reporter: George Sedov >Priority: Major > > When using autoRewriteSoapAddressForAllServices the generated service address > in WSDL is wrong. It is constructed using the "http.base.path", which is > basically CXF context, plus the publishing address of the endpoint. But there > should also be "services" between them, i.e. > [http://example.com/cxfContext/services/myServiceEndpoint] > instead of > [http://example.com/cxfContext/myServiceEndpoint|http://example.com/cxfContext/services/myServiceEndpoint] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (CXF-8084) Wrong adress for endpoints is generated with autoRewriteSoapAddressForAllServices
[ https://issues.apache.org/jira/browse/CXF-8084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899068#comment-16899068 ] Freeman Fang commented on CXF-8084: --- Hi [~morse] FYI, the "http.base.path" is calculate from the HttpServletRequest in org.apache.cxf.transport.http,AbstractHTTPDestination.setupMessage method for each request. And it's by design your configuration for servlet context will affect the "http.base.path", you can configure the servlet context in spring boot, plain servlet or in OSGi. So this is more about a configuration question. Freeman > Wrong adress for endpoints is generated with > autoRewriteSoapAddressForAllServices > - > > Key: CXF-8084 > URL: https://issues.apache.org/jira/browse/CXF-8084 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.3.2 >Reporter: George Sedov >Priority: Major > > When using autoRewriteSoapAddressForAllServices the generated service address > in WSDL is wrong. It is constructed using the "http.base.path", which is > basically CXF context, plus the publishing address of the endpoint. But there > should also be "services" between them, i.e. > [http://example.com/cxfContext/services/myServiceEndpoint] > instead of > [http://example.com/cxfContext/myServiceEndpoint|http://example.com/cxfContext/services/myServiceEndpoint] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (CXF-8083) ensure java2swagger-plugin|java2ws-plugin m2e compatible
[
https://issues.apache.org/jira/browse/CXF-8083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang resolved CXF-8083.
---
Resolution: Fixed
Fix Version/s: 3.2.10
3.3.3
> ensure java2swagger-plugin|java2ws-plugin m2e compatible
>
>
> Key: CXF-8083
> URL: https://issues.apache.org/jira/browse/CXF-8083
> Project: CXF
> Issue Type: Improvement
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 3.3.3, 3.2.10
>
>
> avoid errors like
> {code}
> Plugin execution not covered by lifecycle configuration:
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CXF-8084) Wrong adress for endpoints is generated with autoRewriteSoapAddressForAllServices
[ https://issues.apache.org/jira/browse/CXF-8084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16897303#comment-16897303 ] Freeman Fang commented on CXF-8084: --- Hi [~morse], I don't think we really need the "services" between if there's no compulsory specs about it. Btw, you can use property "publishedEndpointUrl" to specify anything you want for the soap address. Freeman > Wrong adress for endpoints is generated with > autoRewriteSoapAddressForAllServices > - > > Key: CXF-8084 > URL: https://issues.apache.org/jira/browse/CXF-8084 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.3.2 >Reporter: George Sedov >Priority: Major > > When using autoRewriteSoapAddressForAllServices the generated service address > in WSDL is wrong. It is constructed using the "http.base.path", which is > basically CXF context, plus the publishing address of the endpoint. But there > should also be "services" between them, i.e. > [http://example.com/cxfContext/services/myServiceEndpoint] > instead of > [http://example.com/cxfContext/myServiceEndpoint|http://example.com/cxfContext/services/myServiceEndpoint] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (CXF-8083) ensure java2swagger-plugin|java2ws-plugin m2e compatible
Freeman Fang created CXF-8083:
-
Summary: ensure java2swagger-plugin|java2ws-plugin m2e compatible
Key: CXF-8083
URL: https://issues.apache.org/jira/browse/CXF-8083
Project: CXF
Issue Type: Improvement
Reporter: Freeman Fang
avoid errors like
{code}
Plugin execution not covered by lifecycle configuration:
{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (CXF-8083) ensure java2swagger-plugin|java2ws-plugin m2e compatible
[
https://issues.apache.org/jira/browse/CXF-8083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang reassigned CXF-8083:
-
Assignee: Freeman Fang
> ensure java2swagger-plugin|java2ws-plugin m2e compatible
>
>
> Key: CXF-8083
> URL: https://issues.apache.org/jira/browse/CXF-8083
> Project: CXF
> Issue Type: Improvement
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
>
> avoid errors like
> {code}
> Plugin execution not covered by lifecycle configuration:
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (CXF-8081) should cache reactor OutputStream
[ https://issues.apache.org/jira/browse/CXF-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-8081. --- Resolution: Fixed Fix Version/s: 3.2.10 3.3.3 > should cache reactor OutputStream > - > > Key: CXF-8081 > URL: https://issues.apache.org/jira/browse/CXF-8081 > Project: CXF > Issue Type: Test >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > Fix For: 3.3.3, 3.2.10 > > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (CXF-8082) [Apache cxf 3.1.4] ConcurrentModificationException
[ https://issues.apache.org/jira/browse/CXF-8082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16897051#comment-16897051 ] Freeman Fang commented on CXF-8082: --- Hi [~Samadou], Could you please elaborate the scenario how you run into this issue? Btw, please take a look at the doc here https://cxf.apache.org/faq.html#FAQ-AreJAX-WSclientproxiesthreadsafe? CXF client proxy isn't threadsafe in some cases. Freeman > [Apache cxf 3.1.4] ConcurrentModificationException > -- > > Key: CXF-8082 > URL: https://issues.apache.org/jira/browse/CXF-8082 > Project: CXF > Issue Type: Bug > Components: Bus >Affects Versions: 3.1.4 >Reporter: SARE Samadou >Priority: Blocker > > Caused by: java.util.ConcurrentModificationException: null > at java.util.HashMap$HashIterator.nextNode(HashMap.java:1442) > at java.util.HashMap$EntryIterator.next(HashMap.java:1476) > at java.util.HashMap$EntryIterator.next(HashMap.java:1474) > at java.util.AbstractMap.putAll(AbstractMap.java:280) > at java.util.TreeMap.putAll(TreeMap.java:327) > at > org.apache.cxf.transport.http.Headers.getSetProtocolHeaders(Headers.java:249) > at org.apache.cxf.transport.http.Headers.(Headers.java:90) > at > org.apache.cxf.transport.http.HTTPConduit.setHeadersByAuthorizationPolicy(HTTPConduit.java:787) > at org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:556) > at > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:46) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:324) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:277) > at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96) > at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:139) -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (CXF-8081) should cache reactor OutputStream
[ https://issues.apache.org/jira/browse/CXF-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang updated CXF-8081: -- Summary: should cache reactor OutputStream (was: org.apache.cxf.systest.jaxrs.reactor.FluxReactorTest failed for all JDKs) > should cache reactor OutputStream > - > > Key: CXF-8081 > URL: https://issues.apache.org/jira/browse/CXF-8081 > Project: CXF > Issue Type: Test >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (CXF-8081) org.apache.cxf.systest.jaxrs.reactor.FluxReactorTest failed for all JDKs
[ https://issues.apache.org/jira/browse/CXF-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang updated CXF-8081: -- Summary: org.apache.cxf.systest.jaxrs.reactor.FluxReactorTest failed for all JDKs (was: The OutputStream in StreamingResponseProvider should be cached) > org.apache.cxf.systest.jaxrs.reactor.FluxReactorTest failed for all JDKs > > > Key: CXF-8081 > URL: https://issues.apache.org/jira/browse/CXF-8081 > Project: CXF > Issue Type: Test >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (CXF-8081) The OutputStream in StreamingResponseProvider should be cached
[ https://issues.apache.org/jira/browse/CXF-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang updated CXF-8081: -- Summary: The OutputStream in StreamingResponseProvider should be cached (was: org.apache.cxf.systest.jaxrs.reactor.FluxReactorTest failed for all JDKs) > The OutputStream in StreamingResponseProvider should be cached > -- > > Key: CXF-8081 > URL: https://issues.apache.org/jira/browse/CXF-8081 > Project: CXF > Issue Type: Test >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (CXF-8081) org.apache.cxf.systest.jaxrs.reactor.FluxReactorTest failed for all JDKs
[ https://issues.apache.org/jira/browse/CXF-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned CXF-8081: - Assignee: Freeman Fang > org.apache.cxf.systest.jaxrs.reactor.FluxReactorTest failed for all JDKs > > > Key: CXF-8081 > URL: https://issues.apache.org/jira/browse/CXF-8081 > Project: CXF > Issue Type: Test >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (CXF-8081) org.apache.cxf.systest.jaxrs.reactor.FluxReactorTest failed for all JDKs
[ https://issues.apache.org/jira/browse/CXF-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896467#comment-16896467 ] Freeman Fang commented on CXF-8081: --- The change for CXF-8032 exposes this issue but it's not the root cause. Previously the FluxReactorTest ran successfully because the server side using LoggingOutInterceptor, if not using LoggingOutInterceptor, with/without change for CXF-8032, it fails consistently. Using LoggingOutInterceptor or not shouldn't change the behavior of FluxReactorTest > org.apache.cxf.systest.jaxrs.reactor.FluxReactorTest failed for all JDKs > > > Key: CXF-8081 > URL: https://issues.apache.org/jira/browse/CXF-8081 > Project: CXF > Issue Type: Test >Reporter: Freeman Fang >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (CXF-8081) org.apache.cxf.systest.jaxrs.reactor.FluxReactorTest failed for all JDKs
[ https://issues.apache.org/jira/browse/CXF-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896354#comment-16896354 ] Freeman Fang commented on CXF-8081: --- Yes, the change in CXF-8032 caused this > org.apache.cxf.systest.jaxrs.reactor.FluxReactorTest failed for all JDKs > > > Key: CXF-8081 > URL: https://issues.apache.org/jira/browse/CXF-8081 > Project: CXF > Issue Type: Test >Reporter: Freeman Fang >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (CXF-8081) org.apache.cxf.systest.jaxrs.reactor.FluxReactorTest failed for all JDKs
[ https://issues.apache.org/jira/browse/CXF-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16896239#comment-16896239 ] Freeman Fang commented on CXF-8081: --- https://builds.apache.org/job/CXF-Trunk-JDK18/4504/ https://builds.apache.org/job/CXF-Master-JDK11/573/ Seems the commit for CXF-8032 is the cause > org.apache.cxf.systest.jaxrs.reactor.FluxReactorTest failed for all JDKs > > > Key: CXF-8081 > URL: https://issues.apache.org/jira/browse/CXF-8081 > Project: CXF > Issue Type: Test >Reporter: Freeman Fang >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (CXF-8081) org.apache.cxf.systest.jaxrs.reactor.FluxReactorTest failed for all JDKs
Freeman Fang created CXF-8081: - Summary: org.apache.cxf.systest.jaxrs.reactor.FluxReactorTest failed for all JDKs Key: CXF-8081 URL: https://issues.apache.org/jira/browse/CXF-8081 Project: CXF Issue Type: Test Reporter: Freeman Fang -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (CXF-8072) Loggers logs request twice in case of Fault (CXF-7518 again)
[ https://issues.apache.org/jira/browse/CXF-8072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-8072. --- Resolution: Fixed Fix Version/s: 3.2.10 3.3.3 > Loggers logs request twice in case of Fault (CXF-7518 again) > > > Key: CXF-8072 > URL: https://issues.apache.org/jira/browse/CXF-8072 > Project: CXF > Issue Type: Bug > Components: logging >Affects Versions: 3.2.9 >Reporter: Tomasz Poręba >Assignee: Freeman Fang >Priority: Minor > Fix For: 3.3.3, 3.2.10 > > > I noticed that I experience the same problem as in issue CXF-7518 but in far > newer version - 3.2.9. It seems that the fix of CXF-7562 added again the same > code that was removed in CXF-7518. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CXF-8072) Loggers logs request twice in case of Fault (CXF-7518 again)
[ https://issues.apache.org/jira/browse/CXF-8072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned CXF-8072: - Assignee: Freeman Fang > Loggers logs request twice in case of Fault (CXF-7518 again) > > > Key: CXF-8072 > URL: https://issues.apache.org/jira/browse/CXF-8072 > Project: CXF > Issue Type: Bug > Components: logging >Affects Versions: 3.2.9 >Reporter: Tomasz Poręba >Assignee: Freeman Fang >Priority: Minor > > I noticed that I experience the same problem as in issue CXF-7518 but in far > newer version - 3.2.9. It seems that the fix of CXF-7562 added again the same > code that was removed in CXF-7518. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-8064) OpenApiFeature(OpenAPI V3) should be able to work with camel-cxfrs endpoint
[ https://issues.apache.org/jira/browse/CXF-8064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-8064. --- Resolution: Fixed Fix Version/s: 3.2.10 3.3.3 > OpenApiFeature(OpenAPI V3) should be able to work with camel-cxfrs endpoint > --- > > Key: CXF-8064 > URL: https://issues.apache.org/jira/browse/CXF-8064 > Project: CXF > Issue Type: Improvement >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > Fix For: 3.3.3, 3.2.10 > > > we should add another ContainerRequestFilter for OpenApiFeature, so the > swagger related request can be intercepted and won't go in camel router, like > what we've done for Swagger2Feature. > In V3, io.swagger.v3.jaxrs2.integration.resources.OpenApiResource.getOpenApi > should be used to fetch swagger(json|yaml) payload -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-8069) CXF does not allow to change default configuration of Jetty
[
https://issues.apache.org/jira/browse/CXF-8069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16877910#comment-16877910
]
Freeman Fang commented on CXF-8069:
---
Hi [~naina.pati...@infobeans.com],
FYI, the http-jetty transport in CXF also call jetty
sslContextFactory.setExcludeCipherSuites method to exclude CipherSuites, you
can configure the ciphersuite as described
[here|https://cxf.apache.org/docs/tls-configuration.html#TLSConfiguration-CipherSuitesFilter]
You can configure per the above document and debug the code in
org.apache.cxf.transport.http_jetty.JettyHTTPServerEngine.createSSLContext(SslContextFactory
scf) to see how the SslContextFactory.setExcludeCipherSuites get invoked there.
Freeman
> CXF does not allow to change default configuration of Jetty
> ---
>
> Key: CXF-8069
> URL: https://issues.apache.org/jira/browse/CXF-8069
> Project: CXF
> Issue Type: Bug
> Environment: CXF : 3.2.7
> Jetty: 9.4.18v20190429
> Java : IBM Java 8
> Platform : AIX
>
>Reporter: Naina
>Priority: Blocker
>
> Hi Team,
> We are using Apache CXF 3.2.7 and seeking help to update jetty's default
> configuration which is being used by Apache CXF.
> CXF internally calls jetty and jetty has default configuration to exclude
> cipher suites which starts with SSL_*. As all the TLS cipher suites of IBM
> Java 8 starts wih SSL_*, we are unable to establish connection with Jetty
> using IBM Java 8. So the ask is, how can we update the default configuration
> of Jetty via CXF.
> We resolved the same issue on one of our server with the help of Jetty team
> where we were creating Jetty instance in our code and were getting warning
> "No supported ciphers from [ListOfAvailableCiphers]". They suggested to add
> *sslContextFactory.setExcludeCipherSuites(ListOfWeakCiphers)* method while
> creating Jetty's instance, which actually overrides the default cipher suites
> excluded by Jetty.
> But in the current case, we just call CXF's JAXRSServerFactoryBean create()
> method which internally calls Jetty and create its instance with default
> configuration. Here is the code snippet:
> {color:#205081}_private JAXRSServerFactoryBean sf = new
> JAXRSServerFactoryBean();_{color}
> {color:#205081}_private JettyHTTPDestination startEndpoint() {_{color}
> {color:#205081} _logger.info("*+before Starting RESTful Agent+*");_{color}
> {color:#205081} _Server server = sf.create();_{color}
> {color:#205081} _logger.info("*+Started RESTful Agent at:+* " +
> server.getEndpoint().getEndpointInfo().getAddress());_{color}
> {color:#205081} _return (JettyHTTPDestination)
> server.getDestination();_{color}
> {color:#205081} _}_{color}
>
> These are the logs which got generated during the execution of above code :
> {color:#205081}_[2019-07-03T07:37:33,324-0500] INFO [main]
> com.netapp.snapcreator.agent.nextgen.RestEndpointHelper - *+before Starting
> RESTful Agent+*_{color}
> {color:#205081}_[2019-07-03T07:37:33,396-0500] INFO [main]
> org.apache.cxf.endpoint.ServerImpl - Setting the server's publish address to
> be https://localhost:9091/SnapCreator/_{color}
> {color:#205081}_[2019-07-03T07:37:33,503-0500] INFO [main]
> org.eclipse.jetty.util.log - Logging initialized @2814ms to
> org.eclipse.jetty.util.log.Slf4jLog_{color}
> {color:#205081}_[2019-07-03T07:37:33,566-0500] INFO [main]
> org.eclipse.jetty.server.Server - jetty-9.4.18.v20190429; built:
> 2019-04-29T20:42:08.989Z; git: e1bc35120a6617ee3df052294e433f3a25ce7097; jvm
> 8.0.5.21 - pap6480sr5fp21-20180830_01(SR5 FP21)_{color}
> {color:#205081}_[2019-07-03T07:37:33,746-0500] WARN [main]
> *org.eclipse.jetty.util.ssl.SslContextFactory -* *No supported ciphers from*
> [TLS_EMPTY_RENEGOTIATION_INFO_SCSV, SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
> SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384, SSL_RSA_WITH_AES_256_CBC_SHA256,
> SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, SSL_ECDH_RSA_WITH_AES_256_CBC_SHA384,
> SSL_DHE_RSA_WITH_AES_256_CBC_SHA256, SSL_DHE_DSS_WITH_AES_256_CBC_SHA256,
> SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA,
> SSL_RSA_WITH_AES_256_CBC_SHA, SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
> SSL_ECDH_RSA_WITH_AES_256_CBC_SHA, SSL_DHE_RSA_WITH_AES_256_CBC_SHA,
> SSL_DHE_DSS_WITH_AES_256_CBC_SHA, SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
> SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256, SSL_RSA_WITH_AES_128_CBC_SHA256,
> SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256,
> SSL_DHE_RSA_WITH_AES_128_CBC_SHA256, SSL_DHE_DSS_WITH_AES_128_CBC_SHA256,
> SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA,
> SSL_RSA_WITH_AES_128_CBC_SHA, SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
> SSL_ECDH_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_RSA_WITH_AES_128_CBC_SHA,
> SSL_DHE_DSS_WITH_AES_128_CBC_SHA,
[jira] [Resolved] (CXF-8062) MessageContext.HTTP_RESPONSE_CODE cannot be obtained if response code is not 4xx
[
https://issues.apache.org/jira/browse/CXF-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang resolved CXF-8062.
---
Resolution: Fixed
Fix Version/s: 3.2.10
3.3.3
> MessageContext.HTTP_RESPONSE_CODE cannot be obtained if response code is not
> 4xx
>
>
> Key: CXF-8062
> URL: https://issues.apache.org/jira/browse/CXF-8062
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.3.2
>Reporter: Tomás García
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 3.3.3, 3.2.10
>
> Attachments: 200.png, 401.PNG, cxf_dependencies.PNG,
> cxfresponsecode.zip
>
>
> After a web service request, we do this:
> {code:java}
> responseCode = (Integer) ((BindingProvider)
> webServicePort).getResponseContext().get(MessageContext.HTTP_RESPONSE_CODE);
> {code}
> , to extract the Http response code, but we noticed that this only works in
> our case with 200 response codes from the server.
> From what I could gather, it seems that the response context is not populated
> in cases where a 200 is not given. Example:
> !401.PNG!
> As you can see only two instances of SCOPES are in the response context.
> When we receive a 200 from the web service, the response context contains
> this:
> !200.png!
> , which although you can't see it in the screenshot, it contains the
> HTTP_RESPONSE_CODE value, which it's the only thing we need, because we need
> to do some additional steps depending on that response code afterwards.
> Right now, we're using a finicky way to obtain such http response code... the
> exception is a WebServiceException which contains a HTTPException which has
> the response code given by the server. We'd like to have a more reliable way
> since those exception signatures could just change over time if we update
> libraries / java versions we guess.
> Here's the CXF dependencies in our project:
> !cxf_dependencies.PNG!
> Let us know if you need to know about anything else.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CXF-8062) MessageContext.HTTP_RESPONSE_CODE cannot be obtained if response code is not 4xx
[
https://issues.apache.org/jira/browse/CXF-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang updated CXF-8062:
--
Summary: MessageContext.HTTP_RESPONSE_CODE cannot be obtained if response
code is not 4xx (was: MessageContext.HTTP_RESPONSE_CODE cannot be obtained if
response code is not 200)
> MessageContext.HTTP_RESPONSE_CODE cannot be obtained if response code is not
> 4xx
>
>
> Key: CXF-8062
> URL: https://issues.apache.org/jira/browse/CXF-8062
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.3.2
>Reporter: Tomás García
>Assignee: Freeman Fang
>Priority: Major
> Attachments: 200.png, 401.PNG, cxf_dependencies.PNG,
> cxfresponsecode.zip
>
>
> After a web service request, we do this:
> {code:java}
> responseCode = (Integer) ((BindingProvider)
> webServicePort).getResponseContext().get(MessageContext.HTTP_RESPONSE_CODE);
> {code}
> , to extract the Http response code, but we noticed that this only works in
> our case with 200 response codes from the server.
> From what I could gather, it seems that the response context is not populated
> in cases where a 200 is not given. Example:
> !401.PNG!
> As you can see only two instances of SCOPES are in the response context.
> When we receive a 200 from the web service, the response context contains
> this:
> !200.png!
> , which although you can't see it in the screenshot, it contains the
> HTTP_RESPONSE_CODE value, which it's the only thing we need, because we need
> to do some additional steps depending on that response code afterwards.
> Right now, we're using a finicky way to obtain such http response code... the
> exception is a WebServiceException which contains a HTTPException which has
> the response code given by the server. We'd like to have a more reliable way
> since those exception signatures could just change over time if we update
> libraries / java versions we guess.
> Here's the CXF dependencies in our project:
> !cxf_dependencies.PNG!
> Let us know if you need to know about anything else.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-8062) MessageContext.HTTP_RESPONSE_CODE cannot be obtained if response code is not 200
[
https://issues.apache.org/jira/browse/CXF-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16877244#comment-16877244
]
Freeman Fang commented on CXF-8062:
---
OK, for 4xx return code(just like in your testcase), CXF client side will throw
HTTPException and not set return code. Anyway, IMO it's no harm to set 4xx
return code as well. The fix is coming soon.
Freeman
> MessageContext.HTTP_RESPONSE_CODE cannot be obtained if response code is not
> 200
>
>
> Key: CXF-8062
> URL: https://issues.apache.org/jira/browse/CXF-8062
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.3.2
>Reporter: Tomás García
>Assignee: Freeman Fang
>Priority: Major
> Attachments: 200.png, 401.PNG, cxf_dependencies.PNG,
> cxfresponsecode.zip
>
>
> After a web service request, we do this:
> {code:java}
> responseCode = (Integer) ((BindingProvider)
> webServicePort).getResponseContext().get(MessageContext.HTTP_RESPONSE_CODE);
> {code}
> , to extract the Http response code, but we noticed that this only works in
> our case with 200 response codes from the server.
> From what I could gather, it seems that the response context is not populated
> in cases where a 200 is not given. Example:
> !401.PNG!
> As you can see only two instances of SCOPES are in the response context.
> When we receive a 200 from the web service, the response context contains
> this:
> !200.png!
> , which although you can't see it in the screenshot, it contains the
> HTTP_RESPONSE_CODE value, which it's the only thing we need, because we need
> to do some additional steps depending on that response code afterwards.
> Right now, we're using a finicky way to obtain such http response code... the
> exception is a WebServiceException which contains a HTTPException which has
> the response code given by the server. We'd like to have a more reliable way
> since those exception signatures could just change over time if we update
> libraries / java versions we guess.
> Here's the CXF dependencies in our project:
> !cxf_dependencies.PNG!
> Let us know if you need to know about anything else.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-8062) MessageContext.HTTP_RESPONSE_CODE cannot be obtained if response code is not 200
[
https://issues.apache.org/jira/browse/CXF-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16877116#comment-16877116
]
Freeman Fang commented on CXF-8062:
---
Thanks [~tomasedata] for the reproducer, I will take a close look.
Freeman
> MessageContext.HTTP_RESPONSE_CODE cannot be obtained if response code is not
> 200
>
>
> Key: CXF-8062
> URL: https://issues.apache.org/jira/browse/CXF-8062
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.3.2
>Reporter: Tomás García
>Assignee: Freeman Fang
>Priority: Major
> Attachments: 200.png, 401.PNG, cxf_dependencies.PNG,
> cxfresponsecode.zip
>
>
> After a web service request, we do this:
> {code:java}
> responseCode = (Integer) ((BindingProvider)
> webServicePort).getResponseContext().get(MessageContext.HTTP_RESPONSE_CODE);
> {code}
> , to extract the Http response code, but we noticed that this only works in
> our case with 200 response codes from the server.
> From what I could gather, it seems that the response context is not populated
> in cases where a 200 is not given. Example:
> !401.PNG!
> As you can see only two instances of SCOPES are in the response context.
> When we receive a 200 from the web service, the response context contains
> this:
> !200.png!
> , which although you can't see it in the screenshot, it contains the
> HTTP_RESPONSE_CODE value, which it's the only thing we need, because we need
> to do some additional steps depending on that response code afterwards.
> Right now, we're using a finicky way to obtain such http response code... the
> exception is a WebServiceException which contains a HTTPException which has
> the response code given by the server. We'd like to have a more reliable way
> since those exception signatures could just change over time if we update
> libraries / java versions we guess.
> Here's the CXF dependencies in our project:
> !cxf_dependencies.PNG!
> Let us know if you need to know about anything else.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-8067) java 11(reproduced on openjdk/oracle/coretto/adopt): java.lang.VerifyError: Falling off the end of the code
[
https://issues.apache.org/jira/browse/CXF-8067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16877107#comment-16877107
]
Freeman Fang commented on CXF-8067:
---
Hi [~rbelinsky],
A reproducer would be a good way(sometimes even the only way) to get an issue
resolved quickly.
Maybe you could craft a testcase without your specific business logic which you
can share with community to help us nail down the problem.
Thanks!
Freeman
> java 11(reproduced on openjdk/oracle/coretto/adopt): java.lang.VerifyError:
> Falling off the end of the code
> ---
>
> Key: CXF-8067
> URL: https://issues.apache.org/jira/browse/CXF-8067
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.3.2
>Reporter: Roman Belinsky
>Priority: Blocker
>
> exception in runtime:
>
> {{(class:
> com/xatel/webservice/services/configurationservice/definition/jaxws_asm/GetAllStationsResponse,
> method: getReturn signature: ()Ljava/util/List;) Falling off the end of the
> code java.lang.VerifyError: (class:
> com/xatel/webservice/services/configurationservice/definition/jaxws_asm/GetAllStationsResponse,
> method: getReturn signature: ()Ljava/util/List;) Falling off the end of the
> code at java.base/java.lang.Class.getDeclaredConstructors0(Native Method) at
> java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3138) at
> java.base/java.lang.Class.getConstructor0(Class.java:3343) at
> java.base/java.lang.Class.getDeclaredConstructor(Class.java:2554) at
> org.apache.cxf.common.util.ReflectionUtil$4.run(ReflectionUtil.java:99) at
> org.apache.cxf.common.util.ReflectionUtil$4.run(ReflectionUtil.java:96) at
> java.base/java.security.AccessController.doPrivileged(Native Method) at
> org.apache.cxf.common.util.ReflectionUtil.getDeclaredConstructor(ReflectionUtil.java:96)
> at org.apache.cxf.common.jaxb.JAXBUtils.getValidClass(JAXBUtils.java:591) at
> org.apache.cxf.jaxb.JAXBContextInitializer.addClass(JAXBContextInitializer.java:324)
> at
> org.apache.cxf.jaxb.JAXBContextInitializer.begin(JAXBContextInitializer.java:187)
> at
> org.apache.cxf.service.ServiceModelVisitor.visitOperation(ServiceModelVisitor.java:109)
> at
> org.apache.cxf.service.ServiceModelVisitor.walk(ServiceModelVisitor.java:74)
> at org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:341)
> at
> org.apache.cxf.service.factory.AbstractServiceFactoryBean.initializeDataBindings(AbstractServiceFactoryBean.java:86)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:470)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:693)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:530)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:263)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
> at
> org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103)
> at
> org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:91)
> at
> org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:159)
> at
> org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:142)}}
>
> {{project dependencies :}}
> {{[https://gist.github.com/kain64/7ac95cef2cd783a81f7a698cc66ebf8c] }}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CXF-8064) OpenApiFeature(OpenAPI V3) should be able to work with camel-cxfrs endpoint
Freeman Fang created CXF-8064: - Summary: OpenApiFeature(OpenAPI V3) should be able to work with camel-cxfrs endpoint Key: CXF-8064 URL: https://issues.apache.org/jira/browse/CXF-8064 Project: CXF Issue Type: Improvement Reporter: Freeman Fang we should add another ContainerRequestFilter for OpenApiFeature, so the swagger related request can be intercepted and won't go in camel router, like what we've done for Swagger2Feature. In V3, io.swagger.v3.jaxrs2.integration.resources.OpenApiResource.getOpenApi should be used to fetch swagger(json|yaml) payload -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CXF-8064) OpenApiFeature(OpenAPI V3) should be able to work with camel-cxfrs endpoint
[ https://issues.apache.org/jira/browse/CXF-8064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned CXF-8064: - Assignee: Freeman Fang > OpenApiFeature(OpenAPI V3) should be able to work with camel-cxfrs endpoint > --- > > Key: CXF-8064 > URL: https://issues.apache.org/jira/browse/CXF-8064 > Project: CXF > Issue Type: Improvement >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > > we should add another ContainerRequestFilter for OpenApiFeature, so the > swagger related request can be intercepted and won't go in camel router, like > what we've done for Swagger2Feature. > In V3, io.swagger.v3.jaxrs2.integration.resources.OpenApiResource.getOpenApi > should be used to fetch swagger(json|yaml) payload -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-8062) MessageContext.HTTP_RESPONSE_CODE cannot be obtained if response code is not 200
[
https://issues.apache.org/jira/browse/CXF-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16875050#comment-16875050
]
Freeman Fang commented on CXF-8062:
---
Hi [~tomasedata],
I just committed to demonstrate that MessageContext.HTTP_RESPONSE_CODE can be
obtained if response code is not 200
https://github.com/apache/cxf/commit/d4a28ed9d3d1f136263565516accfae9366c41b2
So if you can append a testcase project which can reproduce the issue you
described, that would be very helpful.
Thanks!
Freeman
> MessageContext.HTTP_RESPONSE_CODE cannot be obtained if response code is not
> 200
>
>
> Key: CXF-8062
> URL: https://issues.apache.org/jira/browse/CXF-8062
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.3.2
>Reporter: Tomás García
>Assignee: Freeman Fang
>Priority: Major
> Attachments: 200.png, 401.PNG, cxf_dependencies.PNG
>
>
> After a web service request, we do this:
> {code:java}
> responseCode = (Integer) ((BindingProvider)
> webServicePort).getResponseContext().get(MessageContext.HTTP_RESPONSE_CODE);
> {code}
> , to extract the Http response code, but we noticed that this only works in
> our case with 200 response codes from the server.
> From what I could gather, it seems that the response context is not populated
> in cases where a 200 is not given. Example:
> !401.PNG!
> As you can see only two instances of SCOPES are in the response context.
> When we receive a 200 from the web service, the response context contains
> this:
> !200.png!
> , which although you can't see it in the screenshot, it contains the
> HTTP_RESPONSE_CODE value, which it's the only thing we need, because we need
> to do some additional steps depending on that response code afterwards.
> Right now, we're using a finicky way to obtain such http response code... the
> exception is a WebServiceException which contains a HTTPException which has
> the response code given by the server. We'd like to have a more reliable way
> since those exception signatures could just change over time if we update
> libraries / java versions we guess.
> Here's the CXF dependencies in our project:
> !cxf_dependencies.PNG!
> Let us know if you need to know about anything else.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (CXF-8062) MessageContext.HTTP_RESPONSE_CODE cannot be obtained if response code is not 200
[
https://issues.apache.org/jira/browse/CXF-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang reassigned CXF-8062:
-
Assignee: Freeman Fang
> MessageContext.HTTP_RESPONSE_CODE cannot be obtained if response code is not
> 200
>
>
> Key: CXF-8062
> URL: https://issues.apache.org/jira/browse/CXF-8062
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.3.2
>Reporter: Tomás García
>Assignee: Freeman Fang
>Priority: Major
> Attachments: 200.png, 401.PNG, cxf_dependencies.PNG
>
>
> After a web service request, we do this:
> {code:java}
> responseCode = (Integer) ((BindingProvider)
> webServicePort).getResponseContext().get(MessageContext.HTTP_RESPONSE_CODE);
> {code}
> , to extract the Http response code, but we noticed that this only works in
> our case with 200 response codes from the server.
> From what I could gather, it seems that the response context is not populated
> in cases where a 200 is not given. Example:
> !401.PNG!
> As you can see only two instances of SCOPES are in the response context.
> When we receive a 200 from the web service, the response context contains
> this:
> !200.png!
> , which although you can't see it in the screenshot, it contains the
> HTTP_RESPONSE_CODE value, which it's the only thing we need, because we need
> to do some additional steps depending on that response code afterwards.
> Right now, we're using a finicky way to obtain such http response code... the
> exception is a WebServiceException which contains a HTTPException which has
> the response code given by the server. We'd like to have a more reliable way
> since those exception signatures could just change over time if we update
> libraries / java versions we guess.
> Here's the CXF dependencies in our project:
> !cxf_dependencies.PNG!
> Let us know if you need to know about anything else.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CXF-8057) upgrade to use stax2-api and woodstox-core latest version
[ https://issues.apache.org/jira/browse/CXF-8057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang updated CXF-8057: -- Fix Version/s: (was: 3.3.3) 3.4.0 > upgrade to use stax2-api and woodstox-core latest version > - > > Key: CXF-8057 > URL: https://issues.apache.org/jira/browse/CXF-8057 > Project: CXF > Issue Type: Task >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > Fix For: 3.4.0 > > > since stax2-api 3.1.4 was released 5 years ago. > And also need t latest woodstox-core to make OSGi happy -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (CXF-8057) upgrade to use stax2-api and woodstox-core latest version
[ https://issues.apache.org/jira/browse/CXF-8057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reopened CXF-8057: --- will revert and defer this change to 3.4 to align with Camel 3.0 > upgrade to use stax2-api and woodstox-core latest version > - > > Key: CXF-8057 > URL: https://issues.apache.org/jira/browse/CXF-8057 > Project: CXF > Issue Type: Task >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > Fix For: 3.3.3 > > > since stax2-api 3.1.4 was released 5 years ago. > And also need t latest woodstox-core to make OSGi happy -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-8057) upgrade to use stax2-api and woodstox-core latest version
[ https://issues.apache.org/jira/browse/CXF-8057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16867623#comment-16867623 ] Freeman Fang commented on CXF-8057: --- Hi Colm, OK, let's defer to 3.4. Camel 3.0 will upgrade stax2-api so seems defer this to CXF 3.4 is more suitable. Cheers Freeman > upgrade to use stax2-api and woodstox-core latest version > - > > Key: CXF-8057 > URL: https://issues.apache.org/jira/browse/CXF-8057 > Project: CXF > Issue Type: Task >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > Fix For: 3.3.3 > > > since stax2-api 3.1.4 was released 5 years ago. > And also need t latest woodstox-core to make OSGi happy -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-8058) OSGi tests broken for both JDK8 and JDK11
Freeman Fang created CXF-8058: - Summary: OSGi tests broken for both JDK8 and JDK11 Key: CXF-8058 URL: https://issues.apache.org/jira/browse/CXF-8058 Project: CXF Issue Type: Test Reporter: Freeman Fang [ERROR] Errors: [ERROR] CamelGroovyTest.testCamelGroovy:48 » WrappedTestContainer [testCamelGroovy(org... [ERROR] CamelJacksonFallbackConverterTest.test:56 » NoTypeConversionAvailable No type ... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-8057) upgrade to use stax2-api and woodstox-core latest version
[ https://issues.apache.org/jira/browse/CXF-8057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-8057. --- Resolution: Fixed Fix Version/s: 3.3.3 > upgrade to use stax2-api and woodstox-core latest version > - > > Key: CXF-8057 > URL: https://issues.apache.org/jira/browse/CXF-8057 > Project: CXF > Issue Type: Task >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > Fix For: 3.3.3 > > > since stax2-api 3.1.4 was released 5 years ago. > And also need t latest woodstox-core to make OSGi happy -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-8057) upgrade to use stax2-api and woodstox-core latest version
[ https://issues.apache.org/jira/browse/CXF-8057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang updated CXF-8057: -- Description: since stax2-api 3.1.4 was released 5 years ago. And also need t latest woodstox-core to make OSGi happy > upgrade to use stax2-api and woodstox-core latest version > - > > Key: CXF-8057 > URL: https://issues.apache.org/jira/browse/CXF-8057 > Project: CXF > Issue Type: Task >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > > since stax2-api 3.1.4 was released 5 years ago. > And also need t latest woodstox-core to make OSGi happy -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-8057) upgrade to use stax2-api and woodstox-core latest version
Freeman Fang created CXF-8057: - Summary: upgrade to use stax2-api and woodstox-core latest version Key: CXF-8057 URL: https://issues.apache.org/jira/browse/CXF-8057 Project: CXF Issue Type: Task Reporter: Freeman Fang -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CXF-8057) upgrade to use stax2-api and woodstox-core latest version
[ https://issues.apache.org/jira/browse/CXF-8057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned CXF-8057: - Assignee: Freeman Fang > upgrade to use stax2-api and woodstox-core latest version > - > > Key: CXF-8057 > URL: https://issues.apache.org/jira/browse/CXF-8057 > Project: CXF > Issue Type: Task >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXFXJC-35) Maven-Plugin xsdtojava Task throws NullPointerException if project.build.sourceEncoding is not set
[
https://issues.apache.org/jira/browse/CXFXJC-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang resolved CXFXJC-35.
Resolution: Fixed
Fix Version/s: 3.3.1
> Maven-Plugin xsdtojava Task throws NullPointerException if
> project.build.sourceEncoding is not set
> --
>
> Key: CXFXJC-35
> URL: https://issues.apache.org/jira/browse/CXFXJC-35
> Project: CXF XJC Utils
> Issue Type: Bug
> Components: Maven Plugin
>Affects Versions: 3.3.0
>Reporter: Philipp Nanz
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 3.3.1
>
>
> If the Maven-Property {{project.build.sourceEncoding}} is not set, the plugin
> execution fails with:
> {quote}
> [ERROR] Failed to execute goal org.apache.cxf:cxf-xjc-plugin:3.3.0:xsdtojava
> (generate-sources) on project : null: MojoExecutionException:
> NullPointerException -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> {quote}
> The error message was not really helpful in locating the problem. The reason
> is that in this case an {{-encoding}} parameter is passed to XJC but without
> any value.
> Solution: The Encoding parameter should only be passed if the Maven property
> is set.
> Thanks in advance!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (CXFXJC-35) Maven-Plugin xsdtojava Task throws NullPointerException if project.build.sourceEncoding is not set
[
https://issues.apache.org/jira/browse/CXFXJC-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang reassigned CXFXJC-35:
--
Assignee: Freeman Fang
> Maven-Plugin xsdtojava Task throws NullPointerException if
> project.build.sourceEncoding is not set
> --
>
> Key: CXFXJC-35
> URL: https://issues.apache.org/jira/browse/CXFXJC-35
> Project: CXF XJC Utils
> Issue Type: Bug
> Components: Maven Plugin
>Affects Versions: 3.3.0
>Reporter: Philipp Nanz
>Assignee: Freeman Fang
>Priority: Major
>
> If the Maven-Property {{project.build.sourceEncoding}} is not set, the plugin
> execution fails with:
> {quote}
> [ERROR] Failed to execute goal org.apache.cxf:cxf-xjc-plugin:3.3.0:xsdtojava
> (generate-sources) on project : null: MojoExecutionException:
> NullPointerException -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> {quote}
> The error message was not really helpful in locating the problem. The reason
> is that in this case an {{-encoding}} parameter is passed to XJC but without
> any value.
> Solution: The Encoding parameter should only be passed if the Maven property
> is set.
> Thanks in advance!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CXF-7112) AsyncHTTPConduit ignore the ReceiveTimeout when use Async JAXWS api
[
https://issues.apache.org/jira/browse/CXF-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863362#comment-16863362
]
Freeman Fang edited comment on CXF-7112 at 6/13/19 8:53 PM:
Hi [~Aritz],
No worries, I saw this problem, it's because you use
"javax.xml.ws.client.receiveTimeout" property which is ignored by
AsyncHttpConduit, working on a fix.
And the workaround so far is that you put the receiveTimeout on HttpClientPolicy
code like
{code}
HTTPConduit c = (HTTPConduit)ClientProxy.getClient(g).getConduit();
c.getClient().setReceiveTimeout(3000);
{code}
Freeman
was (Author: ffang):
Hi [~Aritz],
No worries, I saw this problem, it's because you use
"javax.xml.ws.client.receiveTimeout" property which is ignored by
AsyncHttpConduit, working on a fix.
Freeman
> AsyncHTTPConduit ignore the ReceiveTimeout when use Async JAXWS api
> ---
>
> Key: CXF-7112
> URL: https://issues.apache.org/jira/browse/CXF-7112
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 3.1.9, 3.2.0
>
>
> As for the ahc we should use the application level way to check the
> ReceiveTimeout to let ahc connectionManager to manage the connection
> lifecycle for a better performance.
> This works with jaxws sync api and AsyncHTTPConduit.getHttpResponse have this
> timeout check(AsyncHTTPConduitTest.testTimeout cover this scenario), but with
> jaxws async api we don't have this timeout check for ahc, we need provide one
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CXF-8055) AsyncHTTPConduit should also consider jaxws spec timeout properties
[ https://issues.apache.org/jira/browse/CXF-8055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-8055. --- Resolution: Fixed Fix Version/s: 3.2.10 3.3.3 > AsyncHTTPConduit should also consider jaxws spec timeout properties > --- > > Key: CXF-8055 > URL: https://issues.apache.org/jira/browse/CXF-8055 > Project: CXF > Issue Type: Bug >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > Fix For: 3.3.3, 3.2.10 > > > like > "javax.xml.ws.client.connectionTimeout" > "javax.xml.ws.client.receiveTimeout" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7112) AsyncHTTPConduit ignore the ReceiveTimeout when use Async JAXWS api
[ https://issues.apache.org/jira/browse/CXF-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863395#comment-16863395 ] Freeman Fang commented on CXF-7112: --- created CXF-8055 to track it > AsyncHTTPConduit ignore the ReceiveTimeout when use Async JAXWS api > --- > > Key: CXF-7112 > URL: https://issues.apache.org/jira/browse/CXF-7112 > Project: CXF > Issue Type: Bug > Components: Transports >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > Fix For: 3.1.9, 3.2.0 > > > As for the ahc we should use the application level way to check the > ReceiveTimeout to let ahc connectionManager to manage the connection > lifecycle for a better performance. > This works with jaxws sync api and AsyncHTTPConduit.getHttpResponse have this > timeout check(AsyncHTTPConduitTest.testTimeout cover this scenario), but with > jaxws async api we don't have this timeout check for ahc, we need provide one -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CXF-8055) AsyncHTTPConduit should also consider jaxws spec timeout properties
[ https://issues.apache.org/jira/browse/CXF-8055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned CXF-8055: - Assignee: Freeman Fang > AsyncHTTPConduit should also consider jaxws spec timeout properties > --- > > Key: CXF-8055 > URL: https://issues.apache.org/jira/browse/CXF-8055 > Project: CXF > Issue Type: Bug >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > > like > "javax.xml.ws.client.connectionTimeout" > "javax.xml.ws.client.receiveTimeout" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-8055) AsyncHTTPConduit should also consider jaxws spec timeout properties
Freeman Fang created CXF-8055: - Summary: AsyncHTTPConduit should also consider jaxws spec timeout properties Key: CXF-8055 URL: https://issues.apache.org/jira/browse/CXF-8055 Project: CXF Issue Type: Bug Reporter: Freeman Fang like "javax.xml.ws.client.connectionTimeout" "javax.xml.ws.client.receiveTimeout" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7112) AsyncHTTPConduit ignore the ReceiveTimeout when use Async JAXWS api
[ https://issues.apache.org/jira/browse/CXF-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863362#comment-16863362 ] Freeman Fang commented on CXF-7112: --- Hi [~Aritz], No worries, I saw this problem, it's because you use "javax.xml.ws.client.receiveTimeout" property which is ignored by AsyncHttpConduit, working on a fix. Freeman > AsyncHTTPConduit ignore the ReceiveTimeout when use Async JAXWS api > --- > > Key: CXF-7112 > URL: https://issues.apache.org/jira/browse/CXF-7112 > Project: CXF > Issue Type: Bug > Components: Transports >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > Fix For: 3.1.9, 3.2.0 > > > As for the ahc we should use the application level way to check the > ReceiveTimeout to let ahc connectionManager to manage the connection > lifecycle for a better performance. > This works with jaxws sync api and AsyncHTTPConduit.getHttpResponse have this > timeout check(AsyncHTTPConduitTest.testTimeout cover this scenario), but with > jaxws async api we don't have this timeout check for ahc, we need provide one -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7112) AsyncHTTPConduit ignore the ReceiveTimeout when use Async JAXWS api
[ https://issues.apache.org/jira/browse/CXF-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863293#comment-16863293 ] Freeman Fang commented on CXF-7112: --- Hi [~Aritz], For the test example, I think you can take a look at org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduitTest.testTimeoutAsync() Freeman > AsyncHTTPConduit ignore the ReceiveTimeout when use Async JAXWS api > --- > > Key: CXF-7112 > URL: https://issues.apache.org/jira/browse/CXF-7112 > Project: CXF > Issue Type: Bug > Components: Transports >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > Fix For: 3.1.9, 3.2.0 > > > As for the ahc we should use the application level way to check the > ReceiveTimeout to let ahc connectionManager to manage the connection > lifecycle for a better performance. > This works with jaxws sync api and AsyncHTTPConduit.getHttpResponse have this > timeout check(AsyncHTTPConduitTest.testTimeout cover this scenario), but with > jaxws async api we don't have this timeout check for ahc, we need provide one -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7112) AsyncHTTPConduit ignore the ReceiveTimeout when use Async JAXWS api
[ https://issues.apache.org/jira/browse/CXF-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863162#comment-16863162 ] Freeman Fang commented on CXF-7112: --- Hi [~Aritz], Which CXF version you are using? Could you please append a reproducer testcase? Freeman > AsyncHTTPConduit ignore the ReceiveTimeout when use Async JAXWS api > --- > > Key: CXF-7112 > URL: https://issues.apache.org/jira/browse/CXF-7112 > Project: CXF > Issue Type: Bug > Components: Transports >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > Fix For: 3.1.9, 3.2.0 > > > As for the ahc we should use the application level way to check the > ReceiveTimeout to let ahc connectionManager to manage the connection > lifecycle for a better performance. > This works with jaxws sync api and AsyncHTTPConduit.getHttpResponse have this > timeout check(AsyncHTTPConduitTest.testTimeout cover this scenario), but with > jaxws async api we don't have this timeout check for ahc, we need provide one -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-8052) Cannot set JAXB schema compiler options
[
https://issues.apache.org/jira/browse/CXF-8052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang resolved CXF-8052.
---
Resolution: Fixed
Fix Version/s: 3.2.10
3.3.3
> Cannot set JAXB schema compiler options
> ---
>
> Key: CXF-8052
> URL: https://issues.apache.org/jira/browse/CXF-8052
> Project: CXF
> Issue Type: Bug
> Components: Simple Frontend
>Affects Versions: 3.3.2
> Environment: OpenJDK 12
>Reporter: Ranjit Vadakkan
>Assignee: Freeman Fang
>Priority: Blocker
> Fix For: 3.3.3, 3.2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> JAXB generates an is-prefix getter for a boolean data type in my WSDL instead
> of a get-prefix getter, see
> [https://www.ibm.com/developerworks/community/blogs/Dougclectica/entry/JAXB_with_Java_7_and_xs_boolean?lang=en]
>
> The workaround is simple - pass the "-enableIntrospection" argument to the
> JAXB compiler. Unfortunately, CXF fails with this error -
> {quote}Caused by: com.sun.tools.xjc.BadCommandLineException: grammar is not
> specified
> at com.sun.tools.xjc.Options.parseArguments(Options.java:861)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> ...
> {quote}
>
> The test code to reproduce this is very simple -
> {quote}JaxWsDynamicClientFactory factory =
> JaxWsDynamicClientFactory.newInstance();
> String[] schemaCompilerOptions = new String[] \{"-enableIntrospection"};
> factory.setSchemaCompilerOptions(schemaCompilerOptions);
> Client client = factory.createClient();
> {quote}
>
> The error occurs in
> org.apache.cxf.endpoint.dynamic.DynamicClientFactory#createSchemaCompiler
> {quote}if (schemaCompilerOptions != null && schemaCompilerOptions.length > 0)
> {
> compiler.getOptions().parseArguments(schemaCompilerOptions);
> }
> {quote}
>
> parseArguments expects the XML Schemas to have already been added to the
> compiler.getOptions() object, but in DynamicClientFactory, the schemas are
> added after parseArguments is called, which is why parseArguments spits out
> the "grammar is not specified" error.
> This can be fixed in a couple of ways -
> # Add a dummy schema to the compiler.getOptions() object before invoking
> parseArguments on it.
> # Relocate the call to parseArguments after the schemas have been added to
> the compiler.getOptions() object.
>
> Option 1 is used by
> org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding in its
> initialize() method -
> {quote}// keep parseArguments happy, supply dummy required command-line opts
> opts.addGrammar(new InputSource("null"));
> opts.parseArguments(args.toArray(new String[0]));
> {quote}
>
> Personally, I prefer relocating the call instead of adding a dummy schema.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-8052) Cannot set JAXB schema compiler options
[
https://issues.apache.org/jira/browse/CXF-8052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861096#comment-16861096
]
Freeman Fang commented on CXF-8052:
---
patch applied on behalf of Ranjit Vadakkan with thanks!
> Cannot set JAXB schema compiler options
> ---
>
> Key: CXF-8052
> URL: https://issues.apache.org/jira/browse/CXF-8052
> Project: CXF
> Issue Type: Bug
> Components: Simple Frontend
>Affects Versions: 3.3.2
> Environment: OpenJDK 12
>Reporter: Ranjit Vadakkan
>Assignee: Freeman Fang
>Priority: Blocker
> Fix For: 3.3.3, 3.2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> JAXB generates an is-prefix getter for a boolean data type in my WSDL instead
> of a get-prefix getter, see
> [https://www.ibm.com/developerworks/community/blogs/Dougclectica/entry/JAXB_with_Java_7_and_xs_boolean?lang=en]
>
> The workaround is simple - pass the "-enableIntrospection" argument to the
> JAXB compiler. Unfortunately, CXF fails with this error -
> {quote}Caused by: com.sun.tools.xjc.BadCommandLineException: grammar is not
> specified
> at com.sun.tools.xjc.Options.parseArguments(Options.java:861)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> ...
> {quote}
>
> The test code to reproduce this is very simple -
> {quote}JaxWsDynamicClientFactory factory =
> JaxWsDynamicClientFactory.newInstance();
> String[] schemaCompilerOptions = new String[] \{"-enableIntrospection"};
> factory.setSchemaCompilerOptions(schemaCompilerOptions);
> Client client = factory.createClient();
> {quote}
>
> The error occurs in
> org.apache.cxf.endpoint.dynamic.DynamicClientFactory#createSchemaCompiler
> {quote}if (schemaCompilerOptions != null && schemaCompilerOptions.length > 0)
> {
> compiler.getOptions().parseArguments(schemaCompilerOptions);
> }
> {quote}
>
> parseArguments expects the XML Schemas to have already been added to the
> compiler.getOptions() object, but in DynamicClientFactory, the schemas are
> added after parseArguments is called, which is why parseArguments spits out
> the "grammar is not specified" error.
> This can be fixed in a couple of ways -
> # Add a dummy schema to the compiler.getOptions() object before invoking
> parseArguments on it.
> # Relocate the call to parseArguments after the schemas have been added to
> the compiler.getOptions() object.
>
> Option 1 is used by
> org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding in its
> initialize() method -
> {quote}// keep parseArguments happy, supply dummy required command-line opts
> opts.addGrammar(new InputSource("null"));
> opts.parseArguments(args.toArray(new String[0]));
> {quote}
>
> Personally, I prefer relocating the call instead of adding a dummy schema.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXFXJC-23) jaxb dependancy warnings when compiling against java9
[
https://issues.apache.org/jira/browse/CXFXJC-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861031#comment-16861031
]
Freeman Fang commented on CXFXJC-23:
with CXFXJC-31, we've already upgraded to JAXB 2.3.2, so can close this one now
> jaxb dependancy warnings when compiling against java9
> -
>
> Key: CXFXJC-23
> URL: https://issues.apache.org/jira/browse/CXFXJC-23
> Project: CXF XJC Utils
> Issue Type: Improvement
> Components: Maven Plugin
>Affects Versions: 3.2.1
>Reporter: Gareth Healy
>Assignee: Freeman Fang
>Priority: Minor
>
> When using java9, you see the following warnings:
> {code:java}
> [INFO] --- cxf-xjc-plugin:3.2.1:xsdtojava-tests (generate-sources) @
> dozer-core ---
> [WARNING] The POM for com.sun.xml.bind:jaxb-xjc:jar:2.2.11 is invalid,
> transitive dependencies (if any) will not be available, enable debug logging
> for more details
> [WARNING] The POM for com.sun.xml.bind:jaxb-core:jar:2.2.11 is invalid,
> transitive dependencies (if any) will not be available, enable debug logging
> for more details
> [WARNING] Failed to build parent project for
> com.sun.xml.bind.mvn:jaxb-bundles:pom:2.2.11
> [WARNING] Failed to build parent project for
> com.sun.xml.bind:jaxb-xjc:jar:2.2.11
> [WARNING] Invalid POM for com.sun.xml.bind:jaxb-xjc:jar:2.2.11, transitive
> dependencies (if any) will not be available, enable debug logging for more
> details
> [WARNING] Failed to build parent project for
> com.sun.xml.bind.mvn:jaxb-bundles:pom:2.2.11
> [WARNING] Failed to build parent project for
> com.sun.xml.bind:jaxb-core:jar:2.2.11
> [WARNING] Invalid POM for com.sun.xml.bind:jaxb-core:jar:2.2.11, transitive
> dependencies (if any) will not be available, enable debug logging for more
> details
> [WARNING] Failed to build parent project for
> com.sun.xml.bind.mvn:jaxb-bundles:pom:2.2.11
> [WARNING] Failed to build parent project for
> com.sun.xml.bind:jaxb-impl:jar:2.2.11
> [WARNING] Invalid POM for com.sun.xml.bind:jaxb-impl:jar:2.2.11, transitive
> dependencies (if any) will not be available, enable debug logging for more
> details{code}
>
> I think, this would be solved by moving to jaxb 2.3.0
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CXFXJC-23) jaxb dependancy warnings when compiling against java9
[
https://issues.apache.org/jira/browse/CXFXJC-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang resolved CXFXJC-23.
Resolution: Fixed
> jaxb dependancy warnings when compiling against java9
> -
>
> Key: CXFXJC-23
> URL: https://issues.apache.org/jira/browse/CXFXJC-23
> Project: CXF XJC Utils
> Issue Type: Improvement
> Components: Maven Plugin
>Affects Versions: 3.2.1
>Reporter: Gareth Healy
>Assignee: Freeman Fang
>Priority: Minor
>
> When using java9, you see the following warnings:
> {code:java}
> [INFO] --- cxf-xjc-plugin:3.2.1:xsdtojava-tests (generate-sources) @
> dozer-core ---
> [WARNING] The POM for com.sun.xml.bind:jaxb-xjc:jar:2.2.11 is invalid,
> transitive dependencies (if any) will not be available, enable debug logging
> for more details
> [WARNING] The POM for com.sun.xml.bind:jaxb-core:jar:2.2.11 is invalid,
> transitive dependencies (if any) will not be available, enable debug logging
> for more details
> [WARNING] Failed to build parent project for
> com.sun.xml.bind.mvn:jaxb-bundles:pom:2.2.11
> [WARNING] Failed to build parent project for
> com.sun.xml.bind:jaxb-xjc:jar:2.2.11
> [WARNING] Invalid POM for com.sun.xml.bind:jaxb-xjc:jar:2.2.11, transitive
> dependencies (if any) will not be available, enable debug logging for more
> details
> [WARNING] Failed to build parent project for
> com.sun.xml.bind.mvn:jaxb-bundles:pom:2.2.11
> [WARNING] Failed to build parent project for
> com.sun.xml.bind:jaxb-core:jar:2.2.11
> [WARNING] Invalid POM for com.sun.xml.bind:jaxb-core:jar:2.2.11, transitive
> dependencies (if any) will not be available, enable debug logging for more
> details
> [WARNING] Failed to build parent project for
> com.sun.xml.bind.mvn:jaxb-bundles:pom:2.2.11
> [WARNING] Failed to build parent project for
> com.sun.xml.bind:jaxb-impl:jar:2.2.11
> [WARNING] Invalid POM for com.sun.xml.bind:jaxb-impl:jar:2.2.11, transitive
> dependencies (if any) will not be available, enable debug logging for more
> details{code}
>
> I think, this would be solved by moving to jaxb 2.3.0
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (CXF-8052) Cannot set JAXB schema compiler options
[
https://issues.apache.org/jira/browse/CXF-8052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang reassigned CXF-8052:
-
Assignee: Freeman Fang
> Cannot set JAXB schema compiler options
> ---
>
> Key: CXF-8052
> URL: https://issues.apache.org/jira/browse/CXF-8052
> Project: CXF
> Issue Type: Bug
> Components: Simple Frontend
>Affects Versions: 3.3.2
> Environment: OpenJDK 12
>Reporter: Ranjit Vadakkan
>Assignee: Freeman Fang
>Priority: Blocker
> Time Spent: 10m
> Remaining Estimate: 0h
>
> JAXB generates an is-prefix getter for a boolean data type in my WSDL instead
> of a get-prefix getter, see
> [https://www.ibm.com/developerworks/community/blogs/Dougclectica/entry/JAXB_with_Java_7_and_xs_boolean?lang=en]
>
> The workaround is simple - pass the "-enableIntrospection" argument to the
> JAXB compiler. Unfortunately, CXF fails with this error -
> {quote}Caused by: com.sun.tools.xjc.BadCommandLineException: grammar is not
> specified
> at com.sun.tools.xjc.Options.parseArguments(Options.java:861)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> ...
> {quote}
>
> The test code to reproduce this is very simple -
> {quote}JaxWsDynamicClientFactory factory =
> JaxWsDynamicClientFactory.newInstance();
> String[] schemaCompilerOptions = new String[] \{"-enableIntrospection"};
> factory.setSchemaCompilerOptions(schemaCompilerOptions);
> Client client = factory.createClient();
> {quote}
>
> The error occurs in
> org.apache.cxf.endpoint.dynamic.DynamicClientFactory#createSchemaCompiler
> {quote}if (schemaCompilerOptions != null && schemaCompilerOptions.length > 0)
> {
> compiler.getOptions().parseArguments(schemaCompilerOptions);
> }
> {quote}
>
> parseArguments expects the XML Schemas to have already been added to the
> compiler.getOptions() object, but in DynamicClientFactory, the schemas are
> added after parseArguments is called, which is why parseArguments spits out
> the "grammar is not specified" error.
> This can be fixed in a couple of ways -
> # Add a dummy schema to the compiler.getOptions() object before invoking
> parseArguments on it.
> # Relocate the call to parseArguments after the schemas have been added to
> the compiler.getOptions() object.
>
> Option 1 is used by
> org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding in its
> initialize() method -
> {quote}// keep parseArguments happy, supply dummy required command-line opts
> opts.addGrammar(new InputSource("null"));
> opts.parseArguments(args.toArray(new String[0]));
> {quote}
>
> Personally, I prefer relocating the call instead of adding a dummy schema.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CXF-8049) org.apache.cxf.common.util.Compiler fails to compile if a classpath entry contains spaces
[
https://issues.apache.org/jira/browse/CXF-8049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang resolved CXF-8049.
---
Resolution: Fixed
Fix Version/s: 3.2.10
3.3.3
patch applied on behalf of Ranjit Vadakkan with thanks!
> org.apache.cxf.common.util.Compiler fails to compile if a classpath entry
> contains spaces
> -
>
> Key: CXF-8049
> URL: https://issues.apache.org/jira/browse/CXF-8049
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.3.2
> Environment: IntelliJ IDEA 2019.1.2 (Ultimate Edition)
> Build #IU-191.7141.44, built on May 7, 2019
> JRE: 1.8.0_202-release-1483-b49 x86_64
> JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
> macOS 10.14.3
>
> Using OpenJDK 12 to run/debug my project
>Reporter: Ranjit Vadakkan
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 3.3.3, 3.2.10
>
> Attachments: workaround.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I'm trying to create a dynamic client using
> [https://github.com/apache/cxf/blob/master/distribution/src/main/release/samples/wsdl_first_dynamic_client/src/main/java/demo/hw/client/ComplexClient.java]
> as a template.
>
> When I try to debug this, I intermittently get a (javac compile) failure
> where
> org.apache.cxf.common.util.Compiler.internalCompile fails because the
> classpath contains an entry with spaces. In my case, this entry with a space
> was a jar from the IntelliJ installation path -
> {{/Applications/IntelliJ IDEA.app/Contents/lib/idea_rt.jar}}
> After spending some time debugging it, I could [^workaround.txt] the problem
> by escaping the said entry from the calling code (ComplexClient.java), but
> maybe this should be done inside org.apache.cxf.common.util.Compiler.addArgs
> where the classpath is being retrieved from the system property
> 'java.class.path'.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXFXJC-34) Code generation breaks on boolean restricted to 0 or 1
[ https://issues.apache.org/jira/browse/CXFXJC-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849741#comment-16849741 ] Freeman Fang commented on CXFXJC-34: I believe this is the same root cause as CXF-7998 And actually this is a jaxb 2.3.x bug, which is fixed by https://github.com/eclipse-ee4j/jaxb-ri/issues/1287 and we need to wait for a new jaxb(2.3.3) release which would contain this fix. Freeman > Code generation breaks on boolean restricted to 0 or 1 > -- > > Key: CXFXJC-34 > URL: https://issues.apache.org/jira/browse/CXFXJC-34 > Project: CXF XJC Utils > Issue Type: Bug > Components: Maven Plugin >Affects Versions: 3.3.0 >Reporter: Ruud de Jong >Assignee: Freeman Fang >Priority: Major > > Exception in thread "main" java.lang.InternalError: Unable to load source > code of com.sun.tools.xjc.runtime.ZeroOneBooleanAdapter as a resource > at > com.sun.codemodel.fmt.JStaticJavaFile$ResourceLoader.getResourceAsStream(JStaticJavaFile.java:234) > at com.sun.codemodel.fmt.JStaticJavaFile.build(JStaticJavaFile.java:84) > at com.sun.codemodel.JPackage.build(JPackage.java:446) > at com.sun.codemodel.JCodeModel.build(JCodeModel.java:327) > at com.sun.codemodel.JCodeModel.build(JCodeModel.java:317) > at org.apache.cxf.maven_plugin.XSDToJavaRunner.run(XSDToJavaRunner.java:226) > at > org.apache.cxf.maven_plugin.AbstractXSDToJavaMojo.run(AbstractXSDToJavaMojo.java:368) > at > org.apache.cxf.maven_plugin.AbstractXSDToJavaMojo.execute(AbstractXSDToJavaMojo.java:276) > at org.apache.cxf.maven_plugin.XSDToJavaMojo.execute(XSDToJavaMojo.java:41) > > This happens in 3.3.0 (not in 3.2.3). > > The XSD uses this definition: > > > > > > > > which triggers a special piece of code within JCodeModel of jaxb-xjc and > tries to copy some Java source file from classpath. > Apparently, this has changed from 3.2.3 to 3.3.0 and does not work properly > anymore within the Maven plugin scope. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CXFXJC-34) Code generation breaks on boolean restricted to 0 or 1
[ https://issues.apache.org/jira/browse/CXFXJC-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned CXFXJC-34: -- Assignee: Freeman Fang > Code generation breaks on boolean restricted to 0 or 1 > -- > > Key: CXFXJC-34 > URL: https://issues.apache.org/jira/browse/CXFXJC-34 > Project: CXF XJC Utils > Issue Type: Bug > Components: Maven Plugin >Affects Versions: 3.3.0 >Reporter: Ruud de Jong >Assignee: Freeman Fang >Priority: Major > > Exception in thread "main" java.lang.InternalError: Unable to load source > code of com.sun.tools.xjc.runtime.ZeroOneBooleanAdapter as a resource > at > com.sun.codemodel.fmt.JStaticJavaFile$ResourceLoader.getResourceAsStream(JStaticJavaFile.java:234) > at com.sun.codemodel.fmt.JStaticJavaFile.build(JStaticJavaFile.java:84) > at com.sun.codemodel.JPackage.build(JPackage.java:446) > at com.sun.codemodel.JCodeModel.build(JCodeModel.java:327) > at com.sun.codemodel.JCodeModel.build(JCodeModel.java:317) > at org.apache.cxf.maven_plugin.XSDToJavaRunner.run(XSDToJavaRunner.java:226) > at > org.apache.cxf.maven_plugin.AbstractXSDToJavaMojo.run(AbstractXSDToJavaMojo.java:368) > at > org.apache.cxf.maven_plugin.AbstractXSDToJavaMojo.execute(AbstractXSDToJavaMojo.java:276) > at org.apache.cxf.maven_plugin.XSDToJavaMojo.execute(XSDToJavaMojo.java:41) > > This happens in 3.3.0 (not in 3.2.3). > > The XSD uses this definition: > > > > > > > > which triggers a special piece of code within JCodeModel of jaxb-xjc and > tries to copy some Java source file from classpath. > Apparently, this has changed from 3.2.3 to 3.3.0 and does not work properly > anymore within the Maven plugin scope. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CXF-8049) org.apache.cxf.common.util.Compiler fails to compile if a classpath entry contains spaces
[
https://issues.apache.org/jira/browse/CXF-8049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang reassigned CXF-8049:
-
Assignee: Freeman Fang
> org.apache.cxf.common.util.Compiler fails to compile if a classpath entry
> contains spaces
> -
>
> Key: CXF-8049
> URL: https://issues.apache.org/jira/browse/CXF-8049
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.3.2
> Environment: IntelliJ IDEA 2019.1.2 (Ultimate Edition)
> Build #IU-191.7141.44, built on May 7, 2019
> JRE: 1.8.0_202-release-1483-b49 x86_64
> JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
> macOS 10.14.3
>
> Using OpenJDK 12 to run/debug my project
>Reporter: Ranjit Vadakkan
>Assignee: Freeman Fang
>Priority: Major
> Attachments: workaround.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I'm trying to create a dynamic client using
> [https://github.com/apache/cxf/blob/master/distribution/src/main/release/samples/wsdl_first_dynamic_client/src/main/java/demo/hw/client/ComplexClient.java]
> as a template.
>
> When I try to debug this, I intermittently get a (javac compile) failure
> where
> org.apache.cxf.common.util.Compiler.internalCompile fails because the
> classpath contains an entry with spaces. In my case, this entry with a space
> was a jar from the IntelliJ installation path -
> {{/Applications/IntelliJ IDEA.app/Contents/lib/idea_rt.jar}}
> After spending some time debugging it, I could [^workaround.txt] the problem
> by escaping the said entry from the calling code (ComplexClient.java), but
> maybe this should be done inside org.apache.cxf.common.util.Compiler.addArgs
> where the classpath is being retrieved from the system property
> 'java.class.path'.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-8049) org.apache.cxf.common.util.Compiler fails to compile if a classpath entry contains spaces
[
https://issues.apache.org/jira/browse/CXF-8049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849192#comment-16849192
]
Freeman Fang commented on CXF-8049:
---
Hi [~rvadakkan],
Thanks for reporting this issue!
Are you keen to send a PR?
Freeman
> org.apache.cxf.common.util.Compiler fails to compile if a classpath entry
> contains spaces
> -
>
> Key: CXF-8049
> URL: https://issues.apache.org/jira/browse/CXF-8049
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.3.2
> Environment: IntelliJ IDEA 2019.1.2 (Ultimate Edition)
> Build #IU-191.7141.44, built on May 7, 2019
> JRE: 1.8.0_202-release-1483-b49 x86_64
> JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
> macOS 10.14.3
>
> Using OpenJDK 12 to run/debug my project
>Reporter: Ranjit Vadakkan
>Priority: Major
> Attachments: workaround.txt
>
>
> I'm trying to create a dynamic client using
> [https://github.com/apache/cxf/blob/master/distribution/src/main/release/samples/wsdl_first_dynamic_client/src/main/java/demo/hw/client/ComplexClient.java]
> as a template.
>
> When I try to debug this, I intermittently get a (javac compile) failure
> where
> org.apache.cxf.common.util.Compiler.internalCompile fails because the
> classpath contains an entry with spaces. In my case, this entry with a space
> was a jar from the IntelliJ installation path -
> {{/Applications/IntelliJ IDEA.app/Contents/lib/idea_rt.jar}}
> After spending some time debugging it, I could [^workaround.txt] the problem
> by escaping the said entry from the calling code (ComplexClient.java), but
> maybe this should be done inside org.apache.cxf.common.util.Compiler.addArgs
> where the classpath is being retrieved from the system property
> 'java.class.path'.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-8041) Error resolving relative XSD Schema on Tomcat
[
https://issues.apache.org/jira/browse/CXF-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846918#comment-16846918
]
Freeman Fang commented on CXF-8041:
---
Hi [~netmikey],
Thanks for the feedback! Please see latest commit here
https://github.com/apache/cxf/commit/513f83ecbadcae805d541ee246bf1ae0e80fda53
Let me know if this works for you.
Cheers
Freeman
> Error resolving relative XSD Schema on Tomcat
> -
>
> Key: CXF-8041
> URL: https://issues.apache.org/jira/browse/CXF-8041
> Project: CXF
> Issue Type: Bug
> Components: Core, Transports
>Affects Versions: 3.3.1
>Reporter: Mike M.
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 3.3.3, 3.2.10
>
> Attachments: cxf-tomcat-resource-resolver.zip
>
>
> We found an issue in a CXF JAX-WS project when running in WSDL-first mode
> with schema-validation enabled on Tomcat. The WSDL references an external XSD
> schema using a relative path. The WSDL and XSD are bundled with the
> application and are present on the classpath.
> *Expectation:*
> The XSD should be resolved successfully and schema validation should work.
> *Actual behavior:*
> * The resource lookup runs through CXF {{EndpointReferenceUtils}}'
> {{SchemaLSResourceResolver}}. This one runs through multiple strategies for
> resolving the imported XSD URL to a resource. One of them (currently around
> line 150) is an attempt to ask a {{ResourceManager}} for the URL.
> * In a Servlet context, this will be handled by CXF's
> {{ServletContextResourceResolver}}. This one (currently starting around line
> 82) will ask the actual {{ServletContext}} for the URL. While doing so, it
> will catch and ignore {{MalformedURLException}} s as documented in the
> {{ServletContext}} interface as well as {{URISyntaxException}} s (probably
> precautionary).
> * Entering Tomcat's implementation: the call will go through Tomcat's
> {{ApplicationContext}} and end up in the {{StandardRoot}}'s
> {{#validate(String)}} method. Unfortunately, while validating the provided
> URL, this one throws {{IllegalArgumentException}} s instead of just returning
> {{null}}. In our case, since we resolve the XSD schema relative to the WSDL
> and need to go up some levels (../../) from it, Tomcat thinks we're trying to
> escape the application context and will trigger the
> {{IllegalArgumentException}}.
> * Unfortunately though, this exception never gets caught and propagates up
> the stack back to CXF's {{SchemaLSResourceResolver#resolveResource}}. This
> method had several strategies for resolving resources, remember? The annoying
> part is: we didn't even need that particular ServletContext strategy for our
> XSD, and one of the other methods (classpath lookup) would have resolved the
> XSD just fine, *had the ServletContext lookup not thrown the
> {{IllegalArgumentException}}*. That uncaught exception however, breaks the
> lookup entirely.
> *Solution proposal:*
> I think the least invasive solution would be for
> {{ServletContextResourceResolver}} to additionally catch
> {{IllegalArgumentException}} when calling {{ServletContext#getResource}}. It
> already catches {{URISyntaxException}} even though that one isn't documented
> by the {{ServletContext}} API. Catching an exception that basically says
> "Hey, this argument isn't valid" would be semantically similar imho.
> A more drastic approach would be catching all {{RuntimeException}} s from the
> Servlet Container in order to fulfill {{ResourceResolver#resolve}}'s
> contract, namely: "@return an instance of the resource or null if the
> resource cannot be resolved".
> *Reproducing the error:*
> I attached a sample project to this ticket that reproduces the issue. Make
> sure to follow the instructions in its README.md.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CXF-8041) Error resolving relative XSD Schema on Tomcat
[
https://issues.apache.org/jira/browse/CXF-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang resolved CXF-8041.
---
Resolution: Fixed
Fix Version/s: 3.2.10
3.3.3
> Error resolving relative XSD Schema on Tomcat
> -
>
> Key: CXF-8041
> URL: https://issues.apache.org/jira/browse/CXF-8041
> Project: CXF
> Issue Type: Bug
> Components: Core, Transports
>Affects Versions: 3.3.1
>Reporter: Mike M.
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 3.3.3, 3.2.10
>
> Attachments: cxf-tomcat-resource-resolver.zip
>
>
> We found an issue in a CXF JAX-WS project when running in WSDL-first mode
> with schema-validation enabled on Tomcat. The WSDL references an external XSD
> schema using a relative path. The WSDL and XSD are bundled with the
> application and are present on the classpath.
> *Expectation:*
> The XSD should be resolved successfully and schema validation should work.
> *Actual behavior:*
> * The resource lookup runs through CXF {{EndpointReferenceUtils}}'
> {{SchemaLSResourceResolver}}. This one runs through multiple strategies for
> resolving the imported XSD URL to a resource. One of them (currently around
> line 150) is an attempt to ask a {{ResourceManager}} for the URL.
> * In a Servlet context, this will be handled by CXF's
> {{ServletContextResourceResolver}}. This one (currently starting around line
> 82) will ask the actual {{ServletContext}} for the URL. While doing so, it
> will catch and ignore {{MalformedURLException}} s as documented in the
> {{ServletContext}} interface as well as {{URISyntaxException}} s (probably
> precautionary).
> * Entering Tomcat's implementation: the call will go through Tomcat's
> {{ApplicationContext}} and end up in the {{StandardRoot}}'s
> {{#validate(String)}} method. Unfortunately, while validating the provided
> URL, this one throws {{IllegalArgumentException}} s instead of just returning
> {{null}}. In our case, since we resolve the XSD schema relative to the WSDL
> and need to go up some levels (../../) from it, Tomcat thinks we're trying to
> escape the application context and will trigger the
> {{IllegalArgumentException}}.
> * Unfortunately though, this exception never gets caught and propagates up
> the stack back to CXF's {{SchemaLSResourceResolver#resolveResource}}. This
> method had several strategies for resolving resources, remember? The annoying
> part is: we didn't even need that particular ServletContext strategy for our
> XSD, and one of the other methods (classpath lookup) would have resolved the
> XSD just fine, *had the ServletContext lookup not thrown the
> {{IllegalArgumentException}}*. That uncaught exception however, breaks the
> lookup entirely.
> *Solution proposal:*
> I think the least invasive solution would be for
> {{ServletContextResourceResolver}} to additionally catch
> {{IllegalArgumentException}} when calling {{ServletContext#getResource}}. It
> already catches {{URISyntaxException}} even though that one isn't documented
> by the {{ServletContext}} API. Catching an exception that basically says
> "Hey, this argument isn't valid" would be semantically similar imho.
> A more drastic approach would be catching all {{RuntimeException}} s from the
> Servlet Container in order to fulfill {{ResourceResolver#resolve}}'s
> contract, namely: "@return an instance of the resource or null if the
> resource cannot be resolved".
> *Reproducing the error:*
> I attached a sample project to this ticket that reproduces the issue. Make
> sure to follow the instructions in its README.md.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (CXF-8041) Error resolving relative XSD Schema on Tomcat
[
https://issues.apache.org/jira/browse/CXF-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang reassigned CXF-8041:
-
Assignee: Freeman Fang
> Error resolving relative XSD Schema on Tomcat
> -
>
> Key: CXF-8041
> URL: https://issues.apache.org/jira/browse/CXF-8041
> Project: CXF
> Issue Type: Bug
> Components: Core, Transports
>Affects Versions: 3.3.1
>Reporter: Mike M.
>Assignee: Freeman Fang
>Priority: Major
> Attachments: cxf-tomcat-resource-resolver.zip
>
>
> We found an issue in a CXF JAX-WS project when running in WSDL-first mode
> with schema-validation enabled on Tomcat. The WSDL references an external XSD
> schema using a relative path. The WSDL and XSD are bundled with the
> application and are present on the classpath.
> *Expectation:*
> The XSD should be resolved successfully and schema validation should work.
> *Actual behavior:*
> * The resource lookup runs through CXF {{EndpointReferenceUtils}}'
> {{SchemaLSResourceResolver}}. This one runs through multiple strategies for
> resolving the imported XSD URL to a resource. One of them (currently around
> line 150) is an attempt to ask a {{ResourceManager}} for the URL.
> * In a Servlet context, this will be handled by CXF's
> {{ServletContextResourceResolver}}. This one (currently starting around line
> 82) will ask the actual {{ServletContext}} for the URL. While doing so, it
> will catch and ignore {{MalformedURLException}} s as documented in the
> {{ServletContext}} interface as well as {{URISyntaxException}} s (probably
> precautionary).
> * Entering Tomcat's implementation: the call will go through Tomcat's
> {{ApplicationContext}} and end up in the {{StandardRoot}}'s
> {{#validate(String)}} method. Unfortunately, while validating the provided
> URL, this one throws {{IllegalArgumentException}} s instead of just returning
> {{null}}. In our case, since we resolve the XSD schema relative to the WSDL
> and need to go up some levels (../../) from it, Tomcat thinks we're trying to
> escape the application context and will trigger the
> {{IllegalArgumentException}}.
> * Unfortunately though, this exception never gets caught and propagates up
> the stack back to CXF's {{SchemaLSResourceResolver#resolveResource}}. This
> method had several strategies for resolving resources, remember? The annoying
> part is: we didn't even need that particular ServletContext strategy for our
> XSD, and one of the other methods (classpath lookup) would have resolved the
> XSD just fine, *had the ServletContext lookup not thrown the
> {{IllegalArgumentException}}*. That uncaught exception however, breaks the
> lookup entirely.
> *Solution proposal:*
> I think the least invasive solution would be for
> {{ServletContextResourceResolver}} to additionally catch
> {{IllegalArgumentException}} when calling {{ServletContext#getResource}}. It
> already catches {{URISyntaxException}} even though that one isn't documented
> by the {{ServletContext}} API. Catching an exception that basically says
> "Hey, this argument isn't valid" would be semantically similar imho.
> A more drastic approach would be catching all {{RuntimeException}} s from the
> Servlet Container in order to fulfill {{ResourceResolver#resolve}}'s
> contract, namely: "@return an instance of the resource or null if the
> resource cannot be resolved".
> *Reproducing the error:*
> I attached a sample project to this ticket that reproduces the issue. Make
> sure to follow the instructions in its README.md.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CXF-8045) Disable HTTP TRACE method on CXF http-undertow transport
[ https://issues.apache.org/jira/browse/CXF-8045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-8045. --- Resolution: Fixed Fix Version/s: 3.2.10 3.3.3 > Disable HTTP TRACE method on CXF http-undertow transport > > > Key: CXF-8045 > URL: https://issues.apache.org/jira/browse/CXF-8045 > Project: CXF > Issue Type: Improvement >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > Fix For: 3.3.3, 3.2.10 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-8045) Disable HTTP TRACE method on CXF http-undertow transport
Freeman Fang created CXF-8045: - Summary: Disable HTTP TRACE method on CXF http-undertow transport Key: CXF-8045 URL: https://issues.apache.org/jira/browse/CXF-8045 Project: CXF Issue Type: Improvement Reporter: Freeman Fang -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CXF-8045) Disable HTTP TRACE method on CXF http-undertow transport
[ https://issues.apache.org/jira/browse/CXF-8045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned CXF-8045: - Assignee: Freeman Fang > Disable HTTP TRACE method on CXF http-undertow transport > > > Key: CXF-8045 > URL: https://issues.apache.org/jira/browse/CXF-8045 > Project: CXF > Issue Type: Improvement >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CXF-8013) Can't tell CXF to use a custom certstore for SSL certificate check
[
https://issues.apache.org/jira/browse/CXF-8013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang reassigned CXF-8013:
-
Assignee: Colm O hEigeartaigh (was: Freeman Fang)
> Can't tell CXF to use a custom certstore for SSL certificate check
> --
>
> Key: CXF-8013
> URL: https://issues.apache.org/jira/browse/CXF-8013
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.6
>Reporter: Michel SAUMON
>Assignee: Colm O hEigeartaigh
>Priority: Major
>
> In my cxf.xml, I declared a custom certstore because my server's certificate
> is not considered valid by the JDK:
> {code:java}
> http://www.springframework.org/schema/beans;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xmlns:sec="http://cxf.apache.org/configuration/security;
> xmlns:http="http://cxf.apache.org/transports/http/configuration;
> xmlns:jaxws="http://java.sun.com/xml/ns/jaxws;
> xsi:schemaLocation="
> http://cxf.apache.org/configuration/security
> http://cxf.apache.org/schemas/configuration/security.xsd
> http://cxf.apache.org/transports/http/configuration
> http://cxf.apache.org/schemas/configuration/http-conf.xsd
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-2.0.xsd;>
>
> http://myservice.xx/comweb/}ComWebSoap.http-conduit;>
>
>
>
>
>
>
>
>
>
>
> {code}
> But CXF does not take this config.
> I have still the error telling the cert is not valid :
> {code:java}
> javax.xml.ws.WebServiceException:
> org.apache.cxf.service.factory.ServiceConstructionException: Failed to create
> service.
> at org.apache.cxf.jaxws.ServiceImpl.initialize(ServiceImpl.java:163)
> at org.apache.cxf.jaxws.ServiceImpl.(ServiceImpl.java:129)
> at
> org.apache.cxf.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:82)
> at javax.xml.ws.Service.(Service.java:77)
> at xx.mysoapclient.ComWeb.(ComWeb.java:40)
> at xx.mysoapclient.ComWebTest.getComWebSoap(ComWebTest.java:101)
> at xx.mysoapclient.ComWebTest.testGetReporting(ComWebTest.java:136)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:89)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:41)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:541)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:763)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:463)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:209)
> Caused by: org.apache.cxf.service.factory.ServiceConstructionException:
> Failed to create service.
> at
> org.apache.cxf.wsdl11.WSDLServiceFactory.(WSDLServiceFactory.java:87)
> at org.apache.cxf.jaxws.ServiceImpl.initializePorts(ServiceImpl.java:218)
> at org.apache.cxf.jaxws.ServiceImpl.initialize(ServiceImpl.java:161)
> ... 25 more
> Caused by: javax.wsdl.WSDLException: WSDLException: faultCode=PARSER_ERROR:
> Problem parsing 'https://ctrl-talend-s95/COM_WEB/ComWeb.asmx?wsdl'.:
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
> at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(WSDLReaderImpl.java:2198)
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2390)
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2422)
> at
> org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:238)
> at
>
[jira] [Commented] (CXF-8013) Can't tell CXF to use a custom certstore for SSL certificate check
[
https://issues.apache.org/jira/browse/CXF-8013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821009#comment-16821009
]
Freeman Fang commented on CXF-8013:
---
Ah, thanks [~coheigea]!
> Can't tell CXF to use a custom certstore for SSL certificate check
> --
>
> Key: CXF-8013
> URL: https://issues.apache.org/jira/browse/CXF-8013
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.6
>Reporter: Michel SAUMON
>Assignee: Freeman Fang
>Priority: Major
>
> In my cxf.xml, I declared a custom certstore because my server's certificate
> is not considered valid by the JDK:
> {code:java}
> http://www.springframework.org/schema/beans;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xmlns:sec="http://cxf.apache.org/configuration/security;
> xmlns:http="http://cxf.apache.org/transports/http/configuration;
> xmlns:jaxws="http://java.sun.com/xml/ns/jaxws;
> xsi:schemaLocation="
> http://cxf.apache.org/configuration/security
> http://cxf.apache.org/schemas/configuration/security.xsd
> http://cxf.apache.org/transports/http/configuration
> http://cxf.apache.org/schemas/configuration/http-conf.xsd
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-2.0.xsd;>
>
> http://myservice.xx/comweb/}ComWebSoap.http-conduit;>
>
>
>
>
>
>
>
>
>
>
> {code}
> But CXF does not take this config.
> I have still the error telling the cert is not valid :
> {code:java}
> javax.xml.ws.WebServiceException:
> org.apache.cxf.service.factory.ServiceConstructionException: Failed to create
> service.
> at org.apache.cxf.jaxws.ServiceImpl.initialize(ServiceImpl.java:163)
> at org.apache.cxf.jaxws.ServiceImpl.(ServiceImpl.java:129)
> at
> org.apache.cxf.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:82)
> at javax.xml.ws.Service.(Service.java:77)
> at xx.mysoapclient.ComWeb.(ComWeb.java:40)
> at xx.mysoapclient.ComWebTest.getComWebSoap(ComWebTest.java:101)
> at xx.mysoapclient.ComWebTest.testGetReporting(ComWebTest.java:136)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:89)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:41)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:541)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:763)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:463)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:209)
> Caused by: org.apache.cxf.service.factory.ServiceConstructionException:
> Failed to create service.
> at
> org.apache.cxf.wsdl11.WSDLServiceFactory.(WSDLServiceFactory.java:87)
> at org.apache.cxf.jaxws.ServiceImpl.initializePorts(ServiceImpl.java:218)
> at org.apache.cxf.jaxws.ServiceImpl.initialize(ServiceImpl.java:161)
> ... 25 more
> Caused by: javax.wsdl.WSDLException: WSDLException: faultCode=PARSER_ERROR:
> Problem parsing 'https://ctrl-talend-s95/COM_WEB/ComWeb.asmx?wsdl'.:
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
> at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(WSDLReaderImpl.java:2198)
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2390)
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2422)
> at
> org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:238)
> at
>
[jira] [Commented] (CXF-8013) Can't tell CXF to use a custom certstore for SSL certificate check
[
https://issues.apache.org/jira/browse/CXF-8013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814968#comment-16814968
]
Freeman Fang commented on CXF-8013:
---
Hi [~michelsaumon]
Could you please append a runnable testcase?
Thanks!
Freeman
> Can't tell CXF to use a custom certstore for SSL certificate check
> --
>
> Key: CXF-8013
> URL: https://issues.apache.org/jira/browse/CXF-8013
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.6
>Reporter: Michel SAUMON
>Assignee: Freeman Fang
>Priority: Major
>
> In my cxf.xml, I declared a custom certstore because my server's certificate
> is not considered valid by the JDK:
> {code:java}
> http://www.springframework.org/schema/beans;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xmlns:sec="http://cxf.apache.org/configuration/security;
> xmlns:http="http://cxf.apache.org/transports/http/configuration;
> xmlns:jaxws="http://java.sun.com/xml/ns/jaxws;
> xsi:schemaLocation="
> http://cxf.apache.org/configuration/security
> http://cxf.apache.org/schemas/configuration/security.xsd
> http://cxf.apache.org/transports/http/configuration
> http://cxf.apache.org/schemas/configuration/http-conf.xsd
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-2.0.xsd;>
>
> http://myservice.xx/comweb/}ComWebSoap.http-conduit;>
>
>
>
>
>
>
>
>
>
>
> {code}
> But CXF does not take this config.
> I have still the error telling the cert is not valid :
> {code:java}
> javax.xml.ws.WebServiceException:
> org.apache.cxf.service.factory.ServiceConstructionException: Failed to create
> service.
> at org.apache.cxf.jaxws.ServiceImpl.initialize(ServiceImpl.java:163)
> at org.apache.cxf.jaxws.ServiceImpl.(ServiceImpl.java:129)
> at
> org.apache.cxf.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:82)
> at javax.xml.ws.Service.(Service.java:77)
> at xx.mysoapclient.ComWeb.(ComWeb.java:40)
> at xx.mysoapclient.ComWebTest.getComWebSoap(ComWebTest.java:101)
> at xx.mysoapclient.ComWebTest.testGetReporting(ComWebTest.java:136)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:89)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:41)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:541)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:763)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:463)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:209)
> Caused by: org.apache.cxf.service.factory.ServiceConstructionException:
> Failed to create service.
> at
> org.apache.cxf.wsdl11.WSDLServiceFactory.(WSDLServiceFactory.java:87)
> at org.apache.cxf.jaxws.ServiceImpl.initializePorts(ServiceImpl.java:218)
> at org.apache.cxf.jaxws.ServiceImpl.initialize(ServiceImpl.java:161)
> ... 25 more
> Caused by: javax.wsdl.WSDLException: WSDLException: faultCode=PARSER_ERROR:
> Problem parsing 'https://ctrl-talend-s95/COM_WEB/ComWeb.asmx?wsdl'.:
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
> at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(WSDLReaderImpl.java:2198)
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2390)
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2422)
> at
>
[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=16814044#comment-16814044 ] Freeman Fang commented on CXF-7953: --- Hi [~zhfeng], We don't have to revert when maven with plexus-classworlds 2.6 is available, but we can revert this change to re-generate package-info.java when maven can support it OOTB. Cheers Freeman > 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-7953) make corba binding working with JDK11
[ https://issues.apache.org/jira/browse/CXF-7953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16812979#comment-16812979 ] Freeman Fang commented on CXF-7953: --- Hi [~dkulp], Yup, your commit works perfectly. Now we don't need to change the maven for the CI build machine. Thanks! Freeman > 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-7953) make corba binding working with JDK11
[ https://issues.apache.org/jira/browse/CXF-7953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16812856#comment-16812856 ] Freeman Fang commented on CXF-7953: --- [~dkulp] Ah, good idea. I will try that way. Cheers Freeman > 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] [Assigned] (CXF-8013) Can't tell CXF to use a custom certstore for SSL certificate check
[
https://issues.apache.org/jira/browse/CXF-8013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang reassigned CXF-8013:
-
Assignee: Freeman Fang
> Can't tell CXF to use a custom certstore for SSL certificate check
> --
>
> Key: CXF-8013
> URL: https://issues.apache.org/jira/browse/CXF-8013
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.6
>Reporter: Michel SAUMON
>Assignee: Freeman Fang
>Priority: Major
>
> In my cxf.xml, I declared a custom certstore because my server's certificate
> is not considered valid by the JDK:
> {code:java}
> http://www.springframework.org/schema/beans;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xmlns:sec="http://cxf.apache.org/configuration/security;
> xmlns:http="http://cxf.apache.org/transports/http/configuration;
> xmlns:jaxws="http://java.sun.com/xml/ns/jaxws;
> xsi:schemaLocation="
> http://cxf.apache.org/configuration/security
> http://cxf.apache.org/schemas/configuration/security.xsd
> http://cxf.apache.org/transports/http/configuration
> http://cxf.apache.org/schemas/configuration/http-conf.xsd
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-2.0.xsd;>
>
> http://myservice.xx/comweb/}ComWebSoap.http-conduit;>
>
>
>
>
>
>
>
>
>
>
> {code}
> But CXF does not take this config.
> I have still the error telling the cert is not valid :
> {code:java}
> javax.xml.ws.WebServiceException:
> org.apache.cxf.service.factory.ServiceConstructionException: Failed to create
> service.
> at org.apache.cxf.jaxws.ServiceImpl.initialize(ServiceImpl.java:163)
> at org.apache.cxf.jaxws.ServiceImpl.(ServiceImpl.java:129)
> at
> org.apache.cxf.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:82)
> at javax.xml.ws.Service.(Service.java:77)
> at xx.mysoapclient.ComWeb.(ComWeb.java:40)
> at xx.mysoapclient.ComWebTest.getComWebSoap(ComWebTest.java:101)
> at xx.mysoapclient.ComWebTest.testGetReporting(ComWebTest.java:136)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:89)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:41)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:541)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:763)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:463)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:209)
> Caused by: org.apache.cxf.service.factory.ServiceConstructionException:
> Failed to create service.
> at
> org.apache.cxf.wsdl11.WSDLServiceFactory.(WSDLServiceFactory.java:87)
> at org.apache.cxf.jaxws.ServiceImpl.initializePorts(ServiceImpl.java:218)
> at org.apache.cxf.jaxws.ServiceImpl.initialize(ServiceImpl.java:161)
> ... 25 more
> Caused by: javax.wsdl.WSDLException: WSDLException: faultCode=PARSER_ERROR:
> Problem parsing 'https://ctrl-talend-s95/COM_WEB/ComWeb.asmx?wsdl'.:
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
> at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(WSDLReaderImpl.java:2198)
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2390)
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2422)
> at
> org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:238)
> at
>
