[jira] [Resolved] (CXF-5827) Use only local name matching for inbound rpc/literal processing to support some older rpc/literal implementation
[
https://issues.apache.org/jira/browse/CXF-5827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aki Yoshida resolved CXF-5827.
--
Resolution: Fixed
Fix Version/s: 3.0.1
2.7.12
2.6.15
> Use only local name matching for inbound rpc/literal processing to support
> some older rpc/literal implementation
>
>
> Key: CXF-5827
> URL: https://issues.apache.org/jira/browse/CXF-5827
> Project: CXF
> Issue Type: Improvement
> Components: Soap Binding
>Affects Versions: 2.7.11, 2.6.14, 3.0.0
>Reporter: Aki Yoshida
>Assignee: Aki Yoshida
> Fix For: 2.6.15, 2.7.12, 3.0.1
>
>
> Although WS-i BP R2735 states the part parameter elements must be in no
> namespace, some old rpc/literal implementation prior to WS-I BP use qualified
> elements.
> In fact, many rpc/literal services in production use such older
> implementation and there is a benefit in tolerating namespaced elements.
> RPCInInterceptor.java has the following comment to address this point.
> {code}
> 156 // WSI-BP states that RPC/Lit part accessors should be
> completely unqualified
> 157 // However, older toolkits (Axis 1.x) are qualifying
> them. We'll go
> 158 // ahead and just match on the localpart. The
> RPCOutInterceptor
> 159 // will always generate WSI-BP compliant messages so
> it's unknown if
> 160 // the non-WSI-BP toolkits will be able to understand
> the CXF
> 161 // generated messages if they are expecting it to be
> qualified.
> 162 Iterator partItr =
> msg.getMessageParts().iterator();
> 163 while
> (!qn.getLocalPart().equals(part.getConcreteName().getLocalPart())
> 164 && partItr.hasNext()) {
> 165 part = partItr.next();
> 166 }
> 167
> 168 if (!qn.equals(part.getConcreteName())) {
> 169 throw new Fault(
> 170 new
> org.apache.cxf.common.i18n.Message(
> 171
> "UNKNOWN_RPC_LIT_PART",
> 172LOG,
> 173qn));
> {code}
> However, line 168 is rejecting the namespace qualified parameter name.
> This patch changes the above if-statement to use only the local name
> comparison.
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CXF-5827) Use only local name matching for inbound rpc/literal processing to support some older rpc/literal implementation
[
https://issues.apache.org/jira/browse/CXF-5827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14048758#comment-14048758
]
Aki Yoshida commented on CXF-5827:
--
Hi Dan,
thanks for your reply on the list.
yes. from the time when the first iPhone came out. :-)
regards, aki
> Use only local name matching for inbound rpc/literal processing to support
> some older rpc/literal implementation
>
>
> Key: CXF-5827
> URL: https://issues.apache.org/jira/browse/CXF-5827
> Project: CXF
> Issue Type: Improvement
> Components: Soap Binding
>Affects Versions: 2.7.11, 2.6.14, 3.0.0
>Reporter: Aki Yoshida
>Assignee: Aki Yoshida
> Fix For: 2.6.15, 2.7.12, 3.0.1
>
>
> Although WS-i BP R2735 states the part parameter elements must be in no
> namespace, some old rpc/literal implementation prior to WS-I BP use qualified
> elements.
> In fact, many rpc/literal services in production use such older
> implementation and there is a benefit in tolerating namespaced elements.
> RPCInInterceptor.java has the following comment to address this point.
> {code}
> 156 // WSI-BP states that RPC/Lit part accessors should be
> completely unqualified
> 157 // However, older toolkits (Axis 1.x) are qualifying
> them. We'll go
> 158 // ahead and just match on the localpart. The
> RPCOutInterceptor
> 159 // will always generate WSI-BP compliant messages so
> it's unknown if
> 160 // the non-WSI-BP toolkits will be able to understand
> the CXF
> 161 // generated messages if they are expecting it to be
> qualified.
> 162 Iterator partItr =
> msg.getMessageParts().iterator();
> 163 while
> (!qn.getLocalPart().equals(part.getConcreteName().getLocalPart())
> 164 && partItr.hasNext()) {
> 165 part = partItr.next();
> 166 }
> 167
> 168 if (!qn.equals(part.getConcreteName())) {
> 169 throw new Fault(
> 170 new
> org.apache.cxf.common.i18n.Message(
> 171
> "UNKNOWN_RPC_LIT_PART",
> 172LOG,
> 173qn));
> {code}
> However, line 168 is rejecting the namespace qualified parameter name.
> This patch changes the above if-statement to use only the local name
> comparison.
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CXF-5834) WS-RM's JAXB marshalling/unmarshalling is not thread-safe
[
https://issues.apache.org/jira/browse/CXF-5834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aki Yoshida resolved CXF-5834.
--
Resolution: Fixed
Fix Version/s: 3.0.1
2.7.12
2.6.15
> WS-RM's JAXB marshalling/unmarshalling is not thread-safe
> -
>
> Key: CXF-5834
> URL: https://issues.apache.org/jira/browse/CXF-5834
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 2.7.11, 2.6.14, 3.0.0
>Reporter: Aki Yoshida
>Assignee: Aki Yoshida
> Fix For: 2.6.15, 2.7.12, 3.0.1
>
>
> WS-RM's JAXB classes such as Acknowledgement etc are not marshaled or
> unamarshalled thread-safe and this may lead to some JAXB exception
> 2014 06 30 09:23:50#+00#WARN#org.apache.cxf.phase.PhaseInterceptorChain##M16
> SSL client SSL Client
> (Standard)@SAPNetCA#default-workqueue-8##avatarperf#rpetsy2#ifl#sy2#Interceptor
> for {http://schem
> as.xmlsoap.org/ws/2005/02/rm}SequenceAbstractService#{http://schemas.xmlsoap.org/ws/2005/02/rm}TerminateSequence
> has thrown exception, unwinding nowjava.lang.ArrayIndexOutOfBoundsException:
> -1
> at
> com.sun.xml.internal.bind.v2.util.CollisionCheckStack.pushNocheck(CollisionCheckStack.java:117)
> at
> com.sun.xml.internal.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:476)
> at
> com.sun.xml.internal.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:308)
> at
> com.sun.xml.internal.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:236)
> at
> javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:95)
> at
> org.apache.cxf.ws.rm.persistence.PersistenceUtils.serialiseAcknowledgment(PersistenceUtils.java:75)
> at
> org.apache.cxf.ws.rm.persistence.jdbc.RMTxStore.updateDestinationSequence(RMTxStore.java:817)
> at
> org.apache.cxf.ws.rm.persistence.jdbc.RMTxStore.persistIncoming(RMTxStore.java:635)
> at sun.reflect.GeneratedMethodAccessor228.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.apache.aries.proxy.impl.ProxyHandler$1.invoke(ProxyHandler.java:54)
> at
> org.apache.aries.proxy.impl.ProxyHandler.invoke(ProxyHandler.java:119)
> at $Proxy119.persistIncoming(Unknown Source)
> at
> org.apache.cxf.ws.rm.DestinationSequence.terminate(DestinationSequence.java:558)
> at
> org.apache.cxf.ws.rm.Destination.terminateSequence(Destination.java:81)
> at org.apache.cxf.ws.rm.Servant.terminateSequence(Servant.java:247)
> at org.apache.cxf.ws.rm.Servant.invoke(Servant.java:107)
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:107)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.java:242)
> at
> org.apache.cxf.ws.addressing.impl.InternalContextUtils$1.run(InternalContextUtils.java:323)
> at
> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$3.run(AutomaticWorkQueueImpl.java:428)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at
> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$AWQThreadFactory$1.run(AutomaticWorkQueueImpl.java:353)
> at java.lang.Thread.run(Thread.java:789)
>
> This was reported by Franz Forsthofer by mail.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CXF-5834) WS-RM's JAXB marshalling/unmarshalling is not thread-safe
Aki Yoshida created CXF-5834:
Summary: WS-RM's JAXB marshalling/unmarshalling is not thread-safe
Key: CXF-5834
URL: https://issues.apache.org/jira/browse/CXF-5834
Project: CXF
Issue Type: Bug
Components: WS-* Components
Affects Versions: 3.0.0, 2.6.14, 2.7.11
Reporter: Aki Yoshida
Assignee: Aki Yoshida
WS-RM's JAXB classes such as Acknowledgement etc are not marshaled or
unamarshalled thread-safe and this may lead to some JAXB exception
2014 06 30 09:23:50#+00#WARN#org.apache.cxf.phase.PhaseInterceptorChain##M16
SSL client SSL Client
(Standard)@SAPNetCA#default-workqueue-8##avatarperf#rpetsy2#ifl#sy2#Interceptor
for {http://schem
as.xmlsoap.org/ws/2005/02/rm}SequenceAbstractService#{http://schemas.xmlsoap.org/ws/2005/02/rm}TerminateSequence
has thrown exception, unwinding nowjava.lang.ArrayIndexOutOfBoundsException: -1
at
com.sun.xml.internal.bind.v2.util.CollisionCheckStack.pushNocheck(CollisionCheckStack.java:117)
at
com.sun.xml.internal.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:476)
at
com.sun.xml.internal.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:308)
at
com.sun.xml.internal.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:236)
at
javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:95)
at
org.apache.cxf.ws.rm.persistence.PersistenceUtils.serialiseAcknowledgment(PersistenceUtils.java:75)
at
org.apache.cxf.ws.rm.persistence.jdbc.RMTxStore.updateDestinationSequence(RMTxStore.java:817)
at
org.apache.cxf.ws.rm.persistence.jdbc.RMTxStore.persistIncoming(RMTxStore.java:635)
at sun.reflect.GeneratedMethodAccessor228.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.apache.aries.proxy.impl.ProxyHandler$1.invoke(ProxyHandler.java:54)
at
org.apache.aries.proxy.impl.ProxyHandler.invoke(ProxyHandler.java:119)
at $Proxy119.persistIncoming(Unknown Source)
at
org.apache.cxf.ws.rm.DestinationSequence.terminate(DestinationSequence.java:558)
at
org.apache.cxf.ws.rm.Destination.terminateSequence(Destination.java:81)
at org.apache.cxf.ws.rm.Servant.terminateSequence(Servant.java:247)
at org.apache.cxf.ws.rm.Servant.invoke(Servant.java:107)
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:107)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
at
org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.java:242)
at
org.apache.cxf.ws.addressing.impl.InternalContextUtils$1.run(InternalContextUtils.java:323)
at
org.apache.cxf.workqueue.AutomaticWorkQueueImpl$3.run(AutomaticWorkQueueImpl.java:428)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at
org.apache.cxf.workqueue.AutomaticWorkQueueImpl$AWQThreadFactory$1.run(AutomaticWorkQueueImpl.java:353)
at java.lang.Thread.run(Thread.java:789)
This was reported by Franz Forsthofer by mail.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CXF-5827) Use only local name matching for inbound rpc/literal processing to support some older rpc/literal implementation
[
https://issues.apache.org/jira/browse/CXF-5827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aki Yoshida updated CXF-5827:
-
Description:
Although WS-i BP R2735 states the part parameter elements must be in no
namespace, some old rpc/literal implementation prior to WS-I BP use qualified
elements.
In fact, many rpc/literal services in production use such older implementation
and there is a benefit in tolerating namespaced elements.
RPCInInterceptor.java has the following comment to address this point.
{code}
156 // WSI-BP states that RPC/Lit part accessors should be
completely unqualified
157 // However, older toolkits (Axis 1.x) are qualifying
them. We'll go
158 // ahead and just match on the localpart. The
RPCOutInterceptor
159 // will always generate WSI-BP compliant messages so
it's unknown if
160 // the non-WSI-BP toolkits will be able to understand
the CXF
161 // generated messages if they are expecting it to be
qualified.
162 Iterator partItr =
msg.getMessageParts().iterator();
163 while
(!qn.getLocalPart().equals(part.getConcreteName().getLocalPart())
164 && partItr.hasNext()) {
165 part = partItr.next();
166 }
167
168 if (!qn.equals(part.getConcreteName())) {
169 throw new Fault(
170 new
org.apache.cxf.common.i18n.Message(
171
"UNKNOWN_RPC_LIT_PART",
172 LOG,
173 qn));
{code}
However, line 168 is rejecting the namespace qualified parameter name.
This patch changes the above if-statement to use only the local name comparison.
was:
Although WS-i BP R2735 states the part parameter elements must be in no
namespace, some old rpc/literal implementation prior to WS-I BP use qualified
elements.
In fact, most rpc/literal services in production use such older implementation
and there is a benefit in tolerating namespaced elements.
RPCInInterceptor.java has the following comment to address this point.
{code}
156 // WSI-BP states that RPC/Lit part accessors should be
completely unqualified
157 // However, older toolkits (Axis 1.x) are qualifying
them. We'll go
158 // ahead and just match on the localpart. The
RPCOutInterceptor
159 // will always generate WSI-BP compliant messages so
it's unknown if
160 // the non-WSI-BP toolkits will be able to understand
the CXF
161 // generated messages if they are expecting it to be
qualified.
162 Iterator partItr =
msg.getMessageParts().iterator();
163 while
(!qn.getLocalPart().equals(part.getConcreteName().getLocalPart())
164 && partItr.hasNext()) {
165 part = partItr.next();
166 }
167
168 if (!qn.equals(part.getConcreteName())) {
169 throw new Fault(
170 new
org.apache.cxf.common.i18n.Message(
171
"UNKNOWN_RPC_LIT_PART",
172 LOG,
173 qn));
{code}
However, line 168 is rejecting the namespace qualified parameter name.
This patch changes the above if-statement to use only the local name comparison.
> Use only local name matching for inbound rpc/literal processing to support
> some older rpc/literal implementation
>
>
> Key: CXF-5827
> URL: https://issues.apache.org/jira/browse/CXF-5827
> Project: CXF
> Issue Type: Improvement
> Components: Soap Binding
>Affects Versions: 2.7.11, 2.6.14, 3.0.0
>Reporter: Aki Yoshida
>Assignee: Aki Yoshida
>
> Although WS-i BP R2735 states the part parameter elements must be in no
> namespace, some old rpc/literal implementation prior to WS-I BP use qualified
> elements.
> In fact, many rpc/literal services in production use such older
> implementation and there is a benefit in tolerating namespaced elements.
> RPCInInterceptor.java has the following comment to address this point.
> {code}
> 156 // WSI-BP states that RPC/Lit part accessor
[jira] [Updated] (CXF-5827) Use only local name matching for inbound rpc/literal processing to support some older rpc/literal implementation
[
https://issues.apache.org/jira/browse/CXF-5827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aki Yoshida updated CXF-5827:
-
Description:
Although WS-i BP R2735 states the part parameter elements must be in no
namespace, some old rpc/literal implementation prior to WS-I BP use qualified
elements.
In fact, most rpc/literal services in production use such older implementation
and there is a benefit in tolerating namespaced elements.
RPCInInterceptor.java has the following comment to address this point.
{code}
156 // WSI-BP states that RPC/Lit part accessors should be
completely unqualified
157 // However, older toolkits (Axis 1.x) are qualifying
them. We'll go
158 // ahead and just match on the localpart. The
RPCOutInterceptor
159 // will always generate WSI-BP compliant messages so
it's unknown if
160 // the non-WSI-BP toolkits will be able to understand
the CXF
161 // generated messages if they are expecting it to be
qualified.
162 Iterator partItr =
msg.getMessageParts().iterator();
163 while
(!qn.getLocalPart().equals(part.getConcreteName().getLocalPart())
164 && partItr.hasNext()) {
165 part = partItr.next();
166 }
167
168 if (!qn.equals(part.getConcreteName())) {
169 throw new Fault(
170 new
org.apache.cxf.common.i18n.Message(
171
"UNKNOWN_RPC_LIT_PART",
172 LOG,
173 qn));
{code}
However, line 168 is rejecting the namespace qualified parameter name.
This patch changes the above if-statement to use only the local name comparison.
was:
Although WS-i BP R2735 states the part parameter elements must be in no
namespace, some old rpc/literal implementation prior to WS-I BP use qualified
elements.
However, most rpc/literal services in production use such older implementation
and there is a benefit in tolerating namespaced elements.
RPCInInterceptor.java has the following comment to address this point.
{code}
156 // WSI-BP states that RPC/Lit part accessors should be
completely unqualified
157 // However, older toolkits (Axis 1.x) are qualifying
them. We'll go
158 // ahead and just match on the localpart. The
RPCOutInterceptor
159 // will always generate WSI-BP compliant messages so
it's unknown if
160 // the non-WSI-BP toolkits will be able to understand
the CXF
161 // generated messages if they are expecting it to be
qualified.
162 Iterator partItr =
msg.getMessageParts().iterator();
163 while
(!qn.getLocalPart().equals(part.getConcreteName().getLocalPart())
164 && partItr.hasNext()) {
165 part = partItr.next();
166 }
167
168 if (!qn.equals(part.getConcreteName())) {
169 throw new Fault(
170 new
org.apache.cxf.common.i18n.Message(
171
"UNKNOWN_RPC_LIT_PART",
172 LOG,
173 qn));
{code}
However, line 168 is rejecting the namespace qualified parameter name.
This patch changes the above if-statement to use only the local name comparison.
> Use only local name matching for inbound rpc/literal processing to support
> some older rpc/literal implementation
>
>
> Key: CXF-5827
> URL: https://issues.apache.org/jira/browse/CXF-5827
> Project: CXF
> Issue Type: Improvement
> Components: Soap Binding
>Affects Versions: 2.7.11, 2.6.14, 3.0.0
>Reporter: Aki Yoshida
>Assignee: Aki Yoshida
>
> Although WS-i BP R2735 states the part parameter elements must be in no
> namespace, some old rpc/literal implementation prior to WS-I BP use qualified
> elements.
> In fact, most rpc/literal services in production use such older
> implementation and there is a benefit in tolerating namespaced elements.
> RPCInInterceptor.java has the following comment to address this point.
> {code}
> 156 // WSI-BP states that RPC/Lit part accessor
[jira] [Resolved] (CXF-5809) WebSocket transport supporting concurrent asynchronous calls
[ https://issues.apache.org/jira/browse/CXF-5809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-5809. -- Resolution: Fixed > WebSocket transport supporting concurrent asynchronous calls > > > Key: CXF-5809 > URL: https://issues.apache.org/jira/browse/CXF-5809 > Project: CXF > Issue Type: Improvement > Components: Transports >Affects Versions: 3.0.0 >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 3.0.1 > > > This adds the async service call support in the conduit part and the > decoupling of the service invocation from the underlining websocket's > onMessage invocation at the destination part. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CXF-5827) Use only local name matching for inbound rpc/literal processing to support some older rpc/literal implementation
[
https://issues.apache.org/jira/browse/CXF-5827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14046010#comment-14046010
]
Aki Yoshida commented on CXF-5827:
--
Hi Dan,
thanks for your comment on dev@cxf and I answered to the list.
Let me know how you think.
thanks.
regards, aki
> Use only local name matching for inbound rpc/literal processing to support
> some older rpc/literal implementation
>
>
> Key: CXF-5827
> URL: https://issues.apache.org/jira/browse/CXF-5827
> Project: CXF
> Issue Type: Improvement
> Components: Soap Binding
>Affects Versions: 2.7.11, 2.6.14, 3.0.0
>Reporter: Aki Yoshida
>Assignee: Aki Yoshida
>
> Although WS-i BP R2735 states the part parameter elements must be in no
> namespace, some old rpc/literal implementation prior to WS-I BP use qualified
> elements.
> However, most rpc/literal services in production use such older
> implementation and there is a benefit in tolerating namespaced elements.
> RPCInInterceptor.java has the following comment to address this point.
> {code}
> 156 // WSI-BP states that RPC/Lit part accessors should be
> completely unqualified
> 157 // However, older toolkits (Axis 1.x) are qualifying
> them. We'll go
> 158 // ahead and just match on the localpart. The
> RPCOutInterceptor
> 159 // will always generate WSI-BP compliant messages so
> it's unknown if
> 160 // the non-WSI-BP toolkits will be able to understand
> the CXF
> 161 // generated messages if they are expecting it to be
> qualified.
> 162 Iterator partItr =
> msg.getMessageParts().iterator();
> 163 while
> (!qn.getLocalPart().equals(part.getConcreteName().getLocalPart())
> 164 && partItr.hasNext()) {
> 165 part = partItr.next();
> 166 }
> 167
> 168 if (!qn.equals(part.getConcreteName())) {
> 169 throw new Fault(
> 170 new
> org.apache.cxf.common.i18n.Message(
> 171
> "UNKNOWN_RPC_LIT_PART",
> 172LOG,
> 173qn));
> {code}
> However, line 168 is rejecting the namespace qualified parameter name.
> This patch changes the above if-statement to use only the local name
> comparison.
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CXF-5827) Use only local name matching for inbound rpc/literal processing to support some older rpc/literal implementation
Aki Yoshida created CXF-5827:
Summary: Use only local name matching for inbound rpc/literal
processing to support some older rpc/literal implementation
Key: CXF-5827
URL: https://issues.apache.org/jira/browse/CXF-5827
Project: CXF
Issue Type: Improvement
Components: Soap Binding
Affects Versions: 3.0.0, 2.6.14, 2.7.11
Reporter: Aki Yoshida
Assignee: Aki Yoshida
Although WS-i BP R2735 states the part parameter elements must be in no
namespace, some old rpc/literal implementation prior to WS-I BP use qualified
elements.
However, most rpc/literal services in production use such older implementation
and there is a benefit in tolerating namespaced elements.
RPCInInterceptor.java has the following comment to address this point.
{code}
156 // WSI-BP states that RPC/Lit part accessors should be
completely unqualified
157 // However, older toolkits (Axis 1.x) are qualifying
them. We'll go
158 // ahead and just match on the localpart. The
RPCOutInterceptor
159 // will always generate WSI-BP compliant messages so
it's unknown if
160 // the non-WSI-BP toolkits will be able to understand
the CXF
161 // generated messages if they are expecting it to be
qualified.
162 Iterator partItr =
msg.getMessageParts().iterator();
163 while
(!qn.getLocalPart().equals(part.getConcreteName().getLocalPart())
164 && partItr.hasNext()) {
165 part = partItr.next();
166 }
167
168 if (!qn.equals(part.getConcreteName())) {
169 throw new Fault(
170 new
org.apache.cxf.common.i18n.Message(
171
"UNKNOWN_RPC_LIT_PART",
172 LOG,
173 qn));
{code}
However, line 168 is rejecting the namespace qualified parameter name.
This patch changes the above if-statement to use only the local name comparison.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CXF-5812) When I am synchronously or asynchornously calling the web services it's throwing an issue like avax.xml.ws.soap.SOAPFaultException: java.lang.IllegalStateException: Inval
[ https://issues.apache.org/jira/browse/CXF-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-5812. -- Resolution: Invalid Hi Lakshmi, This is not a place to ask questions or get a quick help. Please post your question in the cxf users mailing list first. http://cxf.apache.org/mailing-lists.html Thanks. regards, aki > When I am synchronously or asynchornously calling the web services it's > throwing an issue like avax.xml.ws.soap.SOAPFaultException: > java.lang.IllegalStateException: Invalid use of SingleClientConnManager > > > Key: CXF-5812 > URL: https://issues.apache.org/jira/browse/CXF-5812 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Reporter: Lakshmi Satish Kumar >Priority: Critical > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CXF-5804) Improvement Issue CXF 5781 and CXF 5791
[ https://issues.apache.org/jira/browse/CXF-5804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-5804. -- Resolution: Won't Fix Hi Guilherme, thanks. I'm closing this ticket as won't fix. regards, aki > Improvement Issue CXF 5781 and CXF 5791 > --- > > Key: CXF-5804 > URL: https://issues.apache.org/jira/browse/CXF-5804 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 3.0.1 > Environment: GNU/Linux Debian sid with jdk1.7.0_60 (Java HotSpot(TM) > 64-Bit Server VM (build 24.60-b09, mixed mode)) >Reporter: Guilherme Veloso Neves Oliveira > Labels: patch > Fix For: 3.0.1 > > Attachments: issues_CXF-5781-5791.patch > > > This patch aims to improve the changes made to fix issues of 5781 > (https://issues.apache.org/jira/browse/CXF-5781) and 5791 > (https://issues.apache.org/jira/browse/CXF-5791) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CXF-5809) WebSocket transport supporting concurrent asynchronous calls
Aki Yoshida created CXF-5809: Summary: WebSocket transport supporting concurrent asynchronous calls Key: CXF-5809 URL: https://issues.apache.org/jira/browse/CXF-5809 Project: CXF Issue Type: Improvement Components: Transports Affects Versions: 3.0.0 Reporter: Aki Yoshida Assignee: Aki Yoshida Fix For: 3.0.1 This adds the async service call support in the conduit part and the decoupling of the service invocation from the underlining websocket's onMessage invocation at the destination part. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CXF-5746) WebsocketConduit to use the id header so that it can correlate requests and responses
[ https://issues.apache.org/jira/browse/CXF-5746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-5746. -- Resolution: Fixed > WebsocketConduit to use the id header so that it can correlate requests and > responses > - > > Key: CXF-5746 > URL: https://issues.apache.org/jira/browse/CXF-5746 > Project: CXF > Issue Type: Improvement > Components: Transports >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 3.0.1 > > > This is a follow up from CXF-5715 to make the websocket conduit to use the ID > referencing mechanism so that it can correlate the responses that arrive > asynchronously to its requests. > In this way, a normal jaxws or jaxrs based request-response services can be > invoked using the websocket conduit. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CXF-5623) Failed to invoke WSDLToJava - is already defined
[ https://issues.apache.org/jira/browse/CXF-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14032437#comment-14032437 ] Aki Yoshida commented on CXF-5623: -- I think what Dan described is rather the correct way than just a workaround to be aligned with WS-I basic profile. http://www.ws-i.org/profiles/BasicProfile-1.0-2004-04-16.html#refinement16498504 R2001 A DESCRIPTION MUST only use the WSDL "import" statement to import another WSDL description. R2002 To import XML Schema Definitions, a DESCRIPTION MUST use the XML Schema "import" statement. > Failed to invoke WSDLToJava - is already defined > > > Key: CXF-5623 > URL: https://issues.apache.org/jira/browse/CXF-5623 > Project: CXF > Issue Type: Sub-task > Components: Build system >Affects Versions: 2.4 >Reporter: Daniel Ferreira Castro >Assignee: Daniel Kulp > Fix For: 2.6.15, 2.7.12, 3.0.1 > > Attachments: commons.xsd, corretor.wsdl, corretor.xsd, erro.xsd, > requestCorretor.xsd > > > C:\Users\didemz49\jboss-as-7.1.1.Final\bin>wsconsume > --source=C:\Users\didemz49\Desktop\WebServicesMobileProject\WebServicesMobileProject\src > --verbose -k C:\Users\didemz49\Desktop\WebServicesMobileProject\WebS > ervicesMobile\wsdl\corretor.wsdl > Could not find log4j.xml configuration, logging to console. > Loading FrontEnd jaxws ... > Loading DataBinding jaxb ... > wsdl2java -compile -exsh false -d > C:\Users\didemz49\Desktop\WebServicesMobileProject\WebServicesMobileProject\src > -verbose -classdir C:\Users\didemz49\jboss-as-7.1.1.Final\bin\output > -allowElementReferences fil > e:/C:/Users/didemz49/Desktop/WebServicesMobileProject/WebServicesMobile/wsdl/corretor.wsdl > wsdl2java - Apache CXF 2.4.6 > Failed to invoke WSDLToJava > org.apache.cxf.tools.common.ToolException: Thrown by JAXB: > Thrown by JAXB: > 'mensagemErro' is already defined > at line 6 column 62 of schema > file:/C:/Users/didemz49/Desktop/WebServicesMobileProject/WebServicesMobile/xsd/erro.xsd > Thrown by JAXB: (related to above error) the first definition appears here > 'tMensagemErro' is already defined > at line 29 column 42 of schema > file:/C:/Users/didemz49/Desktop/WebServicesMobileProject/WebServicesMobile/xsd/erro.xsd > Thrown by JAXB: (related to above error) the first definition appears here > 'tListaMensagens' is already defined > at line 42 column 38 of schema > file:/C:/Users/didemz49/Desktop/WebServicesMobileProject/WebServicesMobile/xsd/erro.xsd > Thrown by JAXB: (related to above error) the first definition appears here > 'tListaLinks' is already defined > at line 52 column 14 of schema > file:/C:/Users/didemz49/Desktop/WebServicesMobileProject/WebServicesMobile/xsd/erro.xsd > Thrown by JAXB: (related to above error) the first definition appears here > at > org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBBindErrorListener.throwError(JAXBBindErrorListener.java:40) > at > org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:413) > at > org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.generateTypes(WSDLToJavaContainer.java:591) > at > org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:243) > at > org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:138) > at > org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:286) > at > org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:103) > at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113) > at > org.jboss.wsf.stack.cxf.tools.CXFConsumerImpl.consume(CXFConsumerImpl.java:250) > at org.jboss.ws.tools.cmd.WSConsume.importServices(WSConsume.java:279) > at org.jboss.ws.tools.cmd.WSConsume.mainInternal(WSConsume.java:104) > at org.jboss.ws.tools.cmd.WSConsume.main(WSConsume.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.modules.Module.run(Module.java:260) > at org.jboss.modules.Main.main(Main.java:291) > Caused by: org.xml.sax.SAXParseException; systemId: > file:/C:/Users/didemz49/Desktop/WebServicesMobileProject/WebServicesMobile/xsd/erro.xsd; > lineNumber: 6; columnNumber: 62; 'mensagemErro' is already defined > at > org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBBindErrorListener.error(JAXBBindErrorListener.java:61) > at > com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.error(Schema
[jira] [Commented] (CXF-5804) Improvement Issue CXF 5781 and CXF 5791
[ https://issues.apache.org/jira/browse/CXF-5804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14032316#comment-14032316 ] Aki Yoshida commented on CXF-5804: -- Well, I think this change will change the semantics of the conduit slightly or more precisely speaking change the identity of the conduit. when someone is setting a URL with no port to their conduit, my personal opinion is to leave this url as is until this info (the missing port) is needed instead of explicitly to convert the url set in the conduit. regards, aki > Improvement Issue CXF 5781 and CXF 5791 > --- > > Key: CXF-5804 > URL: https://issues.apache.org/jira/browse/CXF-5804 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 3.0.1 > Environment: GNU/Linux Debian sid with jdk1.7.0_60 (Java HotSpot(TM) > 64-Bit Server VM (build 24.60-b09, mixed mode)) >Reporter: Guilherme Veloso Neves Oliveira > Labels: patch > Fix For: 3.0.1 > > Attachments: issues_CXF-5781-5791.patch > > > This patch aims to improve the changes made to fix issues of 5781 > (https://issues.apache.org/jira/browse/CXF-5781) and 5791 > (https://issues.apache.org/jira/browse/CXF-5791) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CXF-5805) Invalid SOAP Envelope names are accepted
[ https://issues.apache.org/jira/browse/CXF-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-5805. -- Resolution: Fixed Fix Version/s: 3.0.1 2.7.12 2.6.15 > Invalid SOAP Envelope names are accepted > > > Key: CXF-5805 > URL: https://issues.apache.org/jira/browse/CXF-5805 > Project: CXF > Issue Type: Bug > Components: Soap Binding >Affects Versions: 2.6.13, 2.7.11, 3.0.0 >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 2.6.15, 2.7.12, 3.0.1 > > > The CXF SOAP binding does not correctly verify the Envelope name. > This was reported on users@camel > http://camel.465427.n5.nabble.com/CXF-Endpoint-accepts-invalid-SOAP-Envelope-in-POJO-Mode-td5751971.html > The envelope name must be "Envelope" > http://www.w3.org/TR/2000/NOTE-SOAP-2508/#_Toc478383494 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CXF-5805) Invalid SOAP Envelope names are accepted
Aki Yoshida created CXF-5805: Summary: Invalid SOAP Envelope names are accepted Key: CXF-5805 URL: https://issues.apache.org/jira/browse/CXF-5805 Project: CXF Issue Type: Bug Components: Soap Binding Affects Versions: 3.0.0, 2.7.11, 2.6.13 Reporter: Aki Yoshida Assignee: Aki Yoshida The CXF SOAP binding does not correctly verify the Envelope name. This was reported on users@camel http://camel.465427.n5.nabble.com/CXF-Endpoint-accepts-invalid-SOAP-Envelope-in-POJO-Mode-td5751971.html The envelope name must be "Envelope" http://www.w3.org/TR/2000/NOTE-SOAP-2508/#_Toc478383494 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CXF-5798) WebSocket transport fails to transport a large message
[ https://issues.apache.org/jira/browse/CXF-5798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-5798. -- Resolution: Fixed Fix Version/s: 3.0.1 fixed the issue using one approach that buffers the output for the initial response. This approach inevitably limits the size of the response message that can be sent back (note that this is only about the initial response message and not about subsequently pushed response messages. Those subsequent responses by written by the service application to the socket are sent back as individual messages without buffering, Hence there is no size limit for them) To overcome this limitation, the fragment handling may be added in the cxf's websocket binding to transport large response messages. But again, the counter part can be implemented in CXF's websocket conduit, but that won't help for other clients (e.g. js clients). So this open part can be tracked separately. > WebSocket transport fails to transport a large message > -- > > Key: CXF-5798 > URL: https://issues.apache.org/jira/browse/CXF-5798 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 3.0.0 >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 3.0.1 > > > There is an issue for the server to reliably transmit the entire message. > The original server side (i.e., Destination) implementation associates each > write operation from the application to a websocket write operation. When the > message is large and split in this way, this will confuse the client to > interpret the message. > Either the fragment flag must be set at the write operation at the server or > the message must be buffered (if the client is not supporting the fragment). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CXF-5798) WebSocket transport fails to transport a large message
Aki Yoshida created CXF-5798: Summary: WebSocket transport fails to transport a large message Key: CXF-5798 URL: https://issues.apache.org/jira/browse/CXF-5798 Project: CXF Issue Type: Bug Components: Transports Affects Versions: 3.0.0 Reporter: Aki Yoshida Assignee: Aki Yoshida There is an issue for the server to reliably transmit the entire message. The original server side (i.e., Destination) implementation associates each write operation from the application to a websocket write operation. When the message is large and split in this way, this will confuse the client to interpret the message. Either the fragment flag must be set at the write operation at the server or the message must be buffered (if the client is not supporting the fragment). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CXF-5791) Could not send a message. Caused by HTTP response '404: Not Found'
[
https://issues.apache.org/jira/browse/CXF-5791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aki Yoshida resolved CXF-5791.
--
Resolution: Fixed
Fix Version/s: 3.0.1
Guilherme's patch applied.
thanks.
> Could not send a message. Caused by HTTP response '404: Not Found'
> --
>
> Key: CXF-5791
> URL: https://issues.apache.org/jira/browse/CXF-5791
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.0.1
> Environment: GNU/Linux Debian sid with jdk1.7.0_60 (Java HotSpot(TM)
> 64-Bit Server VM (build 24.60-b09, mixed mode))
>Reporter: Guilherme Veloso Neves Oliveira
>Assignee: Aki Yoshida
> Labels: patch
> Fix For: 3.0.1
>
> Attachments: NettyHttpClientRequest.patch
>
>
> The issue https://issues.apache.org/jira/browse/CXF-5781 was resolved the
> exception "port out of range: -1", but introduced the new exception below
> (Could not send Message - HTTP response '404: Not Found')
> What is surprising for me is that the application server hosting the
> webservice runs an instance of JBoss (Red Hat) and not IIS (Microsoft). I say
> this because the HTTP header response for code 404 was produced by an IIS
> server (Microsoft). In DEBUG mode, I collected the correct header produced by
> JBOSS and wrong produced by IIS (Microsoft). I caught these two headers
> stopping code execution in getResponseCode () method of the class $
> org.apache.cxf.transport.http.netty.client.NettyHttpConduit
> NettyWrappedOutputStream.
> The wrong HTTP header was produced simply running the code!
> The correct HTTP header was produced as follows: at runtime, in
> initializePorts() method of class org.apache.cxf.jaxws.ServiceImpl.java the
> value of the local variable called "address" (in line 210, before calling the
> method addPort) was changed to include the number of TCP port 443
> (https://homologwsincom.in.gov.br:443/services/servicoIN). With this change
> again (the reasons are described in
> https://issues.apache.org/jira/browse/CXF-5781), everything worked normally.
> Despite trying to create a patch, I did not get success. So, I would ask that
> the TCP port number was not removed from the local variable called "address".
> Below the headers HTTP:
> ==
> Correct Header
> DefaultFullHttpResponse(decodeResult: success)
> HTTP/1.1 200 OK
> Date: Mon, 09 Jun 2014 01:22:57 GMT
> X-Powered-By: Servlet 2.5; JBoss-5.0/JBossWeb-2.1
> Content-Type: text/xml;charset=UTF-8
> Vary: Accept-Encoding,User-Agent
> Keep-Alive: timeout=20, max=100
> Connection: Keep-Alive
> Content-Length: 730
> -
> Wrong Header
> DefaultFullHttpResponse(decodeResult: success)
> HTTP/1.1 404 Not Found
> Date: Mon, 09 Jun 2014 01:20:52 GMT
> Server: Microsoft-IIS/7.5
> Content-Type: text/html; charset=ISO-8859-1
> X-Powered-By: ASP.NET
> Vary: Accept-Encoding,User-Agent
> Keep-Alive: timeout=5, max=100
> Connection: Keep-Alive
> Content-Length: 1245
> =
> Below, the stacktrace:
> Jun 08, 2014 10:09:05 PM org.apache.cxf.phase.PhaseInterceptorChain
> doDefaultLogging
> WARNING: Interceptor for
> {http://xfire.ws.incom}servicoIN#{http://xfire.ws.incom}ConsultaFormasPagamento
> has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: Could not send Message.
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> 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:326)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:137)
> at com.sun.proxy.$Proxy35.consultaFormasPagamento(Unknown Source)
> at
> incom.ws.xfire.ServicoINPortType_ServicoINHttpPort_Client.main(ServicoINPortType_ServicoINHttpPort_Client.java:60)
> Caused by: org.apache.cxf.transport.http.HTTPException: HTTP response '404:
> Not Found' when communicating with
> https://homologwsincom.in.gov.br/services/servicoIN
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1573)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1525)
>
[jira] [Assigned] (CXF-5791) Could not send a message. Caused by HTTP response '404: Not Found'
[
https://issues.apache.org/jira/browse/CXF-5791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aki Yoshida reassigned CXF-5791:
Assignee: Aki Yoshida
> Could not send a message. Caused by HTTP response '404: Not Found'
> --
>
> Key: CXF-5791
> URL: https://issues.apache.org/jira/browse/CXF-5791
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.0.1
> Environment: GNU/Linux Debian sid with jdk1.7.0_60 (Java HotSpot(TM)
> 64-Bit Server VM (build 24.60-b09, mixed mode))
>Reporter: Guilherme Veloso Neves Oliveira
>Assignee: Aki Yoshida
> Labels: patch
> Attachments: NettyHttpClientRequest.patch
>
>
> The issue https://issues.apache.org/jira/browse/CXF-5781 was resolved the
> exception "port out of range: -1", but introduced the new exception below
> (Could not send Message - HTTP response '404: Not Found')
> What is surprising for me is that the application server hosting the
> webservice runs an instance of JBoss (Red Hat) and not IIS (Microsoft). I say
> this because the HTTP header response for code 404 was produced by an IIS
> server (Microsoft). In DEBUG mode, I collected the correct header produced by
> JBOSS and wrong produced by IIS (Microsoft). I caught these two headers
> stopping code execution in getResponseCode () method of the class $
> org.apache.cxf.transport.http.netty.client.NettyHttpConduit
> NettyWrappedOutputStream.
> The wrong HTTP header was produced simply running the code!
> The correct HTTP header was produced as follows: at runtime, in
> initializePorts() method of class org.apache.cxf.jaxws.ServiceImpl.java the
> value of the local variable called "address" (in line 210, before calling the
> method addPort) was changed to include the number of TCP port 443
> (https://homologwsincom.in.gov.br:443/services/servicoIN). With this change
> again (the reasons are described in
> https://issues.apache.org/jira/browse/CXF-5781), everything worked normally.
> Despite trying to create a patch, I did not get success. So, I would ask that
> the TCP port number was not removed from the local variable called "address".
> Below the headers HTTP:
> ==
> Correct Header
> DefaultFullHttpResponse(decodeResult: success)
> HTTP/1.1 200 OK
> Date: Mon, 09 Jun 2014 01:22:57 GMT
> X-Powered-By: Servlet 2.5; JBoss-5.0/JBossWeb-2.1
> Content-Type: text/xml;charset=UTF-8
> Vary: Accept-Encoding,User-Agent
> Keep-Alive: timeout=20, max=100
> Connection: Keep-Alive
> Content-Length: 730
> -
> Wrong Header
> DefaultFullHttpResponse(decodeResult: success)
> HTTP/1.1 404 Not Found
> Date: Mon, 09 Jun 2014 01:20:52 GMT
> Server: Microsoft-IIS/7.5
> Content-Type: text/html; charset=ISO-8859-1
> X-Powered-By: ASP.NET
> Vary: Accept-Encoding,User-Agent
> Keep-Alive: timeout=5, max=100
> Connection: Keep-Alive
> Content-Length: 1245
> =
> Below, the stacktrace:
> Jun 08, 2014 10:09:05 PM org.apache.cxf.phase.PhaseInterceptorChain
> doDefaultLogging
> WARNING: Interceptor for
> {http://xfire.ws.incom}servicoIN#{http://xfire.ws.incom}ConsultaFormasPagamento
> has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: Could not send Message.
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> 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:326)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:137)
> at com.sun.proxy.$Proxy35.consultaFormasPagamento(Unknown Source)
> at
> incom.ws.xfire.ServicoINPortType_ServicoINHttpPort_Client.main(ServicoINPortType_ServicoINHttpPort_Client.java:60)
> Caused by: org.apache.cxf.transport.http.HTTPException: HTTP response '404:
> Not Found' when communicating with
> https://homologwsincom.in.gov.br/services/servicoIN
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1573)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1525)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.
[jira] [Resolved] (CXF-5794) DynamicClientFactory createClient fails for Simple Rpc Service (java.lang.IllegalStateException: no source files )
[ https://issues.apache.org/jira/browse/CXF-5794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-5794. -- Resolution: Fixed Fix Version/s: 3.0.1 2.7.12 2.6.15 > DynamicClientFactory createClient fails for Simple Rpc Service > (java.lang.IllegalStateException: no source files ) > -- > > Key: CXF-5794 > URL: https://issues.apache.org/jira/browse/CXF-5794 > Project: CXF > Issue Type: Bug > Components: Simple Frontend >Affects Versions: 2.6.13, 2.7.11, 3.0.0 >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 2.6.15, 2.7.12, 3.0.1 > > > When there is no source files generated for the types (e.g., the service is > an RPC styled service using primitive types), the client generation code is > resoling the following error: > Fails after DynamicClientFactory.java Line#369. > INFO: Created classes: > java.lang.IllegalStateException: no source files > at com.sun.tools.javac.main.Main.error(Main.java:173) > at com.sun.tools.javac.main.Main.compile(Main.java:397) > at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:132) > at > org.apache.cxf.common.util.Compiler.internalJava6Compile(Compiler.java:232) > at > org.apache.cxf.common.util.Compiler.useJava6Compiler(Compiler.java:194) > at > org.apache.cxf.common.util.Compiler.compileFiles(Compiler.java:144) > at > org.apache.cxf.common.util.Compiler.compileFiles(Compiler.java:139) > at > org.apache.cxf.endpoint.dynamic.DynamicClientFactory.compileJavaSrc(DynamicClientFactory.java:611) > > at > org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:370) > > at > org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:241) > > at > org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:234) > > at > org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:189) > > at > org.voxeo.eval.cxfclient.SimpleRpcLiteralClientTest.testName(SimpleRpcLiteralClientTest.java:46) > > Reported in > http://cxf.547215.n5.nabble.com/DynamicClientFactory-createClient-fails-for-SimpleRpc-Service-tt5744628.html#a5744697 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CXF-5794) DynamicClientFactory createClient fails for Simple Rpc Service (java.lang.IllegalStateException: no source files )
Aki Yoshida created CXF-5794: Summary: DynamicClientFactory createClient fails for Simple Rpc Service (java.lang.IllegalStateException: no source files ) Key: CXF-5794 URL: https://issues.apache.org/jira/browse/CXF-5794 Project: CXF Issue Type: Bug Components: Simple Frontend Affects Versions: 3.0.0, 2.7.11, 2.6.13 Reporter: Aki Yoshida Assignee: Aki Yoshida When there is no source files generated for the types (e.g., the service is an RPC styled service using primitive types), the client generation code is resoling the following error: Fails after DynamicClientFactory.java Line#369. INFO: Created classes: java.lang.IllegalStateException: no source files at com.sun.tools.javac.main.Main.error(Main.java:173) at com.sun.tools.javac.main.Main.compile(Main.java:397) at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:132) at org.apache.cxf.common.util.Compiler.internalJava6Compile(Compiler.java:232) at org.apache.cxf.common.util.Compiler.useJava6Compiler(Compiler.java:194) at org.apache.cxf.common.util.Compiler.compileFiles(Compiler.java:144) at org.apache.cxf.common.util.Compiler.compileFiles(Compiler.java:139) at org.apache.cxf.endpoint.dynamic.DynamicClientFactory.compileJavaSrc(DynamicClientFactory.java:611) at org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:370) at org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:241) at org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:234) at org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:189) at org.voxeo.eval.cxfclient.SimpleRpcLiteralClientTest.testName(SimpleRpcLiteralClientTest.java:46) Reported in http://cxf.547215.n5.nabble.com/DynamicClientFactory-createClient-fails-for-SimpleRpc-Service-tt5744628.html#a5744697 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CXF-5790) Response-Code is logged for the response sent over a decoupled endpoint
[ https://issues.apache.org/jira/browse/CXF-5790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida updated CXF-5790: - Component/s: (was: WS-* Components) Core > Response-Code is logged for the response sent over a decoupled endpoint > --- > > Key: CXF-5790 > URL: https://issues.apache.org/jira/browse/CXF-5790 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 2.7.11, 2.6.14, 3.0.0 >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 2.6.15, 2.7.12, 3.0.1 > > > The response code appears where it is not supposed to be, as below. > INFO: Inbound Message > > ID: 2 > Address: http://localhost:9990/decoupled_endpoint > Response-Code: 200 > Encoding: UTF-8 > Http-Method: POST > Content-Type: text/xml; charset=UTF-8 > Headers: ... > Payload: ... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CXF-5790) Response-Code is logged for the response sent over a decoupled endpoint
[ https://issues.apache.org/jira/browse/CXF-5790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-5790. -- Resolution: Fixed Fix Version/s: 3.0.1 2.7.12 2.6.15 > Response-Code is logged for the response sent over a decoupled endpoint > --- > > Key: CXF-5790 > URL: https://issues.apache.org/jira/browse/CXF-5790 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 2.7.11, 2.6.14, 3.0.0 >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 2.6.15, 2.7.12, 3.0.1 > > > The response code appears where it is not supposed to be, as below. > INFO: Inbound Message > > ID: 2 > Address: http://localhost:9990/decoupled_endpoint > Response-Code: 200 > Encoding: UTF-8 > Http-Method: POST > Content-Type: text/xml; charset=UTF-8 > Headers: ... > Payload: ... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CXF-5790) Response-Code is logged for the response sent over a decoupled endpoint
Aki Yoshida created CXF-5790: Summary: Response-Code is logged for the response sent over a decoupled endpoint Key: CXF-5790 URL: https://issues.apache.org/jira/browse/CXF-5790 Project: CXF Issue Type: Bug Components: WS-* Components Affects Versions: 3.0.0, 2.6.14, 2.7.11 Reporter: Aki Yoshida Assignee: Aki Yoshida The response code appears where it is not supposed to be, as below. INFO: Inbound Message ID: 2 Address: http://localhost:9990/decoupled_endpoint Response-Code: 200 Encoding: UTF-8 Http-Method: POST Content-Type: text/xml; charset=UTF-8 Headers: ... Payload: ... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CXF-5781) Port ou of Range: -1
[
https://issues.apache.org/jira/browse/CXF-5781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aki Yoshida resolved CXF-5781.
--
Resolution: Fixed
Fix Version/s: 3.0.1
> Port ou of Range: -1
>
>
> Key: CXF-5781
> URL: https://issues.apache.org/jira/browse/CXF-5781
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.0
> Environment: GNU/Linux Debian sid with jdk1.7.0_60 (Java HotSpot(TM)
> 64-Bit Server VM (build 24.60-b09, mixed mode))
>Reporter: Guilherme Veloso Neves Oliveira
>Assignee: Aki Yoshida
>Priority: Critical
> Fix For: 3.0.1
>
>
> I'm trying to access a service available in the URL
> (https://homologwsincom.in.gov.br/services/servicoIN) and when I run the
> ServicoINPortType_ServicoINHttpPort_Client.java (write automatic for CXF 3.0)
> class, with appropriate amendments security header, happens the exception
> below. All classes containing this url in the code generated automatically
> been changed to possess the number of tcp port 443 getting written as
> ("https://homologwsincom.in.gov.br:443/services/servicoIN";). I add the port
> number 443 in the URL as an attempt to fix the problem.
> In initializePorts() method of class org.apache.cxf.jaxws.ServiceImpl.java
> the URL (https://homologwsincom.in.gov.br:443/services/servicoIN?wsdl) was
> changed to (https:// homologwsincom.in.gov.br/services/servicoIN) without the
> TCP port number.
> At runtime, the realized change in the value of the local variable called
> "address" to include the number of TCP port 443 again and everything worked
> normally. I would like the above method does not alter the provided URL.
> Below, the stacktrace:
> ADVERTÊNCIA: Interceptor for
> {http://xfire.ws.incom}servicoIN#{http://xfire.ws.incom}ConsultaFormasPagamento
> has thrown exception, unwinding now
> java.lang.IllegalArgumentException: IllegalArgumentException invoking
> https://homologwsincom.in.gov.br/services/servicoIN: port out of range:-1
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1359)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1348)
> at
> org.apache.cxf.transport.http.netty.client.NettyHttpConduit$NettyWrappedOutputStream.close(NettyHttpConduit.java:153)
> at
> org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:56)
> at
> org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:215)
> at
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:638)
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> 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:326)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:137)
> at com.sun.proxy.$Proxy40.consultaFormasPagamento(Unknown Source)
> at
> incom.ws.xfire.ServicoINPortType_ServicoINHttpPort_Client.main(ServicoINPortType_ServicoINHttpPort_Client.java:62)
> Caused by: java.lang.IllegalArgumentException: port out of range:-1
> at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143)
> at java.net.InetSocketAddress.(InetSocketAddress.java:224)
> at
> org.apache.cxf.transport.http.netty.client.NettyHttpConduit$NettyWrappedOutputStream.connect(NettyHttpConduit.java:293)
> at
> org.apache.cxf.transport.http.netty.client.NettyHttpConduit$NettyWrappedOutputStream.setupWrappedStream(NettyHttpConduit.java:243)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleHeadersTrustCaching(HTTPConduit.java:1302)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.onFirstWrite(HTTPConduit.java:1258)
> at
> org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOut
[jira] [Commented] (CXF-5781) Port ou of Range: -1
[
https://issues.apache.org/jira/browse/CXF-5781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14018042#comment-14018042
]
Aki Yoshida commented on CXF-5781:
--
it looks like the default port handling is missing in NettyHttpConduit.
> Port ou of Range: -1
>
>
> Key: CXF-5781
> URL: https://issues.apache.org/jira/browse/CXF-5781
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.0
> Environment: GNU/Linux Debian sid with jdk1.7.0_60 (Java HotSpot(TM)
> 64-Bit Server VM (build 24.60-b09, mixed mode))
>Reporter: Guilherme Veloso Neves Oliveira
>Assignee: Aki Yoshida
>Priority: Critical
>
> I'm trying to access a service available in the URL
> (https://homologwsincom.in.gov.br/services/servicoIN) and when I run the
> ServicoINPortType_ServicoINHttpPort_Client.java (write automatic for CXF 3.0)
> class, with appropriate amendments security header, happens the exception
> below. All classes containing this url in the code generated automatically
> been changed to possess the number of tcp port 443 getting written as
> ("https://homologwsincom.in.gov.br:443/services/servicoIN";). I add the port
> number 443 in the URL as an attempt to fix the problem.
> In initializePorts() method of class org.apache.cxf.jaxws.ServiceImpl.java
> the URL (https://homologwsincom.in.gov.br:443/services/servicoIN?wsdl) was
> changed to (https:// homologwsincom.in.gov.br/services/servicoIN) without the
> TCP port number.
> At runtime, the realized change in the value of the local variable called
> "address" to include the number of TCP port 443 again and everything worked
> normally. I would like the above method does not alter the provided URL.
> Below, the stacktrace:
> ADVERTÊNCIA: Interceptor for
> {http://xfire.ws.incom}servicoIN#{http://xfire.ws.incom}ConsultaFormasPagamento
> has thrown exception, unwinding now
> java.lang.IllegalArgumentException: IllegalArgumentException invoking
> https://homologwsincom.in.gov.br/services/servicoIN: port out of range:-1
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1359)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1348)
> at
> org.apache.cxf.transport.http.netty.client.NettyHttpConduit$NettyWrappedOutputStream.close(NettyHttpConduit.java:153)
> at
> org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:56)
> at
> org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:215)
> at
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:638)
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> 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:326)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:137)
> at com.sun.proxy.$Proxy40.consultaFormasPagamento(Unknown Source)
> at
> incom.ws.xfire.ServicoINPortType_ServicoINHttpPort_Client.main(ServicoINPortType_ServicoINHttpPort_Client.java:62)
> Caused by: java.lang.IllegalArgumentException: port out of range:-1
> at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143)
> at java.net.InetSocketAddress.(InetSocketAddress.java:224)
> at
> org.apache.cxf.transport.http.netty.client.NettyHttpConduit$NettyWrappedOutputStream.connect(NettyHttpConduit.java:293)
> at
> org.apache.cxf.transport.http.netty.client.NettyHttpConduit$NettyWrappedOutputStream.setupWrappedStream(NettyHttpConduit.java:243)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleHeadersTrustCaching(HTTPConduit.java:1302)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.onFirstWrite(HTTPConduit.java:1258)
> at
> org.apache.cxf.io.Abstr
[jira] [Assigned] (CXF-5781) Port ou of Range: -1
[
https://issues.apache.org/jira/browse/CXF-5781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aki Yoshida reassigned CXF-5781:
Assignee: Aki Yoshida
> Port ou of Range: -1
>
>
> Key: CXF-5781
> URL: https://issues.apache.org/jira/browse/CXF-5781
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.0
> Environment: GNU/Linux Debian sid with jdk1.7.0_60 (Java HotSpot(TM)
> 64-Bit Server VM (build 24.60-b09, mixed mode))
>Reporter: Guilherme Veloso Neves Oliveira
>Assignee: Aki Yoshida
>Priority: Critical
>
> I'm trying to access a service available in the URL
> (https://homologwsincom.in.gov.br/services/servicoIN) and when I run the
> ServicoINPortType_ServicoINHttpPort_Client.java (write automatic for CXF 3.0)
> class, with appropriate amendments security header, happens the exception
> below. All classes containing this url in the code generated automatically
> been changed to possess the number of tcp port 443 getting written as
> ("https://homologwsincom.in.gov.br:443/services/servicoIN";). I add the port
> number 443 in the URL as an attempt to fix the problem.
> In initializePorts() method of class org.apache.cxf.jaxws.ServiceImpl.java
> the URL (https://homologwsincom.in.gov.br:443/services/servicoIN?wsdl) was
> changed to (https:// homologwsincom.in.gov.br/services/servicoIN) without the
> TCP port number.
> At runtime, the realized change in the value of the local variable called
> "address" to include the number of TCP port 443 again and everything worked
> normally. I would like the above method does not alter the provided URL.
> Below, the stacktrace:
> ADVERTÊNCIA: Interceptor for
> {http://xfire.ws.incom}servicoIN#{http://xfire.ws.incom}ConsultaFormasPagamento
> has thrown exception, unwinding now
> java.lang.IllegalArgumentException: IllegalArgumentException invoking
> https://homologwsincom.in.gov.br/services/servicoIN: port out of range:-1
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1359)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1348)
> at
> org.apache.cxf.transport.http.netty.client.NettyHttpConduit$NettyWrappedOutputStream.close(NettyHttpConduit.java:153)
> at
> org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:56)
> at
> org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:215)
> at
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:638)
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> 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:326)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:137)
> at com.sun.proxy.$Proxy40.consultaFormasPagamento(Unknown Source)
> at
> incom.ws.xfire.ServicoINPortType_ServicoINHttpPort_Client.main(ServicoINPortType_ServicoINHttpPort_Client.java:62)
> Caused by: java.lang.IllegalArgumentException: port out of range:-1
> at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143)
> at java.net.InetSocketAddress.(InetSocketAddress.java:224)
> at
> org.apache.cxf.transport.http.netty.client.NettyHttpConduit$NettyWrappedOutputStream.connect(NettyHttpConduit.java:293)
> at
> org.apache.cxf.transport.http.netty.client.NettyHttpConduit$NettyWrappedOutputStream.setupWrappedStream(NettyHttpConduit.java:243)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleHeadersTrustCaching(HTTPConduit.java:1302)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.onFirstWrite(HTTPConduit.java:1258)
> at
> org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:47)
> at
> org.apache.cxf.io.
[jira] [Resolved] (CXF-5747) Add a karaf feature for the websocket transport
[ https://issues.apache.org/jira/browse/CXF-5747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-5747. -- Resolution: Fixed > Add a karaf feature for the websocket transport > --- > > Key: CXF-5747 > URL: https://issues.apache.org/jira/browse/CXF-5747 > Project: CXF > Issue Type: Improvement > Components: OSGi >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 3.0.1 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CXF-5752) Unable to find the target operation when using websocket transport without atmosphere
[ https://issues.apache.org/jira/browse/CXF-5752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-5752. -- Resolution: Fixed > Unable to find the target operation when using websocket transport without > atmosphere > - > > Key: CXF-5752 > URL: https://issues.apache.org/jira/browse/CXF-5752 > Project: CXF > Issue Type: Bug > Components: Transports >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 3.0.1 > > > When publishing a service for the websocket transport in a container without > using atmosphere, the target operation may not be found correctly. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CXF-5752) Unable to find the target operation when using websocket transport without atmosphere
Aki Yoshida created CXF-5752: Summary: Unable to find the target operation when using websocket transport without atmosphere Key: CXF-5752 URL: https://issues.apache.org/jira/browse/CXF-5752 Project: CXF Issue Type: Bug Components: Transports Reporter: Aki Yoshida Assignee: Aki Yoshida Fix For: 3.0.1 When publishing a service for the websocket transport in a container without using atmosphere, the target operation may not be found correctly. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CXF-3272) WS-RM returns Fault for duplicate message received, should probably return acknowledgement instead
[ https://issues.apache.org/jira/browse/CXF-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14002533#comment-14002533 ] Aki Yoshida commented on CXF-3272: -- Hi Dennis, For the oneway case, most clients expect to receive an ack message with the current ack ranges. If you can get this oneway handling working, that would be great. Regarding the request-response case, the response message is queued and its delivery is handled independently of any subsequent retransmission of the original request, right? In that case, I think not including (or triggering) the response as you suggest seems to be the correct behavior. thanks. regards, aki > WS-RM returns Fault for duplicate message received, should probably return > acknowledgement instead > -- > > Key: CXF-3272 > URL: https://issues.apache.org/jira/browse/CXF-3272 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.3.2 >Reporter: Dennis Sosnoski >Assignee: Dennis Sosnoski >Priority: Minor > > The WS-RM Destination code currently throws an exception when a duplicate > message is received if using AtMostOnce or ExactlyOnce delivery assurances. > This gets turned into a Fault which means nothing to the RM Source, and may > interfere with the proper operation of other WS-RM implementations. > A better way to handle this is to return an HTTP 200 OK status (or equivalent > for other transports) along with a SequenceAcknowledgement, so that the RM > Source gets back information to help it in recovery. > For one-way scenarios this can just be returned directly. For two-way > scenarios it should be returned along with a copy of the application response > to the original message (at least if an Offer was included in the original > CreateSequence and accepted by the RM Destination, meaning RM is operating in > both directions of message flow - see the Replay model implemented by Metro, > along with at least some versions of .Net and Axis2/Sandesha2: > http://wso2.org/library/2792). > Metro's handling is interesting. If RM is operating in the response direction > they naturally hold a copy of each response message until acknowledged, but > then even after the message has been acknowledged they use a WeakReference to > keep it available until it is reclaimed by GC. If RM is *not* operating in > the response direction they still appear to keep the response available with > a WeakReference, allowing it to be resent in response to a duplicate message. > That seems like a good approach. > If the response message is not available, is there any reason not to use an > HTTP 200 response and send back a SOAP message with only the > SequenceAcknowledgement? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CXF-3272) WS-RM returns Fault for duplicate message received, should probably return acknowledgement instead
[ https://issues.apache.org/jira/browse/CXF-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14001685#comment-14001685 ] Aki Yoshida commented on CXF-3272: -- Hi Dennis, do you have an update to this item? thanks. regards, aki > WS-RM returns Fault for duplicate message received, should probably return > acknowledgement instead > -- > > Key: CXF-3272 > URL: https://issues.apache.org/jira/browse/CXF-3272 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.3.2 >Reporter: Dennis Sosnoski >Assignee: Dennis Sosnoski >Priority: Minor > > The WS-RM Destination code currently throws an exception when a duplicate > message is received if using AtMostOnce or ExactlyOnce delivery assurances. > This gets turned into a Fault which means nothing to the RM Source, and may > interfere with the proper operation of other WS-RM implementations. > A better way to handle this is to return an HTTP 200 OK status (or equivalent > for other transports) along with a SequenceAcknowledgement, so that the RM > Source gets back information to help it in recovery. > For one-way scenarios this can just be returned directly. For two-way > scenarios it should be returned along with a copy of the application response > to the original message (at least if an Offer was included in the original > CreateSequence and accepted by the RM Destination, meaning RM is operating in > both directions of message flow - see the Replay model implemented by Metro, > along with at least some versions of .Net and Axis2/Sandesha2: > http://wso2.org/library/2792). > Metro's handling is interesting. If RM is operating in the response direction > they naturally hold a copy of each response message until acknowledged, but > then even after the message has been acknowledged they use a WeakReference to > keep it available until it is reclaimed by GC. If RM is *not* operating in > the response direction they still appear to keep the response available with > a WeakReference, allowing it to be resent in response to a duplicate message. > That seems like a good approach. > If the response message is not available, is there any reason not to use an > HTTP 200 response and send back a SOAP message with only the > SequenceAcknowledgement? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CXF-5747) Add a karaf feature for the websocket transport
Aki Yoshida created CXF-5747: Summary: Add a karaf feature for the websocket transport Key: CXF-5747 URL: https://issues.apache.org/jira/browse/CXF-5747 Project: CXF Issue Type: Improvement Components: OSGi Reporter: Aki Yoshida Assignee: Aki Yoshida Fix For: 3.0.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CXF-5746) WebsocketConduit to use the id header so that it can correlate requests and responses
Aki Yoshida created CXF-5746: Summary: WebsocketConduit to use the id header so that it can correlate requests and responses Key: CXF-5746 URL: https://issues.apache.org/jira/browse/CXF-5746 Project: CXF Issue Type: Improvement Components: Transports Reporter: Aki Yoshida Assignee: Aki Yoshida Fix For: 3.0.1 This is a follow up from CXF-5715 to make the websocket conduit to use the ID referencing mechanism so that it can correlate the responses that arrive asynchronously to its requests. In this way, a normal jaxws or jaxrs based request-response services can be invoked using the websocket conduit. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CXF-5698) Use the service root path instead of the initial request path to restrict websocket service access
[ https://issues.apache.org/jira/browse/CXF-5698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida updated CXF-5698: - Fix Version/s: (was: 3.0.0) > Use the service root path instead of the initial request path to restrict > websocket service access > -- > > Key: CXF-5698 > URL: https://issues.apache.org/jira/browse/CXF-5698 > Project: CXF > Issue Type: Improvement > Components: Transports >Reporter: Aki Yoshida >Assignee: Aki Yoshida > > Currently, the URL path used to initiate the websocket connection is used to > allow or restrict the subsequent operations received over the websocket. > This is not convenient as the caller must know the service root path to be > able to invoke all the operations supported by the service. A more convenient > approach would be to use the service root path as the filter so that the > subsequent requests to one of its operations can be processed even if the > initial connection request uses one of these sub resource paths. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CXF-5715) Add a conduit part to WebSocket transport
[ https://issues.apache.org/jira/browse/CXF-5715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-5715. -- Resolution: Fixed I close this ticked as resolved with the limitation that is mentioned in my comment entry. will follow up in the binding and id-refid topics after 3.0.0. > Add a conduit part to WebSocket transport > - > > Key: CXF-5715 > URL: https://issues.apache.org/jira/browse/CXF-5715 > Project: CXF > Issue Type: New Feature > Components: Transports >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 3.0.0 > > > adding an AHC/Netty version of conduit to the websocket transport. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CXF-5604) Add atmosphere based implementation in websocket transport
[ https://issues.apache.org/jira/browse/CXF-5604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-5604. -- Resolution: Fixed Fix Version/s: 3.0.0 > Add atmosphere based implementation in websocket transport > -- > > Key: CXF-5604 > URL: https://issues.apache.org/jira/browse/CXF-5604 > Project: CXF > Issue Type: Improvement > Components: Transports >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 3.0.0 > > > Adding an atmosphere based destination in rt-transports-websocket (CXF-5339) > so that it can be used with other web containers such as tomcat. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CXF-5679) WS-S after upgrade fails with org.apache.ws.security.WSSecurityException: The signature or decryption was invalid
[
https://issues.apache.org/jira/browse/CXF-5679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aki Yoshida updated CXF-5679:
-
Attachment: ParseBodyTest.java
an updated file to show the initial/trailing whitespace cases that i meant.
> WS-S after upgrade fails with org.apache.ws.security.WSSecurityException: The
> signature or decryption was invalid
> -
>
> Key: CXF-5679
> URL: https://issues.apache.org/jira/browse/CXF-5679
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 2.7.9, 2.7.10
>Reporter: Ján Ondrušek
>Assignee: Colm O hEigeartaigh
> Labels: security
> Attachments: ParseBodyTest.java, bad-request-formatted.xml,
> bad-run.txt, example-test.diff, good-request-formatted.xml, log.txt,
> test-soapui-project.xml
>
>
> After upgrading CXF from version 2.7.5 to 2.7.9 or higher, we experienced
> this issue. Worked well with 2.7.5 and earlier.
> Request (our business data stripped and replaced with dummy ns1):
> {code:xml}
> http://example/soap";
> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
>
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
>
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";>
>xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>
>
>
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#";>
>PrefixList="ns1 soapenv"
>
> xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"; />
>
>Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"; />
>
>
>Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#";>
>
>
> xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"; />
>
>
>Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"; />
>
> VF0g31FSsHWpdMN7lGVgQA1li4c=
>
>
>
>Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#";>
>
>
> xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"; />
>
>
>Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"; />
>
> 4yW2ssYnI+QB40HBdWexy80+GNo=
>
>
>
> QGIDsbR//zUyjUD36LtkiMJsIiT1vYionG8Y0blqif2QKrMB2AHnr9KXiYy7MbcdMaTVxn6gmKGN
>
> 7bRjE6MX1VVf9ZPem5SfasHYQ6wS7l/I1NGUyGw227cv1AceDPje05Wjk5vmN9G1dKvbfECJhBLA
> 7/OBAxJI+TYmYe94cu8=
>Id="KI-6788C4A756C88F877313970392940">
>
> wsu:Id="STR-6788C4A756C88F877313970392941">
>
>
>
> CN=clientuser
>
> 1288174342
>
>
>
>
>
>
>
> 2014-04-09T10:28:14.554Z
>
> 2014-04-09T10:33:14.554Z
>
>
>
>
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";>
>
[jira] [Updated] (CXF-5679) WS-S after upgrade fails with org.apache.ws.security.WSSecurityException: The signature or decryption was invalid
[
https://issues.apache.org/jira/browse/CXF-5679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aki Yoshida updated CXF-5679:
-
Attachment: (was: ParseBodyTest.java)
> WS-S after upgrade fails with org.apache.ws.security.WSSecurityException: The
> signature or decryption was invalid
> -
>
> Key: CXF-5679
> URL: https://issues.apache.org/jira/browse/CXF-5679
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 2.7.9, 2.7.10
>Reporter: Ján Ondrušek
>Assignee: Colm O hEigeartaigh
> Labels: security
> Attachments: bad-request-formatted.xml, bad-run.txt,
> example-test.diff, good-request-formatted.xml, log.txt,
> test-soapui-project.xml
>
>
> After upgrading CXF from version 2.7.5 to 2.7.9 or higher, we experienced
> this issue. Worked well with 2.7.5 and earlier.
> Request (our business data stripped and replaced with dummy ns1):
> {code:xml}
> http://example/soap";
> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
>
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
>
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";>
>xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>
>
>
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#";>
>PrefixList="ns1 soapenv"
>
> xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"; />
>
>Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"; />
>
>
>Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#";>
>
>
> xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"; />
>
>
>Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"; />
>
> VF0g31FSsHWpdMN7lGVgQA1li4c=
>
>
>
>Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#";>
>
>
> xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"; />
>
>
>Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"; />
>
> 4yW2ssYnI+QB40HBdWexy80+GNo=
>
>
>
> QGIDsbR//zUyjUD36LtkiMJsIiT1vYionG8Y0blqif2QKrMB2AHnr9KXiYy7MbcdMaTVxn6gmKGN
>
> 7bRjE6MX1VVf9ZPem5SfasHYQ6wS7l/I1NGUyGw227cv1AceDPje05Wjk5vmN9G1dKvbfECJhBLA
> 7/OBAxJI+TYmYe94cu8=
>Id="KI-6788C4A756C88F877313970392940">
>
> wsu:Id="STR-6788C4A756C88F877313970392941">
>
>
>
> CN=clientuser
>
> 1288174342
>
>
>
>
>
>
>
> 2014-04-09T10:28:14.554Z
>
> 2014-04-09T10:33:14.554Z
>
>
>
>
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";>
>
>
>
> {code}
> Response:
> {code:xml}
> http://schemas.xmlsoap.org/soap/
[jira] [Updated] (CXF-5679) WS-S after upgrade fails with org.apache.ws.security.WSSecurityException: The signature or decryption was invalid
[
https://issues.apache.org/jira/browse/CXF-5679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aki Yoshida updated CXF-5679:
-
Attachment: ParseBodyTest.java
I think StaxUtils.copy using SAAJStreamWriter loses the initial and trailing
whitespace/newline info, which is, in contrast, preserved when using
StaxUtils.readDocElements.
I'm attaching a simpler unit test (ParseBodyTest) for trunk to show this issue.
> WS-S after upgrade fails with org.apache.ws.security.WSSecurityException: The
> signature or decryption was invalid
> -
>
> Key: CXF-5679
> URL: https://issues.apache.org/jira/browse/CXF-5679
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 2.7.9, 2.7.10
>Reporter: Ján Ondrušek
>Assignee: Colm O hEigeartaigh
> Labels: security
> Attachments: ParseBodyTest.java, bad-request-formatted.xml,
> bad-run.txt, example-test.diff, good-request-formatted.xml, log.txt,
> test-soapui-project.xml
>
>
> After upgrading CXF from version 2.7.5 to 2.7.9 or higher, we experienced
> this issue. Worked well with 2.7.5 and earlier.
> Request (our business data stripped and replaced with dummy ns1):
> {code:xml}
> http://example/soap";
> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
>
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
>
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";>
>xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>
>
>
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#";>
>PrefixList="ns1 soapenv"
>
> xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"; />
>
>Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"; />
>
>
>Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#";>
>
>
> xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"; />
>
>
>Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"; />
>
> VF0g31FSsHWpdMN7lGVgQA1li4c=
>
>
>
>Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#";>
>
>
> xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"; />
>
>
>Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"; />
>
> 4yW2ssYnI+QB40HBdWexy80+GNo=
>
>
>
> QGIDsbR//zUyjUD36LtkiMJsIiT1vYionG8Y0blqif2QKrMB2AHnr9KXiYy7MbcdMaTVxn6gmKGN
>
> 7bRjE6MX1VVf9ZPem5SfasHYQ6wS7l/I1NGUyGw227cv1AceDPje05Wjk5vmN9G1dKvbfECJhBLA
> 7/OBAxJI+TYmYe94cu8=
>Id="KI-6788C4A756C88F877313970392940">
>
> wsu:Id="STR-6788C4A756C88F877313970392941">
>
>
>
> CN=clientuser
>
> 1288174342
>
>
>
>
>
>
>
> 2014-04-09T10:28:14.554Z
>
> 2014-04-09T10:33:14.554Z
>
[jira] [Resolved] (CXF-5711) SOAP 1.2 fault reason xml:lang attribute should follow XML standard
[ https://issues.apache.org/jira/browse/CXF-5711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-5711. -- Resolution: Fixed Fix Version/s: 2.7.12 2.6.15 applied the patch provided by Iris with a minor modification, where the old parsing behavior (accepting the java's conventional delimiter) is additionally preserved for 2.7.x and 2.6.x. Thanks. > SOAP 1.2 fault reason xml:lang attribute should follow XML standard > > > Key: CXF-5711 > URL: https://issues.apache.org/jira/browse/CXF-5711 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Affects Versions: 3.0.0-milestone1, 2.7.10, 2.6.14 >Reporter: iris ding >Assignee: Aki Yoshida > Fix For: 2.6.15, 2.7.12, 3.0.0 > > Attachments: 5711.patch > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CXF-5711) SOAP 1.2 fault reason xml:lang attribute should follow XML standard
[ https://issues.apache.org/jira/browse/CXF-5711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13984182#comment-13984182 ] Aki Yoshida edited comment on CXF-5711 at 4/29/14 10:35 AM: Hi Iris, it's all clear. sorry for the delay. I needed to discuss with Alessio, whether to keep the old java's conventional parsing (i.e., accepting the underscore) in the corrected code or to ignore this underscore in the parsing part. We decided to drop the conventional parsing (the wrong one) in 3.0.0 but keep it in 2.7.x/2.6.x so that the those newer 2.7.x/2.6.x can interoperate with the older cxf 2.7.x/2.6.x versions that used the java's conventional parsing I'll commit the patch shortly. regards, aki was (Author: ay): Hi Iris, it's all clear. sorry for the delay. I needed to discuss with Alessio, whether to keep the old java's conventional parsing (i.e., not accepting the underscore) in the corrected code or to ignore the underscore syntax. We decided to drop the conventional parsing (the wrong one) in 3.0.0 but keep it in 2.7.x/2.6.x so that the those newer 2.7.x/2.6.x can interoperate with the older cxf 2.7.x/2.6.x versions that used the java's conventional parsing I'll commit the patch shortly. regards, aki > SOAP 1.2 fault reason xml:lang attribute should follow XML standard > > > Key: CXF-5711 > URL: https://issues.apache.org/jira/browse/CXF-5711 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Affects Versions: 3.0.0-milestone1, 2.7.10, 2.6.14 >Reporter: iris ding >Assignee: Aki Yoshida > Fix For: 3.0.0 > > Attachments: 5711.patch > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CXF-5711) SOAP 1.2 fault reason xml:lang attribute should follow XML standard
[ https://issues.apache.org/jira/browse/CXF-5711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13984182#comment-13984182 ] Aki Yoshida commented on CXF-5711: -- Hi Iris, it's all clear. sorry for the delay. I needed to discuss with Alessio, whether to keep the old java's conventional parsing (i.e., not accepting the underscore) in the corrected code or to ignore the underscore syntax. We decided to drop the conventional parsing (the wrong one) in 3.0.0 but keep it in 2.7.x/2.6.x so that the those newer 2.7.x/2.6.x can interoperate with the older cxf 2.7.x/2.6.x versions that used the java's conventional parsing I'll commit the patch shortly. regards, aki > SOAP 1.2 fault reason xml:lang attribute should follow XML standard > > > Key: CXF-5711 > URL: https://issues.apache.org/jira/browse/CXF-5711 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Affects Versions: 3.0.0-milestone1, 2.7.10, 2.6.14 >Reporter: iris ding >Assignee: Aki Yoshida > Fix For: 3.0.0 > > Attachments: 5711.patch > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CXF-5715) Add a conduit part to WebSocket transport
[ https://issues.apache.org/jira/browse/CXF-5715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13982986#comment-13982986 ] Aki Yoshida commented on CXF-5715: -- Hi Sergey, yes. we have some interesting part (bindings) to work on. :-) for cxf's default binding, we need to add a Id-refId mechanism so that a request-reply reliably works. Right now, we use no Id header, so we have FIFO. for other standard bindings, I can work on the .net websocket binding. That should not be complicated. I just don't know if this binding is really useful (as it is not taking advantage of websocket), but from the interop point of view, it may be interesting so that we can claim cxf interoperates with .net' websocket ;-) regards, aki > Add a conduit part to WebSocket transport > - > > Key: CXF-5715 > URL: https://issues.apache.org/jira/browse/CXF-5715 > Project: CXF > Issue Type: New Feature > Components: Transports >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 3.0.0 > > > adding an AHC/Netty version of conduit to the websocket transport. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CXF-5715) Add a conduit part to WebSocket transport
[ https://issues.apache.org/jira/browse/CXF-5715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13982880#comment-13982880 ] Aki Yoshida commented on CXF-5715: -- hi, just committed a conduit implementation that matches (interoperates with) the current server side websocket transport in CXF (CXF-5339, CXF-5604). an integration test case is located in systests/jaxrs ;-) > Add a conduit part to WebSocket transport > - > > Key: CXF-5715 > URL: https://issues.apache.org/jira/browse/CXF-5715 > Project: CXF > Issue Type: New Feature > Components: Transports >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 3.0.0 > > > adding an AHC/Netty version of conduit to the websocket transport. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CXF-5715) Add a conduit part to WebSocket transport
Aki Yoshida created CXF-5715: Summary: Add a conduit part to WebSocket transport Key: CXF-5715 URL: https://issues.apache.org/jira/browse/CXF-5715 Project: CXF Issue Type: New Feature Components: Transports Reporter: Aki Yoshida Assignee: Aki Yoshida Fix For: 3.0.0 adding an AHC/Netty version of conduit to the websocket transport. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CXF-5711) SOAP 1.2 fault reason xml:lang attribute should follow XML standard
[ https://issues.apache.org/jira/browse/CXF-5711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida reassigned CXF-5711: Assignee: Aki Yoshida > SOAP 1.2 fault reason xml:lang attribute should follow XML standard > > > Key: CXF-5711 > URL: https://issues.apache.org/jira/browse/CXF-5711 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Affects Versions: 3.0.0-milestone1, 2.7.10, 2.6.14 >Reporter: iris ding >Assignee: Aki Yoshida > Fix For: 3.0.0 > > Attachments: 5711.patch > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CXF-5711) SOAP 1.2 fault reason xml:lang attribute should follow XML standard
[ https://issues.apache.org/jira/browse/CXF-5711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13980870#comment-13980870 ] Aki Yoshida commented on CXF-5711: -- in jdk6, Locale.toString() generates the underscored string (e.g.. en_US). in jdk7, there is a method toLanguateTag() that generates the IETF BCP 47 language tag (eg. en-US). so if we correct the tag format to the IETF format, we need to manually do this step to support jdk6. > SOAP 1.2 fault reason xml:lang attribute should follow XML standard > > > Key: CXF-5711 > URL: https://issues.apache.org/jira/browse/CXF-5711 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Affects Versions: 3.0.0-milestone1, 2.7.10, 2.6.14 >Reporter: iris ding > Fix For: 3.0.0 > > Attachments: 5711.patch > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CXF-5479) Create a Maven plugin for generating WADL at build time
[ https://issues.apache.org/jira/browse/CXF-5479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13980857#comment-13980857 ] Aki Yoshida commented on CXF-5479: -- hi, is this build working on OSX JDK6? I'm getting this error. [ERROR] Failed to execute goal on project cxf-java2wadl-plugin: Could not resolve dependencies for project org.apache.cxf:cxf-java2wadl-plugin:maven-plugin:3.0.0-SNAPSHOT: Could not find artifact com.sun:tools:jar:1.6.0 at specified path /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/../lib/tools.jar -> [Help 1] [ERROR] i see this reference coming from java2wadl-plugin/pom.xml and i am not sure if this referencing is supposed to work on some systems. > Create a Maven plugin for generating WADL at build time > --- > > Key: CXF-5479 > URL: https://issues.apache.org/jira/browse/CXF-5479 > Project: CXF > Issue Type: New Feature > Components: JAX-RS >Reporter: Sergey Beryozkin >Assignee: Freeman Fang > Fix For: 3.0.0 > > Attachments: CXF-5479-doclet.patch, CXF-5479.patch > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CXF-5709) WSRM 1.1 TerminateSequence should not overwrite the default replyTo to none
[ https://issues.apache.org/jira/browse/CXF-5709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-5709. -- Resolution: Fixed Fix Version/s: 3.0.0 2.7.12 2.6.15 > WSRM 1.1 TerminateSequence should not overwrite the default replyTo to none > --- > > Key: CXF-5709 > URL: https://issues.apache.org/jira/browse/CXF-5709 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.7.11, 2.6.14 >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 2.6.15, 2.7.12, 3.0.0 > > > CXF currently overwrites the replyTo header of the TerminateSequence message > to none for both WSRM 1.0 and 1.1, implying no response is to be returned. > However, RM 1.1 defines the TerminateSequenceResponse message and expects the > response message to the TerminateSequence. Therefore, the replyTo header > should not be overwritten to none. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CXF-5709) WSRM 1.1 TerminateSequence should not overwrite the default replyTo to none
Aki Yoshida created CXF-5709: Summary: WSRM 1.1 TerminateSequence should not overwrite the default replyTo to none Key: CXF-5709 URL: https://issues.apache.org/jira/browse/CXF-5709 Project: CXF Issue Type: Bug Components: WS-* Components Affects Versions: 2.6.14, 2.7.11 Reporter: Aki Yoshida Assignee: Aki Yoshida CXF currently overwrites the replyTo header of the TerminateSequence message to none for both WSRM 1.0 and 1.1, implying no response is to be returned. However, RM 1.1 defines the TerminateSequenceResponse message and expects the response message to the TerminateSequence. Therefore, the replyTo header should not be overwritten to none. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CXF-5698) Use the service root path instead of the initial request path to restrict websocket service access
[ https://issues.apache.org/jira/browse/CXF-5698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13973061#comment-13973061 ] Aki Yoshida edited comment on CXF-5698 at 4/17/14 3:48 PM: --- Hi Sergey, The original intention was, let's say, using the example in systests/jaxrs, to start with "/websocket/web/bookstore/books/123" to open a socket connection and use this socket connection to call another operation "/websocket/web/bookstore/booknames". Currently, this is failing. I stumbled on this problem, when I wrote the client part (i.e., conduit) that used the operation URL path in the initial socket open request. But it turned out, it seems not so simple to determine the service root path "/websocket/web/bookstore" (not the deployed endpoint path "/websocket" but that path followed by the annotated path name of the service class) without checking the deployed jaxrs resource. So I will drop this patch/change and instead, assume the client to be smart enough (e.g., it has the resource description) and knows the service root path "/websocket/web/bookstore" so that it can issue the correct socket open request. regards, aki was (Author: ay): Hi Sergey, The original intention was, let's say, using the example in systests/jaxrs, to start with "/websocket/web/bookstore/books/123" to open a socket connection and use this socket connection to call another operation "/websocket/web/bookstore/booknames". Currently, this is failing. I stumbled on this problem, when I wrote the client part (i.e., conduit) that used the operation URL path in the initial socket open request. But it turned out, it seems not so simple to determine the service root path "/websocket/web/bookstore" (not the endpoint path) without checking the deployed jaxrs resource. So I will drop this patch/change and instead, assume the client to be smart enough (e.g., it has the resource description) and knows the service root path "/websocket/web/bookstore" so that it can issue the correct socket open request. regards, aki > Use the service root path instead of the initial request path to restrict > websocket service access > -- > > Key: CXF-5698 > URL: https://issues.apache.org/jira/browse/CXF-5698 > Project: CXF > Issue Type: Improvement > Components: Transports >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 3.0.0 > > > Currently, the URL path used to initiate the websocket connection is used to > allow or restrict the subsequent operations received over the websocket. > This is not convenient as the caller must know the service root path to be > able to invoke all the operations supported by the service. A more convenient > approach would be to use the service root path as the filter so that the > subsequent requests to one of its operations can be processed even if the > initial connection request uses one of these sub resource paths. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CXF-5698) Use the service root path instead of the initial request path to restrict websocket service access
[ https://issues.apache.org/jira/browse/CXF-5698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13973061#comment-13973061 ] Aki Yoshida commented on CXF-5698: -- Hi Sergey, The original intention was, let's say, using the example in systests/jaxrs, to start with "/websocket/web/bookstore/books/123" to open a socket connection and use this socket connection to call another operation "/websocket/web/bookstore/booknames". Currently, this is failing. I stumbled on this problem, when I wrote the client part (i.e., conduit) that used the operation URL path in the initial socket open request. But it turned out, it seems not so simple to determine the service root path "/websocket/web/bookstore" (not the endpoint path) without checking the deployed jaxrs resource. So I will drop this patch/change and instead, assume the client to be smart enough (e.g., it has the resource description) and knows the service root path "/websocket/web/bookstore" so that it can issue the correct socket open request. regards, aki > Use the service root path instead of the initial request path to restrict > websocket service access > -- > > Key: CXF-5698 > URL: https://issues.apache.org/jira/browse/CXF-5698 > Project: CXF > Issue Type: Improvement > Components: Transports >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 3.0.0 > > > Currently, the URL path used to initiate the websocket connection is used to > allow or restrict the subsequent operations received over the websocket. > This is not convenient as the caller must know the service root path to be > able to invoke all the operations supported by the service. A more convenient > approach would be to use the service root path as the filter so that the > subsequent requests to one of its operations can be processed even if the > initial connection request uses one of these sub resource paths. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CXF-5698) Use the service root path instead of the initial request path to restrict websocket service access
Aki Yoshida created CXF-5698: Summary: Use the service root path instead of the initial request path to restrict websocket service access Key: CXF-5698 URL: https://issues.apache.org/jira/browse/CXF-5698 Project: CXF Issue Type: Improvement Components: Transports Reporter: Aki Yoshida Assignee: Aki Yoshida Fix For: 3.0.0 Currently, the URL path used to initiate the websocket connection is used to allow or restrict the subsequent operations received over the websocket. This is not convenient as the caller must know the service root path to be able to invoke all the operations supported by the service. A more convenient approach would be to use the service root path as the filter so that the subsequent requests to one of its operations can be processed even if the initial connection request uses one of these sub resource paths. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CXF-5676) IllegalArgumentException: wrong number of arguments while invoking operation with only an implicit header parameter
[
https://issues.apache.org/jira/browse/CXF-5676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aki Yoshida resolved CXF-5676.
--
Resolution: Fixed
Fix Version/s: 3.0.0
2.7.12
2.6.15
I committed the fix including a slightly modified version of the test case
provided by Andreas.
> IllegalArgumentException: wrong number of arguments while invoking operation
> with only an implicit header parameter
> ---
>
> Key: CXF-5676
> URL: https://issues.apache.org/jira/browse/CXF-5676
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.0-milestone2, 2.7.10
>Reporter: Andreas Gudian
>Assignee: Aki Yoshida
> Fix For: 2.6.15, 2.7.12, 3.0.0
>
> Attachments: implicit-header-with-no-args.zip
>
>
> I have an operation with no arguments, only an implicit header with direction
> {{IN}}. Calling the operation fails:
> {code}
> javax.xml.ws.soap.SOAPFaultException: wrong number of arguments while
> invoking public java.util.List
> sample.ImplicitHeaderWithExtSoapHeaderINSampleTest$ImplicitHeaderSampleImplementation.operationWithNoArgs(com.sample.audit.Audit)
> with params [com.sample.audit.Audit@c19fbf, com.sample.audit.Audit@c19fbf].
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:159)
> {code}
> It works for operations with non-empty parameters and when the implicit
> header has direction INOUT.
> I'll attach a sample that demonstrates the issue.
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CXF-5677) Operation without body but non empty header causes IllegalArgumentException
[
https://issues.apache.org/jira/browse/CXF-5677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aki Yoshida resolved CXF-5677.
--
Resolution: Fixed
Fix Version/s: 3.0.0
2.7.12
2.6.15
Assignee: Aki Yoshida
> Operation without body but non empty header causes IllegalArgumentException
> ---
>
> Key: CXF-5677
> URL: https://issues.apache.org/jira/browse/CXF-5677
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.7.5, 2.7.10
>Reporter: Ørjan Mjelde
>Assignee: Aki Yoshida
> Fix For: 2.6.15, 2.7.12, 3.0.0
>
> Attachments: CXF-5677-cxf-wrong-number-of-arguments.zip
>
>
> Hi, we have a web service operation with an empty body but with a header. The
> header is defined in a separate name space and xsd. The service is exposed
> and accessed using JAX-WS.
> When called we get an IllegalArgumentException with message, "Wrong number of
> arguments".
> Attached is a maven project with the service definitions and a unit test
> reproducing the issue.
> The stack trace is as follows:
> {code}
> WARNING: Application
> {http://example.com/products/v1}ProductInfoService#{http://example.com/products/v1}getProducts
> has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: wrong number of arguments while invoking
> public java.util.List
> com.example.ProductInfoSEI.getProducts(com.example.meta.v2.Head) with params
> [com.example.meta.v2.Head@184f8b33, com.example.meta.v2.Head@184f8b33].
> at
> org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:174)
>
> at
> org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMethodInvoker.java:272)
>
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:148)
>
> at
> org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:237)
>
> at
> org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:68)
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:75)
>
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58)
>
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
>
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:107)
>
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
>
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
>
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:355)
>
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:319)
>
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:72)
>
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1088)
>
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1024)
>
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
>
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>
> at org.eclipse.jetty.server.Server.handle(Server.java:370)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
>
> at
> org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982)
>
> at
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043)
>
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)
> at
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
> at
> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
>
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)
>
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
>
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>
> at java.lang.Thread.run(Thread.java:724
[jira] [Commented] (CXF-5677) Operation without body but non empty header causes IllegalArgumentException
[
https://issues.apache.org/jira/browse/CXF-5677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13969328#comment-13969328
]
Aki Yoshida commented on CXF-5677:
--
I think this is a duplicate of CXF-5676 and the fix is currently in
3.0.0-SNAPSHOT for testing.
> Operation without body but non empty header causes IllegalArgumentException
> ---
>
> Key: CXF-5677
> URL: https://issues.apache.org/jira/browse/CXF-5677
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.7.5, 2.7.10
>Reporter: Ørjan Mjelde
> Attachments: CXF-5677-cxf-wrong-number-of-arguments.zip
>
>
> Hi, we have a web service operation with an empty body but with a header. The
> header is defined in a separate name space and xsd. The service is exposed
> and accessed using JAX-WS.
> When called we get an IllegalArgumentException with message, "Wrong number of
> arguments".
> Attached is a maven project with the service definitions and a unit test
> reproducing the issue.
> The stack trace is as follows:
> {code}
> WARNING: Application
> {http://example.com/products/v1}ProductInfoService#{http://example.com/products/v1}getProducts
> has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: wrong number of arguments while invoking
> public java.util.List
> com.example.ProductInfoSEI.getProducts(com.example.meta.v2.Head) with params
> [com.example.meta.v2.Head@184f8b33, com.example.meta.v2.Head@184f8b33].
> at
> org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:174)
>
> at
> org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMethodInvoker.java:272)
>
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:148)
>
> at
> org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:237)
>
> at
> org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:68)
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:75)
>
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58)
>
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
>
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:107)
>
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
>
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
>
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:355)
>
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:319)
>
> at
> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:72)
>
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1088)
>
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1024)
>
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
>
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>
> at org.eclipse.jetty.server.Server.handle(Server.java:370)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
>
> at
> org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982)
>
> at
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043)
>
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)
> at
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
> at
> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
>
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)
>
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
>
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>
> at java.lang.Thread.run(Thread.java:724)
> Caused by: java.lang.IllegalArgumentException: wrong numb
[jira] [Assigned] (CXF-5676) IllegalArgumentException: wrong number of arguments while invoking operation with only an implicit header parameter
[
https://issues.apache.org/jira/browse/CXF-5676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aki Yoshida reassigned CXF-5676:
Assignee: Aki Yoshida
> IllegalArgumentException: wrong number of arguments while invoking operation
> with only an implicit header parameter
> ---
>
> Key: CXF-5676
> URL: https://issues.apache.org/jira/browse/CXF-5676
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.0-milestone2, 2.7.10
>Reporter: Andreas Gudian
>Assignee: Aki Yoshida
> Attachments: implicit-header-with-no-args.zip
>
>
> I have an operation with no arguments, only an implicit header with direction
> {{IN}}. Calling the operation fails:
> {code}
> javax.xml.ws.soap.SOAPFaultException: wrong number of arguments while
> invoking public java.util.List
> sample.ImplicitHeaderWithExtSoapHeaderINSampleTest$ImplicitHeaderSampleImplementation.operationWithNoArgs(com.sample.audit.Audit)
> with params [com.sample.audit.Audit@c19fbf, com.sample.audit.Audit@c19fbf].
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:159)
> {code}
> It works for operations with non-empty parameters and when the implicit
> header has direction INOUT.
> I'll attach a sample that demonstrates the issue.
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CXF-5676) IllegalArgumentException: wrong number of arguments while invoking operation with only an implicit header parameter
[
https://issues.apache.org/jira/browse/CXF-5676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13964178#comment-13964178
]
Aki Yoshida commented on CXF-5676:
--
there seems to be some irregularity in the processing when there is no body. I
see the header part inserted into the arguments list twice for some reason and
that seems to be leading to this error.
> IllegalArgumentException: wrong number of arguments while invoking operation
> with only an implicit header parameter
> ---
>
> Key: CXF-5676
> URL: https://issues.apache.org/jira/browse/CXF-5676
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.0-milestone2, 2.7.10
>Reporter: Andreas Gudian
> Attachments: implicit-header-with-no-args.zip
>
>
> I have an operation with no arguments, only an implicit header with direction
> {{IN}}. Calling the operation fails:
> {code}
> javax.xml.ws.soap.SOAPFaultException: wrong number of arguments while
> invoking public java.util.List
> sample.ImplicitHeaderWithExtSoapHeaderINSampleTest$ImplicitHeaderSampleImplementation.operationWithNoArgs(com.sample.audit.Audit)
> with params [com.sample.audit.Audit@c19fbf, com.sample.audit.Audit@c19fbf].
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:159)
> {code}
> It works for operations with non-empty parameters and when the implicit
> header has direction INOUT.
> I'll attach a sample that demonstrates the issue.
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CXF-5611) [joda-time] different versions in maven and feature descriptor
[ https://issues.apache.org/jira/browse/CXF-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13937553#comment-13937553 ] Aki Yoshida commented on CXF-5611: -- Hi Freeman, sure. I somehow missed the original intention of Alexey who was talking about the karaf feature. Sorry for my confusion. Please go ahead with the change. regards, aki > [joda-time] different versions in maven and feature descriptor > -- > > Key: CXF-5611 > URL: https://issues.apache.org/jira/browse/CXF-5611 > Project: CXF > Issue Type: Bug > Components: Build system >Affects Versions: 2.7.11 >Reporter: Alexey Markevich >Assignee: Freeman Fang > Attachments: CXF-5611.zip > > > I have a project which depends on cxf-rt-security [1]. After the build there > is > Import-Package: org.joda.time;version="[2.2,3)" > But after deploy to karaf got > Reason: Missing Constraint: Import-Package: org.joda.time; > version="[2.2.0,3.0.0)" > because wss4j feature contains [2] > 1. > [INFO] \- org.apache.cxf:cxf-rt-security:jar:2.7.11-SNAPSHOT:compile > [INFO]+- org.opensaml:opensaml:jar:2.6.1:compile > [INFO]| +- joda-time:joda-time:jar:2.2:compile > 2. > dependency="true">mvn:joda-time/joda-time/2.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CXF-5611) [joda-time] different versions in maven and feature descriptor
[ https://issues.apache.org/jira/browse/CXF-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13935160#comment-13935160 ] Aki Yoshida commented on CXF-5611: -- Hi Freeman, Shouldn't Alexey's project itself add the corresponding imports to override what is derived from the compile time dependency? e.g. adding org.joda.time;version="[1.6,3)" cxf-rt-security itself has the correct import dependency to accept a lower version of joda than 2.2. Or are you suggesting to change the compile time dependency of 2.7.11's cxf-rt-security? regards, aki > [joda-time] different versions in maven and feature descriptor > -- > > Key: CXF-5611 > URL: https://issues.apache.org/jira/browse/CXF-5611 > Project: CXF > Issue Type: Bug > Components: Build system >Affects Versions: 2.7.11 >Reporter: Alexey Markevich >Assignee: Freeman Fang > Attachments: CXF-5611.zip > > > I have a project which depends on cxf-rt-security [1]. After the build there > is > Import-Package: org.joda.time;version="[2.2,3)" > But after deploy to karaf got > Reason: Missing Constraint: Import-Package: org.joda.time; > version="[2.2.0,3.0.0)" > because wss4j feature contains [2] > 1. > [INFO] \- org.apache.cxf:cxf-rt-security:jar:2.7.11-SNAPSHOT:compile > [INFO]+- org.opensaml:opensaml:jar:2.6.1:compile > [INFO]| +- joda-time:joda-time:jar:2.2:compile > 2. > dependency="true">mvn:joda-time/joda-time/2.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CXF-5546) NPE may be thrown and logged during WS-RM's retransmission
[ https://issues.apache.org/jira/browse/CXF-5546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-5546. -- Resolution: Fixed Fix Version/s: 2.7.11 3.0.0 > NPE may be thrown and logged during WS-RM's retransmission > -- > > Key: CXF-5546 > URL: https://issues.apache.org/jira/browse/CXF-5546 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.7.9 >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 3.0.0, 2.7.11 > > > While a message is being retransmitted from a client (RM-Source) from its > retransmission queue, the corresponding message might be acknowledged and its > resource released at the client. And in this case, an NPE will be thrown > during the resending of the message. > Feb 5, 2014 5:48:32 PM org.apache.cxf.ws.rm.soap.RetransmissionQueueImpl$3 > resend > WARNING: WS-RM retransmission failed. > java.lang.NullPointerException > at java.io.ByteArrayInputStream.(ByteArrayInputStream.java:89) > at > org.apache.cxf.ws.rm.soap.RetransmissionQueueImpl.resend(RetransmissionQueueImpl.java:461) > at > org.apache.cxf.ws.rm.soap.RetransmissionQueueImpl.clientResend(RetransmissionQueueImpl.java:371) > at > org.apache.cxf.ws.rm.soap.RetransmissionQueueImpl.access$400(RetransmissionQueueImpl.java:80) > at > org.apache.cxf.ws.rm.soap.RetransmissionQueueImpl$3.resend(RetransmissionQueueImpl.java:768) > at > org.apache.cxf.ws.rm.soap.RetransmissionQueueImpl$ResendCandidate.run(RetransmissionQueueImpl.java:577) > at > org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) > at > org.apache.cxf.ws.rm.soap.RetransmissionQueueImpl$ResendCandidate.initiate(RetransmissionQueueImpl.java:565) > at > org.apache.cxf.ws.rm.soap.RetransmissionQueueImpl$ResendCandidate$1ResendTask.run(RetransmissionQueueImpl.java:724) > at java.util.TimerThread.mainLoop(Timer.java:512) > at java.util.TimerThread.run(Timer.java:462) > Note that this issue is about handling this case gracefully to avoid throwing > an NPE. The issue itself does not break the delivery guarantee semantics as > the resend is failing because the message has been acknowledged. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CXF-5614) CachedOutputStream may fail to read the data when encryption is turned on
[ https://issues.apache.org/jira/browse/CXF-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-5614. -- Resolution: Fixed > CachedOutputStream may fail to read the data when encryption is turned on > - > > Key: CXF-5614 > URL: https://issues.apache.org/jira/browse/CXF-5614 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.0.0-milestone2, 2.7.10 >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 3.0.0, 2.7.11 > > > CachedOutputStream which is used to cache large data in the file system may > fail to read the file-cached data when its cipher transformation is enabled. > The problem occurs when two threads are reading from the cached file or one > thread is reading from the cached file after another thread partially read > the data. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CXF-5614) CachedOutputStream may fail to read the data when encryption is turned on
[ https://issues.apache.org/jira/browse/CXF-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida updated CXF-5614: - Affects Version/s: 3.0.0-milestone2 > CachedOutputStream may fail to read the data when encryption is turned on > - > > Key: CXF-5614 > URL: https://issues.apache.org/jira/browse/CXF-5614 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.0.0-milestone2, 2.7.10 >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 3.0.0, 2.7.11 > > > CachedOutputStream which is used to cache large data in the file system may > fail to read the file-cached data when its cipher transformation is enabled. > The problem occurs when two threads are reading from the cached file or one > thread is reading from the cached file after another thread partially read > the data. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CXF-5614) CachedOutputStream may fail to read the data when encryption is turned on
[ https://issues.apache.org/jira/browse/CXF-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida updated CXF-5614: - Fix Version/s: 2.7.11 3.0.0 > CachedOutputStream may fail to read the data when encryption is turned on > - > > Key: CXF-5614 > URL: https://issues.apache.org/jira/browse/CXF-5614 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 2.7.10 >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 3.0.0, 2.7.11 > > > CachedOutputStream which is used to cache large data in the file system may > fail to read the file-cached data when its cipher transformation is enabled. > The problem occurs when two threads are reading from the cached file or one > thread is reading from the cached file after another thread partially read > the data. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CXF-5614) CachedOutputStream may fail to read the data when encryption is turned on
[ https://issues.apache.org/jira/browse/CXF-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida updated CXF-5614: - Affects Version/s: (was: 2.6.12) > CachedOutputStream may fail to read the data when encryption is turned on > - > > Key: CXF-5614 > URL: https://issues.apache.org/jira/browse/CXF-5614 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 2.7.10 >Reporter: Aki Yoshida >Assignee: Aki Yoshida > > CachedOutputStream which is used to cache large data in the file system may > fail to read the file-cached data when its cipher transformation is enabled. > The problem occurs when two threads are reading from the cached file or one > thread is reading from the cached file after another thread partially read > the data. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CXF-5614) CachedOutputStream may fail to read the data when encryption is turned on
Aki Yoshida created CXF-5614: Summary: CachedOutputStream may fail to read the data when encryption is turned on Key: CXF-5614 URL: https://issues.apache.org/jira/browse/CXF-5614 Project: CXF Issue Type: Bug Components: Core Affects Versions: 2.7.10, 2.6.12 Reporter: Aki Yoshida Assignee: Aki Yoshida CachedOutputStream which is used to cache large data in the file system may fail to read the file-cached data when its cipher transformation is enabled. The problem occurs when two threads are reading from the cached file or one thread is reading from the cached file after another thread partially read the data. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CXF-5611) [joda-time] different versions in maven and feature descriptor
[ https://issues.apache.org/jira/browse/CXF-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13933600#comment-13933600 ] Aki Yoshida commented on CXF-5611: -- I don't know why you have the range [2.2,3). I just checked the current 2.7.11-SNAPSHOT, cxf-rt-security has org.joda.time;version="[1.6,3)". > [joda-time] different versions in maven and feature descriptor > -- > > Key: CXF-5611 > URL: https://issues.apache.org/jira/browse/CXF-5611 > Project: CXF > Issue Type: Bug > Components: Build system >Affects Versions: 2.7.11 >Reporter: Alexey Markevich > > I have a project which depends on cxf-rt-security [1]. After the build there > is > Import-Package: org.joda.time;version="[2.2,3)" > But after deploy to karaf got > Reason: Missing Constraint: Import-Package: org.joda.time; > version="[2.2.0,3.0.0)" > because wss4j feature contains [2] > 1. > [INFO] \- org.apache.cxf:cxf-rt-security:jar:2.7.11-SNAPSHOT:compile > [INFO]+- org.opensaml:opensaml:jar:2.6.1:compile > [INFO]| +- joda-time:joda-time:jar:2.2:compile > 2. > dependency="true">mvn:joda-time/joda-time/2.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CXF-5604) Add atmosphere based implementation in websocket transport
Aki Yoshida created CXF-5604: Summary: Add atmosphere based implementation in websocket transport Key: CXF-5604 URL: https://issues.apache.org/jira/browse/CXF-5604 Project: CXF Issue Type: Improvement Components: Transports Reporter: Aki Yoshida Assignee: Aki Yoshida Adding an atmosphere based destination in rt-transports-websocket (CXF-5339) so that it can be used with other web containers such as tomcat. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CXF-5339) Introduce WebSocket CXF Transport
[ https://issues.apache.org/jira/browse/CXF-5339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-5339. -- Resolution: Fixed Fix Version/s: 3.0.0 Hi all, I moved the code into a separate transport component cxf-rt-transports-websocket. The current code supports both the embedded mode and the container mode using jetty-websocket. Some scenario tests located in systests/jaxrs's websocket tests (org.apache.cxf.systest.jaxrs.websocket) show the usage. We can close this ticket and use separate tickets to track further changes or improvements. Regards, Aki > Introduce WebSocket CXF Transport > - > > Key: CXF-5339 > URL: https://issues.apache.org/jira/browse/CXF-5339 > Project: CXF > Issue Type: New Feature > Components: Transports >Reporter: Sergey Beryozkin >Assignee: Aki Yoshida > Fix For: 3.0.0 > > > WebSocket transport will likely be supported on the server only. > It will allow users, specifically those not working directly with Camel, do > Web-Socket based Web UI targeting CXF endpoints returning some real time info. > Additionally, hope is it will help revitalise LogBrowser project where having > the log or other events displayed for individual endpoints in real time can > be quite cool; supporting such a feature might help us basically move it into > a sub-project -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (CXF-5587) CXF version 2.2.9 is not recognising my url-pattern
[ https://issues.apache.org/jira/browse/CXF-5587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida reopened CXF-5587: -- didn't know sergey was following. > CXF version 2.2.9 is not recognising my url-pattern > --- > > Key: CXF-5587 > URL: https://issues.apache.org/jira/browse/CXF-5587 > Project: CXF > Issue Type: Bug > Environment: Windows 7, 32bit, IBM RAD 7.5.5.3 >Reporter: Reginald Reed > > We are trying to run our server locally on our PC using IBM RAD 7.5.5.3 under > Windows 7, 32Bit. When we use SoapUI to run our test, we get back the error: > Error 404: SRVE0190E: File not found: /services/worker > the SoapUI url used was: http://localhost:9080/airport/services/workerwe > verified that (A) the port was correct (B) the context-root: airport is > correct (C) The Servlet mapping /services/* is correct. Is there a > compatibility with issue CXF version 2.2.9 and WIndows 7? > > > CXFServlet > > org.apache.cxf.transport.servlet.CXFServlet > > Hides the listing of available services > when set to true. > It is considered a security risk to set this to false > (or leave it unset), > because a container should never give more information > to the client > than is necessary to function properly. > hide-service-list-page > true > > > > CXFServlet > /services/* > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CXF-5587) CXF version 2.2.9 is not recognising my url-pattern
[ https://issues.apache.org/jira/browse/CXF-5587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida closed CXF-5587. Resolution: Incomplete > CXF version 2.2.9 is not recognising my url-pattern > --- > > Key: CXF-5587 > URL: https://issues.apache.org/jira/browse/CXF-5587 > Project: CXF > Issue Type: Bug > Environment: Windows 7, 32bit, IBM RAD 7.5.5.3 >Reporter: Reginald Reed > > We are trying to run our server locally on our PC using IBM RAD 7.5.5.3 under > Windows 7, 32Bit. When we use SoapUI to run our test, we get back the error: > Error 404: SRVE0190E: File not found: /services/worker > the SoapUI url used was: http://localhost:9080/airport/services/workerwe > verified that (A) the port was correct (B) the context-root: airport is > correct (C) The Servlet mapping /services/* is correct. Is there a > compatibility with issue CXF version 2.2.9 and WIndows 7? > > > CXFServlet > > org.apache.cxf.transport.servlet.CXFServlet > > Hides the listing of available services > when set to true. > It is considered a security risk to set this to false > (or leave it unset), > because a container should never give more information > to the client > than is necessary to function properly. > hide-service-list-page > true > > > > CXFServlet > /services/* > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CXF-5587) CXF version 2.2.9 is not recognising my url-pattern
[ https://issues.apache.org/jira/browse/CXF-5587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13930451#comment-13930451 ] Aki Yoshida commented on CXF-5587: -- Hi, Is there any way you could use cxf 2.7.x or 2.6.x? 2.2.9 is a way too old and we cannot look into it. If you can't reach the servlet, it is very likely that your web app configuration is incorrect. For general usage questions, please use the users@cxf mailing list. https://cxf.apache.org/mailing-lists.html Jira is not a place for asking questions but for reporting concrete issues. Thanks. Regards, aki > CXF version 2.2.9 is not recognising my url-pattern > --- > > Key: CXF-5587 > URL: https://issues.apache.org/jira/browse/CXF-5587 > Project: CXF > Issue Type: Bug > Environment: Windows 7, 32bit, IBM RAD 7.5.5.3 >Reporter: Reginald Reed > > We are trying to run our server locally on our PC using IBM RAD 7.5.5.3 under > Windows 7, 32Bit. When we use SoapUI to run our test, we get back the error: > Error 404: SRVE0190E: File not found: /services/worker > the SoapUI url used was: http://localhost:9080/airport/services/workerwe > verified that (A) the port was correct (B) the context-root: airport is > correct (C) The Servlet mapping /services/* is correct. Is there a > compatibility with issue CXF version 2.2.9 and WIndows 7? > > > CXFServlet > > org.apache.cxf.transport.servlet.CXFServlet > > Hides the listing of available services > when set to true. > It is considered a security risk to set this to false > (or leave it unset), > because a container should never give more information > to the client > than is necessary to function properly. > hide-service-list-page > true > > > > CXFServlet > /services/* > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CXF-5600) WSDL generation at WS-RM endpoint leads to NPE in the server's log
[ https://issues.apache.org/jira/browse/CXF-5600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-5600. -- Resolution: Fixed > WSDL generation at WS-RM endpoint leads to NPE in the server's log > -- > > Key: CXF-5600 > URL: https://issues.apache.org/jira/browse/CXF-5600 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.7.7, 2.7.8, 2.7.9, 3.0.0-milestone2, 2.7.10 >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 3.0.0, 2.7.11 > > > Retrieving the wsdl file from an WS-RM endpoint will lead to an NPE at the > server side log, although the wsdl document itself will be returned to the > calling client. > java.lang.NullPointerException > at > org.apache.cxf.ws.rm.RMManager.getReliableEndpoint(RMManager.java:381) > at org.apache.cxf.ws.rm.RMManager.getDestination(RMManager.java:398) > at > org.apache.cxf.ws.rm.RMDeliveryInterceptor.handle(RMDeliveryInterceptor.java:48) > at > org.apache.cxf.ws.rm.AbstractRMInterceptor.handleMessage(AbstractRMInterceptor.java:83) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) > at > org.apache.cxf.phase.PhaseInterceptorChain.doInterceptStartingAt(PhaseInterceptorChain.java:456) > at > org.apache.cxf.frontend.WSDLGetInterceptor.handleMessage(WSDLGetInterceptor.java:93) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) > at > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) > at > org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:241) > at > org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:259) > at > org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:72) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1088) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1024) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) > at org.eclipse.jetty.server.Server.handle(Server.java:370) > at > org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494) > at > org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:971) > at > org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1033) > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644) > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) > at > org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82) > at > org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667) > at > org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) > at java.lang.Thread.run(Thread.java:744) > More details in > http://cxf.547215.n5.nabble.com/WS-RM-and-WSDLGetInInterceptor-td5740962.html > This is a regression from CXF-5151 and affects CXF versions 2.7.7 to 2.7.10. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CXF-5600) WSDL generation at WS-RM endpoint leads to NPE in the server's log
Aki Yoshida created CXF-5600: Summary: WSDL generation at WS-RM endpoint leads to NPE in the server's log Key: CXF-5600 URL: https://issues.apache.org/jira/browse/CXF-5600 Project: CXF Issue Type: Bug Components: WS-* Components Affects Versions: 2.7.10, 3.0.0-milestone2, 2.7.9, 2.7.8, 2.7.7 Reporter: Aki Yoshida Assignee: Aki Yoshida Fix For: 3.0.0, 2.7.11 Retrieving the wsdl file from an WS-RM endpoint will lead to an NPE at the server side log, although the wsdl document itself will be returned to the calling client. java.lang.NullPointerException at org.apache.cxf.ws.rm.RMManager.getReliableEndpoint(RMManager.java:381) at org.apache.cxf.ws.rm.RMManager.getDestination(RMManager.java:398) at org.apache.cxf.ws.rm.RMDeliveryInterceptor.handle(RMDeliveryInterceptor.java:48) at org.apache.cxf.ws.rm.AbstractRMInterceptor.handleMessage(AbstractRMInterceptor.java:83) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) at org.apache.cxf.phase.PhaseInterceptorChain.doInterceptStartingAt(PhaseInterceptorChain.java:456) at org.apache.cxf.frontend.WSDLGetInterceptor.handleMessage(WSDLGetInterceptor.java:93) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:241) at org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:259) at org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:72) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1088) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1024) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) at org.eclipse.jetty.server.Server.handle(Server.java:370) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:971) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1033) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667) at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) at java.lang.Thread.run(Thread.java:744) More details in http://cxf.547215.n5.nabble.com/WS-RM-and-WSDLGetInInterceptor-td5740962.html This is a regression from CXF-5151 and affects CXF versions 2.7.7 to 2.7.10. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CXF-5339) Introduce WebSocket CXF Transport
[ https://issues.apache.org/jira/browse/CXF-5339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13915620#comment-13915620 ] Aki Yoshida commented on CXF-5339: -- Hi sergey, thanks. yes. I just committed the change we talked on #irc yesterday so that the status + headers are included in the response. I updated the tests and enable all of them. I'll update the beans configuration and then we can close this ticket and handle further fixes, features in separate jira tickets. I'll put the current information on the wiki page you created. regards, aki > Introduce WebSocket CXF Transport > - > > Key: CXF-5339 > URL: https://issues.apache.org/jira/browse/CXF-5339 > Project: CXF > Issue Type: New Feature > Components: Transports >Reporter: Sergey Beryozkin >Assignee: Aki Yoshida > > WebSocket transport will likely be supported on the server only. > It will allow users, specifically those not working directly with Camel, do > Web-Socket based Web UI targeting CXF endpoints returning some real time info. > Additionally, hope is it will help revitalise LogBrowser project where having > the log or other events displayed for individual endpoints in real time can > be quite cool; supporting such a feature might help us basically move it into > a sub-project -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CXF-5339) Introduce WebSocket CXF Transport
[ https://issues.apache.org/jira/browse/CXF-5339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914658#comment-13914658 ] Aki Yoshida commented on CXF-5339: -- hi sergey, regarding the to-do's and the ideas to compare/discuss regarding the options that we want to offer, shall we use an internal wiki page at the cxf's work in progress wiki or something of that kind so that we can edits/comments to sort out these fragments of thought? regards, aki > Introduce WebSocket CXF Transport > - > > Key: CXF-5339 > URL: https://issues.apache.org/jira/browse/CXF-5339 > Project: CXF > Issue Type: New Feature > Components: Transports >Reporter: Sergey Beryozkin >Assignee: Aki Yoshida > > WebSocket transport will likely be supported on the server only. > It will allow users, specifically those not working directly with Camel, do > Web-Socket based Web UI targeting CXF endpoints returning some real time info. > Additionally, hope is it will help revitalise LogBrowser project where having > the log or other events displayed for individual endpoints in real time can > be quite cool; supporting such a feature might help us basically move it into > a sub-project -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CXF-5339) Introduce WebSocket CXF Transport
[ https://issues.apache.org/jira/browse/CXF-5339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914314#comment-13914314 ] Aki Yoshida commented on CXF-5339: -- it looks like the permgen issue that I was seeing has something to do with the jdk version that I used (1.6.0_65-b14-462-11M4609 on macbook). With the standard jdk 1.7.0_51, I ran the whole systests/jaxrs a couple of times and not seeing the problem. So, I'll activate the test. > Introduce WebSocket CXF Transport > - > > Key: CXF-5339 > URL: https://issues.apache.org/jira/browse/CXF-5339 > Project: CXF > Issue Type: New Feature > Components: Transports >Reporter: Sergey Beryozkin >Assignee: Aki Yoshida > > WebSocket transport will likely be supported on the server only. > It will allow users, specifically those not working directly with Camel, do > Web-Socket based Web UI targeting CXF endpoints returning some real time info. > Additionally, hope is it will help revitalise LogBrowser project where having > the log or other events displayed for individual endpoints in real time can > be quite cool; supporting such a feature might help us basically move it into > a sub-project -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CXF-5339) Introduce WebSocket CXF Transport
[ https://issues.apache.org/jira/browse/CXF-5339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13912753#comment-13912753 ] Aki Yoshida commented on CXF-5339: -- HI Sergey, thanks. I agree that it's better to have a separate smaller test to make it easier to test additional features and analyze any issues if occurs. regarding the dependency to jetty-websocket, yes. we should make it optional. The code uses the websocket package optionally. I will add the optional flag in the osgi's package import. regards, aki > Introduce WebSocket CXF Transport > - > > Key: CXF-5339 > URL: https://issues.apache.org/jira/browse/CXF-5339 > Project: CXF > Issue Type: New Feature > Components: Transports >Reporter: Sergey Beryozkin >Assignee: Aki Yoshida > > WebSocket transport will likely be supported on the server only. > It will allow users, specifically those not working directly with Camel, do > Web-Socket based Web UI targeting CXF endpoints returning some real time info. > Additionally, hope is it will help revitalise LogBrowser project where having > the log or other events displayed for individual endpoints in real time can > be quite cool; supporting such a feature might help us basically move it into > a sub-project -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (CXF-5339) Introduce WebSocket CXF Transport
[ https://issues.apache.org/jira/browse/CXF-5339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911880#comment-13911880 ] Aki Yoshida edited comment on CXF-5339 at 2/25/14 7:07 PM: --- Hi Sergery, all, just committed the early working code in master that uses cxf's http-jetty with an extended jetty handler that can handle additionally websocket requests so that you can get the idea of this usage pattern. Currently, it allows you to open a websocket connection to the root service URL of the service enabled for websockets, which is done in its destination configuration. Once the socket is open, you can invoke various operations of that service. Currently, we have the following assumptions: 1. to be able to select the operation and pass additional parameters to it, the request body must include the request URL (e.g., GET /path…) and any additional headers and body entity if any. 2. for the client to be able to interpret the response data, the response must return the headers followed by any body entity. (In my initial commit, the response does not include headers). 3. currently, if jetty-websocket-pkg is found, the extended jetty handler is instantiated the destination even if the websocket feature is not enabled for that destination. This extended handler can handle websocket-open requests but will reject opening sockets during the request time if the websocket feature is not enabled for that destination. The reason for this behavior was to allow this enable/disable switching configurable when using ServerFactoryBean to programatically create the destination. Allowing to pass this switching parameter to the destination instantiation seems to require a change in its interface and that appeared inappropriate. If there is a simple way to pass this parameter to the destination before the handler is attached to it, we can separate the instantiation of the two handlers clearly to force the extended handler to be only instantiated if indeed the websocket feature is available and enabled for the destination. 4. the unit test in systests/jaxrs performs some GET or POST operations returning some data and one GET operation returning StreamingOutput where data can be pushed back to the client continuously. This test is working, however, when it is executed, there seems to be some issue that results in permGen error later at other tests (that indicates some memory leak). When the test is not executed, this problem does not occur. I observe this problem on my OSX setup but not on a ubunthu desktop. And I am looking into this issue. Thus, this test is currently disabled. 5. for non-jetty containers, we should add the atmosphere transport so that other web containers are supported transparently. But for now, there are various questions regarding the websocket usage patterns which we can discuss and try out with jetty. regards, aki was (Author: ay): Hi Sergery, all, just committed the early working code in master that uses cxf's http-jetty with an extended jetty handler that can handle additionally websocket requests so that you can get the idea of this usage pattern. Currently, it allows you to open a websocket connection to the root service URL of the service enabled for websockets, which is made in its destination configuration. Once the socket is open, you can invoke various operations of that service. And we have the following assumptions: 1. to be able to select the operation and pass additional parameters to it, the request body must include the request URL (e.g., GET /path…) and any additional headers and body entity if any. 2. for the client to be able to interpret the response data, the response must return the headers followed by any body entity. (In my initial commit, the response does not include headers). 3. currently, if jetty-websocket-pkg is found, the extended handler is instantiated even if the websocket feature is not enabled for the corresponding destination. This extended handler can handle websocket open requests but rejects opening sockets during the request time if the websocket feature is not enabled for that destination. The reason for this behavior was to allow this enable/disable switching when using ServerFactoryBean to programatically configure the destination. Allowing to pass this switching parameter to the destination instantiation seems to require a change in its interface and that appeared inappropriate. If there is a simple way to pass this parameter to the destination before the handler is attached, we can separate the instantiation of the handler clearly to force the extended handler is only instantiated if indeed the websocket feature is available and enabled for the destination. 4. the unit test in systests/jaxrs does simple GET or POST calls and one using StreamingOutput to push data back to the client c
[jira] [Commented] (CXF-5339) Introduce WebSocket CXF Transport
[ https://issues.apache.org/jira/browse/CXF-5339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911880#comment-13911880 ] Aki Yoshida commented on CXF-5339: -- Hi Sergery, all, just committed the early working code in master that uses cxf's http-jetty with an extended jetty handler that can handle additionally websocket requests so that you can get the idea of this usage pattern. Currently, it allows you to open a websocket connection to the root service URL of the service enabled for websockets, which is made in its destination configuration. Once the socket is open, you can invoke various operations of that service. And we have the following assumptions: 1. to be able to select the operation and pass additional parameters to it, the request body must include the request URL (e.g., GET /path…) and any additional headers and body entity if any. 2. for the client to be able to interpret the response data, the response must return the headers followed by any body entity. (In my initial commit, the response does not include headers). 3. currently, if jetty-websocket-pkg is found, the extended handler is instantiated even if the websocket feature is not enabled for the corresponding destination. This extended handler can handle websocket open requests but rejects opening sockets during the request time if the websocket feature is not enabled for that destination. The reason for this behavior was to allow this enable/disable switching when using ServerFactoryBean to programatically configure the destination. Allowing to pass this switching parameter to the destination instantiation seems to require a change in its interface and that appeared inappropriate. If there is a simple way to pass this parameter to the destination before the handler is attached, we can separate the instantiation of the handler clearly to force the extended handler is only instantiated if indeed the websocket feature is available and enabled for the destination. 4. the unit test in systests/jaxrs does simple GET or POST calls and one using StreamingOutput to push data back to the client continuously. This test is working, however, when it is executed, there seems to be some issue that results in permGen error later at other tests in systests/jarxs, I observed this problem on my OSX setup but not on a ubunthu desktop. So, I am looking into this issue. Thus, this test is currently set disabled. regards, aki > Introduce WebSocket CXF Transport > - > > Key: CXF-5339 > URL: https://issues.apache.org/jira/browse/CXF-5339 > Project: CXF > Issue Type: New Feature > Components: Transports >Reporter: Sergey Beryozkin >Assignee: Aki Yoshida > > WebSocket transport will likely be supported on the server only. > It will allow users, specifically those not working directly with Camel, do > Web-Socket based Web UI targeting CXF endpoints returning some real time info. > Additionally, hope is it will help revitalise LogBrowser project where having > the log or other events displayed for individual endpoints in real time can > be quite cool; supporting such a feature might help us basically move it into > a sub-project -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CXF-5339) Introduce WebSocket CXF Transport
[ https://issues.apache.org/jira/browse/CXF-5339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida reassigned CXF-5339: Assignee: Aki Yoshida > Introduce WebSocket CXF Transport > - > > Key: CXF-5339 > URL: https://issues.apache.org/jira/browse/CXF-5339 > Project: CXF > Issue Type: New Feature > Components: Transports >Reporter: Sergey Beryozkin >Assignee: Aki Yoshida > > WebSocket transport will likely be supported on the server only. > It will allow users, specifically those not working directly with Camel, do > Web-Socket based Web UI targeting CXF endpoints returning some real time info. > Additionally, hope is it will help revitalise LogBrowser project where having > the log or other events displayed for individual endpoints in real time can > be quite cool; supporting such a feature might help us basically move it into > a sub-project -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CXF-5551) Creating a custom bus in Blueprint does not seem to work
[
https://issues.apache.org/jira/browse/CXF-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13896612#comment-13896612
]
Aki Yoshida commented on CXF-5551:
--
Hi Sergey,
I'm sorry, I made some typos, it should say:
where cxf-core is the cxf's bp namespace.
...
the attribute name is "bus" and not "name".
and this is working fine with camel's cxf endpoint.
regards, aki
> Creating a custom bus in Blueprint does not seem to work
>
>
> Key: CXF-5551
> URL: https://issues.apache.org/jira/browse/CXF-5551
> Project: CXF
> Issue Type: Bug
> Components: Bus
>Reporter: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.0.0
>
>
> Here is a Blueprint fragment:
> {code:xml}
>
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xmlns:cxfcore="http://cxf.apache.org/blueprint/core";>
>
>
>
>
> http://localhost:8182";
> serviceClass="com.mycompany.camel.blueprint.jackson.ServiceOne"
> loggingFeatureEnabled="true"
> bus="jaxrs">
>
>
>
>
>
> {code}
> then I see:
> {noformat}
> karaf@trun> log:display-exception
> org.osgi.service.blueprint.container.ComponentDefinitionException: Unresolved
> ref/idref to component: jaxrs
> at
> org.apache.aries.blueprint.container.BlueprintRepository.validate(BlueprintRepository.java:262)[7:org.apache.aries.blueprint.core:1.1.0]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CXF-5551) Creating a custom bus in Blueprint does not seem to work
[
https://issues.apache.org/jira/browse/CXF-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13896508#comment-13896508
]
Aki Yoshida commented on CXF-5551:
--
Hi Sergey,
I think it should be working when using the bus attribute as in
...
...
let me know if it's not working.
regards, aki
> Creating a custom bus in Blueprint does not seem to work
>
>
> Key: CXF-5551
> URL: https://issues.apache.org/jira/browse/CXF-5551
> Project: CXF
> Issue Type: Bug
> Components: Bus
>Reporter: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.0.0
>
>
> Here is a Blueprint fragment:
> {code:xml}
>
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xmlns:cxfcore="http://cxf.apache.org/blueprint/core";>
>
>
>
>
> http://localhost:8182";
> serviceClass="com.mycompany.camel.blueprint.jackson.ServiceOne"
> loggingFeatureEnabled="true"
> bus="jaxrs">
>
>
>
>
>
> {code}
> then I see:
> {noformat}
> karaf@trun> log:display-exception
> org.osgi.service.blueprint.container.ComponentDefinitionException: Unresolved
> ref/idref to component: jaxrs
> at
> org.apache.aries.blueprint.container.BlueprintRepository.validate(BlueprintRepository.java:262)[7:org.apache.aries.blueprint.core:1.1.0]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (CXF-5546) NPE may be thrown and logged during WS-RM's retransmission
Aki Yoshida created CXF-5546: Summary: NPE may be thrown and logged during WS-RM's retransmission Key: CXF-5546 URL: https://issues.apache.org/jira/browse/CXF-5546 Project: CXF Issue Type: Bug Components: WS-* Components Affects Versions: 2.7.9 Reporter: Aki Yoshida Assignee: Aki Yoshida While a message is being retransmitted from a client (RM-Source) from its retransmission queue, the corresponding message might be acknowledged and its resource released at the client. And in this case, an NPE will be thrown during the resending of the message. Feb 5, 2014 5:48:32 PM org.apache.cxf.ws.rm.soap.RetransmissionQueueImpl$3 resend WARNING: WS-RM retransmission failed. java.lang.NullPointerException at java.io.ByteArrayInputStream.(ByteArrayInputStream.java:89) at org.apache.cxf.ws.rm.soap.RetransmissionQueueImpl.resend(RetransmissionQueueImpl.java:461) at org.apache.cxf.ws.rm.soap.RetransmissionQueueImpl.clientResend(RetransmissionQueueImpl.java:371) at org.apache.cxf.ws.rm.soap.RetransmissionQueueImpl.access$400(RetransmissionQueueImpl.java:80) at org.apache.cxf.ws.rm.soap.RetransmissionQueueImpl$3.resend(RetransmissionQueueImpl.java:768) at org.apache.cxf.ws.rm.soap.RetransmissionQueueImpl$ResendCandidate.run(RetransmissionQueueImpl.java:577) at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) at org.apache.cxf.ws.rm.soap.RetransmissionQueueImpl$ResendCandidate.initiate(RetransmissionQueueImpl.java:565) at org.apache.cxf.ws.rm.soap.RetransmissionQueueImpl$ResendCandidate$1ResendTask.run(RetransmissionQueueImpl.java:724) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) Note that this issue is about handling this case gracefully to avoid throwing an NPE. The issue itself does not break the delivery guarantee semantics as the resend is failing because the message has been acknowledged. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CXF-5517) Incorrect check for VOID type
[ https://issues.apache.org/jira/browse/CXF-5517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-5517. -- Resolution: Fixed Fix Version/s: 2.7.10 2.6.13 3.0.0-milestone2 I kept the Void.class comparison although it's probably unusual to get the return type of Void.class. The patch will perform comparison consistently against Void.TYPE (which is equivalent to void.class) and Void.class. > Incorrect check for VOID type > - > > Key: CXF-5517 > URL: https://issues.apache.org/jira/browse/CXF-5517 > Project: CXF > Issue Type: Bug >Reporter: Valentin Mayamsin >Assignee: Aki Yoshida > Labels: void > Fix For: 3.0.0-milestone2, 2.6.13, 2.7.10 > > > There are multiple occurrences in CXF code base for both server and client > side which incorrectly deals with VOID return type. For example: > method.getReturnType() == Void.class > This fails in case of primitive VOID: > method.getReturnType() => void.class > The correct way of checking for VOID is: > method.getReturnType().equals(Void.TYPE) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CXF-5517) Incorrect check for VOID type
[ https://issues.apache.org/jira/browse/CXF-5517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida reassigned CXF-5517: Assignee: Aki Yoshida > Incorrect check for VOID type > - > > Key: CXF-5517 > URL: https://issues.apache.org/jira/browse/CXF-5517 > Project: CXF > Issue Type: Bug >Reporter: Valentin Mayamsin >Assignee: Aki Yoshida > Labels: void > > There are multiple occurrences in CXF code base for both server and client > side which incorrectly deals with VOID return type. For example: > method.getReturnType() == Void.class > This fails in case of primitive VOID: > method.getReturnType() => void.class > The correct way of checking for VOID is: > method.getReturnType().equals(Void.TYPE) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CXF-5517) Incorrect check for VOID type
[ https://issues.apache.org/jira/browse/CXF-5517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13887826#comment-13887826 ] Aki Yoshida commented on CXF-5517: -- Maybe we need to fix this. but Void.TYPE is the same thing as void.class, no? I just don't know when to use Void.class in comparison. > Incorrect check for VOID type > - > > Key: CXF-5517 > URL: https://issues.apache.org/jira/browse/CXF-5517 > Project: CXF > Issue Type: Bug >Reporter: Valentin Mayamsin > Labels: void > > There are multiple occurrences in CXF code base for both server and client > side which incorrectly deals with VOID return type. For example: > method.getReturnType() == Void.class > This fails in case of primitive VOID: > method.getReturnType() => void.class > The correct way of checking for VOID is: > method.getReturnType().equals(Void.TYPE) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CXF-5509) NullPointerException if class with generic-array parameters is set to rootClassNames
[
https://issues.apache.org/jira/browse/CXF-5509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13884228#comment-13884228
]
Aki Yoshida commented on CXF-5509:
--
Bright,
okay. I see.
You could get this error spotted in a unit test by loading your spring context
file, though.
But in any case, I am not sure how/if this case can be handled.
regards, aki
> NullPointerException if class with generic-array parameters is set to
> rootClassNames
>
>
> Key: CXF-5509
> URL: https://issues.apache.org/jira/browse/CXF-5509
> Project: CXF
> Issue Type: Bug
> Components: Aegis Databinding
>Affects Versions: 2.7.8
> Environment: RHEL6.3 (64b), JDK1.6, Spring 3.0.6, CXF 2.7.8
>Reporter: Bright Zheng
> Labels: NPE, aegis, binding, cxf, generic
> Attachments: learning-spring_cxf.zip
>
>
> I want to expose a set of classes by setting the aegisContext:
> {code:xml}
> scope="prototype">
>
>
>
>
>
> {code}
> One of the class in the list is as a response pojo which has generic-array
> field like:
> {code:java}
> public class Subject{
> ...
> private T[] score;
> //and getter/setter also
> ...
> {code}
> During the deployment phase, while debugging with the CXF code, I found that
> below codes in TypeUtil.java under cxf-rt-databinding-aegis-2.7.8.jar will
> case issue:
> {code:java}
> public static Class getTypeRelatedClass(Type type) {
> Class directClass = getTypeClass(type, false);
> if (directClass != null) {
> return directClass;
> }
>
> if (type instanceof ParameterizedType) {
> ParameterizedType pType = (ParameterizedType) type;
> return getTypeRelatedClass(pType.getRawType());
> }
>
> if (type instanceof GenericArrayType) {
> GenericArrayType gat = (GenericArrayType) type;
> Type compType = gat.getGenericComponentType();
> Class arrayBaseType = getTypeRelatedClass(compType);
> // believe it or not, this seems to be the only way to get the
> // Class object for an array of primitive type.
> Object instance = Array.newInstance(arrayBaseType, 0);
> return instance.getClass();
> }
> return null;
> }
> {code}
> {color:red}
> Note: the arrayBaseType will always be null while initializing that class so
> it will cause the next line of code NPE!!
> {color}
> Did I miss anything for this kind of class mapping while using aegis?
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CXF-5509) NullPointerException if class with generic-array parameters is set to rootClassNames
[
https://issues.apache.org/jira/browse/CXF-5509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13882731#comment-13882731
]
Aki Yoshida commented on CXF-5509:
--
Hi,
Is the unit test that you included in your zip file supposed to fail?
I just ran the test and didn't see any exception, so I was wondering about it.
regards, aki
> NullPointerException if class with generic-array parameters is set to
> rootClassNames
>
>
> Key: CXF-5509
> URL: https://issues.apache.org/jira/browse/CXF-5509
> Project: CXF
> Issue Type: Bug
> Components: Aegis Databinding
>Affects Versions: 2.7.8
> Environment: RHEL6.3 (64b), JDK1.6, Spring 3.0.6, CXF 2.7.8
>Reporter: Bright Zheng
> Labels: NPE, aegis, binding, cxf, generic
> Attachments: learning-spring_cxf.zip
>
>
> I want to expose a set of classes by setting the aegisContext:
> {code:xml}
> scope="prototype">
>
>
>
>
>
> {code}
> One of the class in the list is as a response pojo which has generic-array
> field like:
> {code:java}
> public class Subject{
> ...
> private T[] score;
> //and getter/setter also
> ...
> {code}
> During the deployment phase, while debugging with the CXF code, I found that
> below codes in TypeUtil.java under cxf-rt-databinding-aegis-2.7.8.jar will
> case issue:
> {code:java}
> public static Class getTypeRelatedClass(Type type) {
> Class directClass = getTypeClass(type, false);
> if (directClass != null) {
> return directClass;
> }
>
> if (type instanceof ParameterizedType) {
> ParameterizedType pType = (ParameterizedType) type;
> return getTypeRelatedClass(pType.getRawType());
> }
>
> if (type instanceof GenericArrayType) {
> GenericArrayType gat = (GenericArrayType) type;
> Type compType = gat.getGenericComponentType();
> Class arrayBaseType = getTypeRelatedClass(compType);
> // believe it or not, this seems to be the only way to get the
> // Class object for an array of primitive type.
> Object instance = Array.newInstance(arrayBaseType, 0);
> return instance.getClass();
> }
> return null;
> }
> {code}
> {color:red}
> Note: the arrayBaseType will always be null while initializing that class so
> it will cause the next line of code NPE!!
> {color}
> Did I miss anything for this kind of class mapping while using aegis?
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (CXF-5507) Missing alternativeSelector handling in ws-policy feature's blueprint configuration
[ https://issues.apache.org/jira/browse/CXF-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-5507. -- Resolution: Fixed > Missing alternativeSelector handling in ws-policy feature's blueprint > configuration > --- > > Key: CXF-5507 > URL: https://issues.apache.org/jira/browse/CXF-5507 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.7.8 >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 3.0.0-milestone2, 2.6.12, 2.7.9 > > > alternativeSelector is not handled in ws-policy feature's blueprint > configuration. > Note it is handled in spring configuration and also for ws-policy's engine > configuration in blueprint. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CXF-5507) Missing alternativeSelector handling in ws-policy feature's blueprint configuration
Aki Yoshida created CXF-5507: Summary: Missing alternativeSelector handling in ws-policy feature's blueprint configuration Key: CXF-5507 URL: https://issues.apache.org/jira/browse/CXF-5507 Project: CXF Issue Type: Bug Components: WS-* Components Affects Versions: 2.7.8 Reporter: Aki Yoshida Assignee: Aki Yoshida Fix For: 3.0.0-milestone2, 2.6.12, 2.7.9 alternativeSelector is not handled in ws-policy feature's blueprint configuration. Note it is handled in spring configuration and also for ws-policy's engine configuration in blueprint. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CXF-5506) Make ws-addressing schema available during blueprint schema resolution
[ https://issues.apache.org/jira/browse/CXF-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-5506. -- Resolution: Fixed Fix Version/s: 2.7.9 2.6.12 3.0.0-milestone2 > Make ws-addressing schema available during blueprint schema resolution > -- > > Key: CXF-5506 > URL: https://issues.apache.org/jira/browse/CXF-5506 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 2.7.8 >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 3.0.0-milestone2, 2.6.12, 2.7.9 > > > ws-addressing schemas are included in cxf-api (or in cxf-core in 3.x) but not > made available locally during blueprint's schema parsing. > i think we should expose this schema from cxf-api so that a schema > referencing ws-addressing can be processed without internet connection. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CXF-5506) Make ws-addressing schema available during blueprint schema resolution
Aki Yoshida created CXF-5506: Summary: Make ws-addressing schema available during blueprint schema resolution Key: CXF-5506 URL: https://issues.apache.org/jira/browse/CXF-5506 Project: CXF Issue Type: Bug Components: Core Affects Versions: 2.7.8 Reporter: Aki Yoshida Assignee: Aki Yoshida ws-addressing schemas are included in cxf-api (or in cxf-core in 3.x) but not made available locally during blueprint's schema parsing. i think we should expose this schema from cxf-api so that a schema referencing ws-addressing can be processed without internet connection. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CXF-5465) policy.xsd used in rt-ws-policy's blueprint configuration is inconsistent
[ https://issues.apache.org/jira/browse/CXF-5465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-5465. -- Resolution: Fixed Fix Version/s: 2.7.9 2.6.12 3.0.0-milestone2 > policy.xsd used in rt-ws-policy's blueprint configuration is inconsistent > - > > Key: CXF-5465 > URL: https://issues.apache.org/jira/browse/CXF-5465 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.7.8 >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 3.0.0-milestone2, 2.6.12, 2.7.9 > > > According to the CXF documentation, > http://cxf.apache.org/docs/schemas-and-namespaces.html > the schema for CXF's policy configuration has namespace > "http://cxf.apache.org/policy"; for both spring and blueprint, but the schema > location is given as "http://cxf.apache.org/schemas/policy.xsd"; and > "http://cxf.apache.org/schemas/blueprint/policy.xsd";, respectively. > Although the lookup of these two schemas will unlikely occur at the same time > (because one for only spring context and the other one for only blueprint > context), assigning a namespace to two different locations with different > contents could lead to an unexpected behavior. For example, schema at > "http://cxf.apache.org/schemas/blueprint/policy.xsd"; has the target namespace > set to http://cxf.apache.org/blueprint/policy. > As it seems these two schemas can be unified into one schema without any > dependency to spring or blueprint, we should use one unified schema for both > contexts. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CXF-5461) Add ws-securitypolicy-1.2.xsd to rt-ws-policy's schema resolution
[ https://issues.apache.org/jira/browse/CXF-5461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-5461. -- Resolution: Fixed Fix Version/s: 2.7.9 2.6.12 3.0.0-milestone2 > Add ws-securitypolicy-1.2.xsd to rt-ws-policy's schema resolution > - > > Key: CXF-5461 > URL: https://issues.apache.org/jira/browse/CXF-5461 > Project: CXF > Issue Type: Improvement > Components: WS-* Components >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 3.0.0-milestone2, 2.6.12, 2.7.9 > > > The other security related schemas that are used to configure a policy based > security scenario are available as local schema files in rt-ws-policy. > However, the schema for namespace > "http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"; is missing. This > leads to the namespace handler waiting error when the policy is configured > inline in the blueprint configuration. > [ Blueprint Extender: 2] BlueprintContainerImpl INFO Bundle > test_wssecpolicy_in_bp is waiting for namespace handlers > [http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702] > Since other policy related security schemas are exposed from rt-ws-policy, we > could put this schema in rt-ws-policy (and not in rt-ws-security). > Note that one could avoid this problem by externalizing the policy part. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CXF-5459) Some imported xsd schemas are not resolved in spring when referenced from another schema
[ https://issues.apache.org/jira/browse/CXF-5459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-5459. -- Resolution: Fixed Fix Version/s: 2.7.9 2.6.12 3.0.0-milestone2 > Some imported xsd schemas are not resolved in spring when referenced from > another schema > > > Key: CXF-5459 > URL: https://issues.apache.org/jira/browse/CXF-5459 > Project: CXF > Issue Type: Bug > Components: Configuration >Affects Versions: 2.7.8 >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 3.0.0-milestone2, 2.6.12, 2.7.9 > > > Imported xsd schemas from a locally copied xsd schema should be referenced > using their "original" absolute schema location URLs and these "original" > location URLs should be mapped to the locally available resource location in > spring and blueprint. > Currently, some imported schemas are directly referenced using their local > relative resource location and this is interfering with the schema loading in > spring. > http://cxf.547215.n5.nabble.com/issue-with-schema-loading-in-spring-td5737686.html -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CXF-5405) WS-RM with anonymous endpoint throwing security policy validation exception for SequenceAck
[
https://issues.apache.org/jira/browse/CXF-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aki Yoshida resolved CXF-5405.
--
Resolution: Fixed
Fix Version/s: 3.0.0-milestone2
> WS-RM with anonymous endpoint throwing security policy validation exception
> for SequenceAck
> ---
>
> Key: CXF-5405
> URL: https://issues.apache.org/jira/browse/CXF-5405
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 2.7.7
>Reporter: Aki Yoshida
>Assignee: Aki Yoshida
> Fix For: 3.0.0-milestone2, 2.6.12, 2.7.9
>
>
> When WS-RM with an anonoymous endpoint is used in conjuction with a policy
> based WS-Security configuration, the sequence acknoledgement response to the
> client is rejected by the policy validator.
> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}X509Token: The
> received token does not match the token inclusion requirement
> org.apache.cxf.ws.policy.PolicyException: These policy alternatives can not
> be satisfied:
> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}X509Token: The
> received token does not match the token inclusion requirement
> at
> org.apache.cxf.ws.policy.AssertionInfoMap.checkEffectivePolicy(AssertionInfoMap.java:179)
> at
> org.apache.cxf.ws.policy.PolicyVerificationInInterceptor.handle(PolicyVerificationInInterceptor.java:101)
> at
> org.apache.cxf.ws.policy.AbstractPolicyInterceptor.handleMessage(AbstractPolicyInterceptor.java:44)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
> at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:835)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1606)
> The cause of this issue is in the RM processing to reset the requestor role,
> whose value will subsequently be used by the policy validator to choose the
> correct configuration value. The requestor role for the SequenceAck messages
> should not be reset.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
