[jira] [Created] (CXF-7168) CXF WSN Publisher SOAP 1.2 Binding
Fahrettin Gökgöz created CXF-7168:
-
Summary: CXF WSN Publisher SOAP 1.2 Binding
Key: CXF-7168
URL: https://issues.apache.org/jira/browse/CXF-7168
Project: CXF
Issue Type: Improvement
Components: WS-* Components
Affects Versions: 3.1.8, 3.1.7
Environment: Windows 7
Reporter: Fahrettin Gökgöz
Priority: Critical
org.apache.cxf.wsn.client.Publisher -> SOAP 1.2 binding
Following constructor does not allow to set SOAP binding for publisher.
public Publisher(Callback callback, String address) {
this.callback = callback;
this.address = address;
if (callback == null || address == null) {
this.endpoint = null;
} else {
this.endpoint = WSNHelper.getInstance().publish(address, this);
}
}
Which can be solve in the WSNHelper with using
javax.xml.ws.Endpoint.create(String bindingId, Object implementor);
instead of
javax.xml.ws.Endpoint.create(Object implementor);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7168) CXF WSN Publisher SOAP 1.2 Binding
[
https://issues.apache.org/jira/browse/CXF-7168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15728405#comment-15728405
]
Colm O hEigeartaigh commented on CXF-7168:
--
Could you create a patch for this enhancement and attach it to the JIRA?
> CXF WSN Publisher SOAP 1.2 Binding
> --
>
> Key: CXF-7168
> URL: https://issues.apache.org/jira/browse/CXF-7168
> Project: CXF
> Issue Type: Improvement
> Components: WS-* Components
>Affects Versions: 3.1.7, 3.1.8
> Environment: Windows 7
>Reporter: Fahrettin Gökgöz
>Priority: Critical
> Labels: patch
>
> org.apache.cxf.wsn.client.Publisher -> SOAP 1.2 binding
> Following constructor does not allow to set SOAP binding for publisher.
> public Publisher(Callback callback, String address) {
> this.callback = callback;
> this.address = address;
> if (callback == null || address == null) {
> this.endpoint = null;
> } else {
> this.endpoint = WSNHelper.getInstance().publish(address, this);
> }
>}
> Which can be solve in the WSNHelper with using
> javax.xml.ws.Endpoint.create(String bindingId, Object implementor);
> instead of
> javax.xml.ws.Endpoint.create(Object implementor);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-7129) Provide an optional HTrace Logging receiver
[ https://issues.apache.org/jira/browse/CXF-7129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin updated CXF-7129: -- Description: It can be useful to add the current log statements (at the specific level) to the in-scope Span information. For example, at the moment CXF interceptors will mark the start and the stop of the given span - log statements will optionally go in between, with these log statements carrying span 'tags' (was: It can be useful to add the current log statements (at the specific level) to the in-scope Span information. For example, at the moment CXF interceptors will mark the start and the stop of the given span - log statements will optionally go in between) > Provide an optional HTrace Logging receiver > > > Key: CXF-7129 > URL: https://issues.apache.org/jira/browse/CXF-7129 > Project: CXF > Issue Type: Improvement > Components: Management >Reporter: Sergey Beryozkin >Assignee: Andriy Redko >Priority: Minor > Fix For: 3.2.0, 3.1.9 > > > It can be useful to add the current log statements (at the specific level) to > the in-scope Span information. For example, at the moment CXF interceptors > will mark the start and the stop of the given span - log statements will > optionally go in between, with these log statements carrying span 'tags' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FEDIZ-183) Support logging out in the plugins via the "wa" parameter
Colm O hEigeartaigh created FEDIZ-183: - Summary: Support logging out in the plugins via the "wa" parameter Key: FEDIZ-183 URL: https://issues.apache.org/jira/browse/FEDIZ-183 Project: CXF-Fediz Issue Type: Improvement Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 1.3.2, 1.4.0 Right now, only the Tomcat plugin supports logging out via the "wa" parameter. This task is to support this behaviour for the other plugins. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FEDIZ-183) Support logging out in the plugins via the "wa" parameter
[ https://issues.apache.org/jira/browse/FEDIZ-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved FEDIZ-183. --- Resolution: Fixed > Support logging out in the plugins via the "wa" parameter > - > > Key: FEDIZ-183 > URL: https://issues.apache.org/jira/browse/FEDIZ-183 > Project: CXF-Fediz > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 1.3.2, 1.4.0 > > > Right now, only the Tomcat plugin supports logging out via the "wa" > parameter. This task is to support this behaviour for the other plugins. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7169) Upgrade to woodstox to 5.x
Rebecca Searls created CXF-7169: --- Summary: Upgrade to woodstox to 5.x Key: CXF-7169 URL: https://issues.apache.org/jira/browse/CXF-7169 Project: CXF Issue Type: Improvement Components: Core Affects Versions: 3.1.5 Reporter: Rebecca Searls CXF's version of woodstox is quite out of date. 3rd party produces that use CXF request this dependency be updated to the more current version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7169) Upgrade to woodstox to 5.x
[ https://issues.apache.org/jira/browse/CXF-7169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15728989#comment-15728989 ] Rebecca Searls commented on CXF-7169: - woodstox apis have moved from pk org.codehaus.woodstox to com.fasterxml.woodstox > Upgrade to woodstox to 5.x > -- > > Key: CXF-7169 > URL: https://issues.apache.org/jira/browse/CXF-7169 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 3.1.5 >Reporter: Rebecca Searls > > CXF's version of woodstox is quite out of date. 3rd party produces that use > CXF request this dependency be updated to the more current version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7169) Upgrade to woodstox to 5.x
[ https://issues.apache.org/jira/browse/CXF-7169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15729053#comment-15729053 ] Sergey Beryozkin commented on CXF-7169: --- Is it really a 3.1.x-level update ? > Upgrade to woodstox to 5.x > -- > > Key: CXF-7169 > URL: https://issues.apache.org/jira/browse/CXF-7169 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 3.1.5 >Reporter: Rebecca Searls > > CXF's version of woodstox is quite out of date. 3rd party produces that use > CXF request this dependency be updated to the more current version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7169) Upgrade to woodstox to 5.x
[ https://issues.apache.org/jira/browse/CXF-7169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15729077#comment-15729077 ] Rebecca Searls commented on CXF-7169: - This is the cxf version EAP is using and is having a conflict because other components of EAP are using woodstox 5.x. I suppose cxf can be updated in a more current version and we can back port to the versions we need. > Upgrade to woodstox to 5.x > -- > > Key: CXF-7169 > URL: https://issues.apache.org/jira/browse/CXF-7169 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 3.1.5 >Reporter: Rebecca Searls > > CXF's version of woodstox is quite out of date. 3rd party produces that use > CXF request this dependency be updated to the more current version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7169) Upgrade to woodstox to 5.x
[ https://issues.apache.org/jira/browse/CXF-7169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15729084#comment-15729084 ] Rebecca Searls commented on CXF-7169: - Another reason we need it is, "One of the reasons for woodstox 5.x is JDK 9 support." > Upgrade to woodstox to 5.x > -- > > Key: CXF-7169 > URL: https://issues.apache.org/jira/browse/CXF-7169 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 3.1.5 >Reporter: Rebecca Searls > > CXF's version of woodstox is quite out of date. 3rd party produces that use > CXF request this dependency be updated to the more current version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7169) Upgrade to woodstox to 5.x
[ https://issues.apache.org/jira/browse/CXF-7169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15729206#comment-15729206 ] Daniel Kulp commented on CXF-7169: -- This is a significant dependency change and would need to be done on 3.2. > Upgrade to woodstox to 5.x > -- > > Key: CXF-7169 > URL: https://issues.apache.org/jira/browse/CXF-7169 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 3.1.5 >Reporter: Rebecca Searls > > CXF's version of woodstox is quite out of date. 3rd party produces that use > CXF request this dependency be updated to the more current version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6930) Race-Condition with JMS-transport, LoggingInInterceptor spoils the payload while logging it
[
https://issues.apache.org/jira/browse/CXF-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15731211#comment-15731211
]
Tobias Schöneberg commented on CXF-6930:
sorry, didn't get to it yet. it's high in my backlog
> Race-Condition with JMS-transport, LoggingInInterceptor spoils the payload
> while logging it
> ---
>
> Key: CXF-6930
> URL: https://issues.apache.org/jira/browse/CXF-6930
> Project: CXF
> Issue Type: Bug
> Components: JMS
>Affects Versions: 3.1.6
>Reporter: Tobias Schöneberg
>Assignee: Daniel Kulp
> Fix For: 3.1.8
>
>
> Hi,
> I think we stumbled over a problem with cxf and the JMS-transport,
> if the {{LoggingFeature}} is used to log incoming response messages.
> The problem is that sometimes, {{ClientProxyImpl.invoke(...)}} returns
> {{null}},
> but from the logged message payload, it's clear that there is a not-null
> response payload coming from the sever.
> I believe, I just figured out that it is in fact the logging of that very
> payload which causes {{ClientProxyImpl.invoke(...)}} to return {{null}}.
> How?
> There is a race between the actual "client thread" which waited for the
> server's response
> (i.e. {{exchange.wait()}} in {{JMSConduit.sendAndReceiveMessage(...)}} )
> until notified by the ActiveMQ Session Task thread
> (i.e. {{exchange.notifyAll()}} in {{JMSConduit.processReplyMessage(...)}} )
> one one side and the ActiveMQ Session Task thread itself on the other side.
> Once the client thread is notified, it goes on with {{preProcessResult(...)}}
> and {{handleResponse(...)}} and somewhere in there the message's
> {{ByteArrayStream}} is read and the return object is created.
> However, at the same time, back in the ActiveMQ thread, the interceptor chain
> is run.
> In my case it contains the {{LoggingInInterceptor}} which accesses the
> message's *same* {{ByteArrayInputStream}}, in the method
> {{LoggingInInterceptor.logInputStream(...)}} ).
> Now, in {{logInputStream(...)}}, we have
> {code:java}
> IOUtils.copyAtLeast(bis, bos, limit == -1 ? Integer.MAX_VALUE : limit);
> bos.flush();
> bis = new SequenceInputStream(bos.getInputStream(), bis);
> // restore the delegating input stream or the input stream
> if (is instanceof DelegatingInputStream) {
> ((DelegatingInputStream)is).setInputStream(bis);
> } else {
> message.setContent(InputStream.class, bis);
> }
> {code}
> My problem happens if the client thread tries to read the message while
> "{{bis}}" was read, but not yet restored. During that time, "{{bis}}" is
> closed for the in the client thread and it will skip over it (or throw an
> Exception, based on its config).
> My current best and maybe naive guess on how to solve this is to change the
> method {{JMSConduit.processReplyMessage(...)}}
> and execute the if-block around {{exchange.notifyAll();}} only after the
> if-block around {{incomingObserver.onMessage(exchange.getInMessage());}}
> WDYT?
> Best reagards
> Tobias
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
