[jira] [Created] (CXF-3412) ManagedEndpoint.getTransportId return endpoint address
ManagedEndpoint.getTransportId return endpoint address
--
Key: CXF-3412
URL: https://issues.apache.org/jira/browse/CXF-3412
Project: CXF
Issue Type: Bug
Components: Core
Affects Versions: 2.2
Reporter: David Liu
Is it a bug that ManagedEndpoint.getTransportId() just return the endpoint's
address. I would expect it return endpoint.getTransportId()
{code}
ManagedEndpoint{
@ManagedAttribute(description = "TransportId Attribute", currencyTimeLimit
= 60)
public String getTransportId() {
return endpoint.getEndpointInfo().getAddress();
}
@ManagedAttribute(description = "Address Attribute", currencyTimeLimit = 60)
public String getAddress() {
return endpoint.getEndpointInfo().getAddress();
}
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3412) ManagedEndpoint.getTransportId return endpoint address
[
https://issues.apache.org/jira/browse/CXF-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010042#comment-13010042
]
Freeman Fang commented on CXF-3412:
---
Yeah, it's a bug, patch is always welcome!
Freeman
> ManagedEndpoint.getTransportId return endpoint address
> --
>
> Key: CXF-3412
> URL: https://issues.apache.org/jira/browse/CXF-3412
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2
>Reporter: David Liu
>
> Is it a bug that ManagedEndpoint.getTransportId() just return the endpoint's
> address. I would expect it return endpoint.getTransportId()
> {code}
> ManagedEndpoint{
> @ManagedAttribute(description = "TransportId Attribute",
> currencyTimeLimit = 60)
> public String getTransportId() {
> return endpoint.getEndpointInfo().getAddress();
> }
> @ManagedAttribute(description = "Address Attribute", currencyTimeLimit =
> 60)
> public String getAddress() {
> return endpoint.getEndpointInfo().getAddress();
> }
> }
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3413) IndexOutOfBoundsException in DocLiteralInInterceptor
IndexOutOfBoundsException in DocLiteralInInterceptor
Key: CXF-3413
URL: https://issues.apache.org/jira/browse/CXF-3413
Project: CXF
Issue Type: Bug
Affects Versions: 2.3.3
Reporter: Andreas Gudian
I am receiving the following response from a web service that I call using CXF
2.3.3:
{code:xml}
http://www.w3.org/2003/05/soap-envelope";
xmlns:xml="http://www.w3.org/XML/1998/namespace";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
http://www.w3.org/2003/05/soap-envelope";
xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding";>
http://www.xxx.yy/zzz/types/";>-1
http://www.xxx.yy/zzz/types/";>Some Status
Message
http://www.xxx.yy/zzz/types/";>
{code}
This results in the following exception:
{code}
java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at
org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:188)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:755)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2335)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:2193)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:2037)
at
org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:47)
at
org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:188)
at
org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:697)
at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:516)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:265)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
at $Proxy43.myWebserviceOperation(Unknown Source)
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3413) IndexOutOfBoundsException in DocLiteralInInterceptor
[
https://issues.apache.org/jira/browse/CXF-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010089#comment-13010089
]
Freeman Fang commented on CXF-3413:
---
Hi,
Could you elaborate what's the soap stack used for server side?
I notice there's
xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding";
from your response message,
which indicate the server side isn't cxf, and soap-encoding style isn't
supported by cxf.
Thus you also need append your wsdl so that we can tell if the response soap
message is expected by cxf.
Freeman
> IndexOutOfBoundsException in DocLiteralInInterceptor
>
>
> Key: CXF-3413
> URL: https://issues.apache.org/jira/browse/CXF-3413
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.3.3
>Reporter: Andreas Gudian
>
> I am receiving the following response from a web service that I call using
> CXF 2.3.3:
> {code:xml}
>
> http://www.w3.org/2003/05/soap-envelope";
> xmlns:xml="http://www.w3.org/XML/1998/namespace";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> http://www.w3.org/2003/05/soap-envelope";
> xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding";>
> xmlns:xsd1="http://www.xxx.yy/zzz/types/";>-1
> http://www.xxx.yy/zzz/types/";>Some Status
> Message
> http://www.xxx.yy/zzz/types/";>
>
>
> {code}
> This results in the following exception:
> {code}
> java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
> at java.util.ArrayList.RangeCheck(ArrayList.java:547)
> at java.util.ArrayList.get(ArrayList.java:322)
> at
> org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:188)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
> at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:755)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2335)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:2193)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:2037)
> at
> org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:47)
> at
> org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:188)
> at
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:697)
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:516)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:265)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
> at $Proxy43.myWebserviceOperation(Unknown Source)
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-1100) WS-RM should stream the messages into storage instead of using byte[]
[ https://issues.apache.org/jira/browse/CXF-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010106#comment-13010106 ] Aki Yoshida commented on CXF-1100: -- Hi, Should I prepare for a similar change (i.e., the corresponding change minus the added methods in RMStore) for 2.3.x as well? Let me know, Regards, aki > WS-RM should stream the messages into storage instead of using byte[] > - > > Key: CXF-1100 > URL: https://issues.apache.org/jira/browse/CXF-1100 > Project: CXF > Issue Type: Improvement > Components: WS-* Components >Affects Versions: 2.0.2 >Reporter: Daniel Kulp >Assignee: Daniel Kulp > Fix For: 2.4 > > Attachments: trunk_20110321.zip > > > Currently, WS-RM loads the entire message into a byte[] to put into the > RMMessage. For large messages that could be a lot of memory used. Ideally, > it should be able to stream directly from the > CachedOutputStream.getInputStream() into storage so if the message is cached > in a temp file, it won't be totally loaded into memory. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3414) Signature verification fails with custom SOAP header
Signature verification fails with custom SOAP header
Key: CXF-3414
URL: https://issues.apache.org/jira/browse/CXF-3414
Project: CXF
Issue Type: Bug
Components: WS-* Components
Affects Versions: 2.3.2
Reporter: Jens Granseuer
Attachments: signature-handler.zip
When a client sends a signed message body, and also includes a custom SOAP
header in the message, signature verification fails at the receiving end.
{quote}
2011-03-23 14:33:41,159 DEBUG | verify 1 References | signature.Manifest
2011-03-23 14:33:41,159 DEBUG | I am not requested to follow nested Manifests |
signature.Manifest
2011-03-23 14:33:41,159 DEBUG | setElement("ds:Reference", "null") |
utils.ElementProxy
2011-03-23 14:33:41,159 DEBUG | setElement("ds:Transforms", "null") |
utils.ElementProxy
2011-03-23 14:33:41,159 DEBUG | Request for URI
http://www.w3.org/2000/09/xmldsig#sha1 | algorithms.JCEMapper
2011-03-23 14:33:41,159 DEBUG | I was asked to create a ResourceResolver and
got 1 | resolver.ResourceResolver
2011-03-23 14:33:41,159 DEBUG | extra resolvers to my existing 4 system-wide
resolvers | resolver.ResourceResolver
2011-03-23 14:33:41,159 DEBUG | check resolvability by class
org.apache.ws.security.message.EnvelopeIdResolver | resolver.ResourceResolver
2011-03-23 14:33:41,159 DEBUG | enter engineResolve, look for: #id-2 |
message.EnvelopeIdResolver
2011-03-23 14:33:41,159 DEBUG | exit engineResolve, result:
XMLSignatureInput/Element/[soap:Body: null] exclude null comments:false/null |
message.EnvelopeIdResolver
2011-03-23 14:33:41,159 DEBUG | setElement("ds:Transform", "null") |
utils.ElementProxy
2011-03-23 14:33:41,159 DEBUG | Pre-digested input: | utils.DigesterOutputStream
2011-03-23 14:33:41,159 DEBUG | http://schemas.xmlsoap.org/soap/envelope/";
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
wsu:Id="id-2">http://apache.org/hello_world_soap_http/types";>Masterhttp://apache.org/hello_world_soap_http/types";>Master
| utils.DigesterOutputStream
2011-03-23 14:33:41,159 WARN | Verification failed for URI "#id-2" |
signature.Reference
2011-03-23 14:33:41,159 WARN | Expected Digest: yFxDQhgODwm09BOOEJwzrMzvfO4= |
signature.Reference
2011-03-23 14:33:41,159 WARN | Actual Digest: l9AeEEtC5yLW+5gbX/vJunbkhrU= |
signature.Reference
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-1100) WS-RM should stream the messages into storage instead of using byte[]
[ https://issues.apache.org/jira/browse/CXF-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010116#comment-13010116 ] Daniel Kulp commented on CXF-1100: -- Aki, With 2.4.0 just a couple weeks away, I'm actually quite ok with saying this is a 2.4.x improvement. If you'd like to port it to 2.3.x, that's fine, but I wouldn't consider it a major issue. If there are other things you'd prefer to spend your time on, please do so. :-) Dan > WS-RM should stream the messages into storage instead of using byte[] > - > > Key: CXF-1100 > URL: https://issues.apache.org/jira/browse/CXF-1100 > Project: CXF > Issue Type: Improvement > Components: WS-* Components >Affects Versions: 2.0.2 >Reporter: Daniel Kulp >Assignee: Daniel Kulp > Fix For: 2.4 > > Attachments: trunk_20110321.zip > > > Currently, WS-RM loads the entire message into a byte[] to put into the > RMMessage. For large messages that could be a lot of memory used. Ideally, > it should be able to stream directly from the > CachedOutputStream.getInputStream() into storage so if the message is cached > in a temp file, it won't be totally loaded into memory. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-3414) Signature verification fails with custom SOAP header
[
https://issues.apache.org/jira/browse/CXF-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Granseuer updated CXF-3414:
Attachment: signature-handler.zip
simple maven test project
> Signature verification fails with custom SOAP header
>
>
> Key: CXF-3414
> URL: https://issues.apache.org/jira/browse/CXF-3414
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 2.3.2
>Reporter: Jens Granseuer
> Attachments: signature-handler.zip
>
>
> When a client sends a signed message body, and also includes a custom SOAP
> header in the message, signature verification fails at the receiving end.
> {quote}
> 2011-03-23 14:33:41,159 DEBUG | verify 1 References | signature.Manifest
> 2011-03-23 14:33:41,159 DEBUG | I am not requested to follow nested Manifests
> | signature.Manifest
> 2011-03-23 14:33:41,159 DEBUG | setElement("ds:Reference", "null") |
> utils.ElementProxy
> 2011-03-23 14:33:41,159 DEBUG | setElement("ds:Transforms", "null") |
> utils.ElementProxy
> 2011-03-23 14:33:41,159 DEBUG | Request for URI
> http://www.w3.org/2000/09/xmldsig#sha1 | algorithms.JCEMapper
> 2011-03-23 14:33:41,159 DEBUG | I was asked to create a ResourceResolver and
> got 1 | resolver.ResourceResolver
> 2011-03-23 14:33:41,159 DEBUG | extra resolvers to my existing 4 system-wide
> resolvers | resolver.ResourceResolver
> 2011-03-23 14:33:41,159 DEBUG | check resolvability by class
> org.apache.ws.security.message.EnvelopeIdResolver | resolver.ResourceResolver
> 2011-03-23 14:33:41,159 DEBUG | enter engineResolve, look for: #id-2 |
> message.EnvelopeIdResolver
> 2011-03-23 14:33:41,159 DEBUG | exit engineResolve, result:
> XMLSignatureInput/Element/[soap:Body: null] exclude null comments:false/null
> | message.EnvelopeIdResolver
> 2011-03-23 14:33:41,159 DEBUG | setElement("ds:Transform", "null") |
> utils.ElementProxy
> 2011-03-23 14:33:41,159 DEBUG | Pre-digested input: |
> utils.DigesterOutputStream
> 2011-03-23 14:33:41,159 DEBUG | xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
> wsu:Id="id-2"> xmlns="http://apache.org/hello_world_soap_http/types";>Master
> xmlns="http://apache.org/hello_world_soap_http/types";>Master
> | utils.DigesterOutputStream
> 2011-03-23 14:33:41,159 WARN | Verification failed for URI "#id-2" |
> signature.Reference
> 2011-03-23 14:33:41,159 WARN | Expected Digest: yFxDQhgODwm09BOOEJwzrMzvfO4=
> | signature.Reference
> 2011-03-23 14:33:41,159 WARN | Actual Digest: l9AeEEtC5yLW+5gbX/vJunbkhrU= |
> signature.Reference
> {quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3414) Signature verification fails with custom SOAP header
[
https://issues.apache.org/jira/browse/CXF-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010166#comment-13010166
]
Colm O hEigeartaigh commented on CXF-3414:
--
Hi,
Two points...
1) The custom SOAP header is not sent in the message, the SOAP handler is only
installed on the inbound side.
2) The test-case works if you remove the SAAJInInterceptor. It isn't needed, as
the WSS4JInInterceptor will call it automatically.
Beyond that, I'm not sure without digging into it deeper what's causing the
SOAP body child to be duplicated, and cause the signature verification to fail
as a result.
Colm.
> Signature verification fails with custom SOAP header
>
>
> Key: CXF-3414
> URL: https://issues.apache.org/jira/browse/CXF-3414
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 2.3.2
>Reporter: Jens Granseuer
> Attachments: signature-handler.zip
>
>
> When a client sends a signed message body, and also includes a custom SOAP
> header in the message, signature verification fails at the receiving end.
> {quote}
> 2011-03-23 14:33:41,159 DEBUG | verify 1 References | signature.Manifest
> 2011-03-23 14:33:41,159 DEBUG | I am not requested to follow nested Manifests
> | signature.Manifest
> 2011-03-23 14:33:41,159 DEBUG | setElement("ds:Reference", "null") |
> utils.ElementProxy
> 2011-03-23 14:33:41,159 DEBUG | setElement("ds:Transforms", "null") |
> utils.ElementProxy
> 2011-03-23 14:33:41,159 DEBUG | Request for URI
> http://www.w3.org/2000/09/xmldsig#sha1 | algorithms.JCEMapper
> 2011-03-23 14:33:41,159 DEBUG | I was asked to create a ResourceResolver and
> got 1 | resolver.ResourceResolver
> 2011-03-23 14:33:41,159 DEBUG | extra resolvers to my existing 4 system-wide
> resolvers | resolver.ResourceResolver
> 2011-03-23 14:33:41,159 DEBUG | check resolvability by class
> org.apache.ws.security.message.EnvelopeIdResolver | resolver.ResourceResolver
> 2011-03-23 14:33:41,159 DEBUG | enter engineResolve, look for: #id-2 |
> message.EnvelopeIdResolver
> 2011-03-23 14:33:41,159 DEBUG | exit engineResolve, result:
> XMLSignatureInput/Element/[soap:Body: null] exclude null comments:false/null
> | message.EnvelopeIdResolver
> 2011-03-23 14:33:41,159 DEBUG | setElement("ds:Transform", "null") |
> utils.ElementProxy
> 2011-03-23 14:33:41,159 DEBUG | Pre-digested input: |
> utils.DigesterOutputStream
> 2011-03-23 14:33:41,159 DEBUG | xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
> wsu:Id="id-2"> xmlns="http://apache.org/hello_world_soap_http/types";>Master
> xmlns="http://apache.org/hello_world_soap_http/types";>Master
> | utils.DigesterOutputStream
> 2011-03-23 14:33:41,159 WARN | Verification failed for URI "#id-2" |
> signature.Reference
> 2011-03-23 14:33:41,159 WARN | Expected Digest: yFxDQhgODwm09BOOEJwzrMzvfO4=
> | signature.Reference
> 2011-03-23 14:33:41,159 WARN | Actual Digest: l9AeEEtC5yLW+5gbX/vJunbkhrU= |
> signature.Reference
> {quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
CXF client and WAS 7 issue classcast exception
Hi, I am trying to run a CXF client in WAS 7. The client runs fine but I start getting classcast excetion as soon as I try to use the ClientProxy.getClient(mycxfclient) so that I can apply some policies in regard to setting the connection and recieve timeout or setting the authentication data etc. below is the sample code: Client cl = ClientProxy.getClient(rs); HTTPConduit http = (HTTPConduit) cl.getConduit(); HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy(); httpClientPolicy.setConnectionTimeout(12); httpClientPolicy.setReceiveTimeout(12); httpClientPolicy.setAllowChunking(false); http.setClient(httpClientPolicy); Here is the partial excetion trace: Exception data: java.lang.ClassCastException: org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler incompatible with org.apache.cxf.frontend.ClientProxy at org.apache.cxf.frontend.ClientProxy.getClient(ClientProxy.java:93) I have deployed successfully couple of CXF services on WAS 7. This is my first instance trying to consume the CXF CLIENT which is trying to hit another web service deployed somewhere else. As I mentioned even that works fine as long as I don't try to use the ClinetProxy. In the code above my Client cl is actually org.apache.cxf.frontend.Client and ClientProxy is org.apache.cxf.frontend.ClientProxy. I am gettig stuck on this one and will really appreciate if someoen can share some insight. As I indicated I have deployed some CXF servives successfully on WAS 7 after using the DisableIBMJAXWSEngine: true technique. But this problem is happening when I trying to run a CXF client in my code and when I try to get the Client thry ClientProxy.getClient call. -- View this message in context: http://cxf.547215.n5.nabble.com/CXF-client-and-WAS-7-issue-classcast-exception-tp4258948p4258948.html Sent from the cxf-issues mailing list archive at Nabble.com.
Re: CXF client and WAS 7 issue classcast exception
I also want to highlight the fact that same code runs fine under jUNIT test running in my RAD. I only see this issue when I am trying to run the application on WAS server itself. -- View this message in context: http://cxf.547215.n5.nabble.com/CXF-client-and-WAS-7-issue-classcast-exception-tp4258948p4258957.html Sent from the cxf-issues mailing list archive at Nabble.com.
[jira] [Commented] (CXF-3414) Signature verification fails with custom SOAP header
[
https://issues.apache.org/jira/browse/CXF-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010204#comment-13010204
]
Jens Granseuer commented on CXF-3414:
-
1) Yeah, even so, just adding the handler is sufficient to make it fail.
2) Ah, indeed, it does work without the SAAJOut. Sorry for the noise.
Thanks!
> Signature verification fails with custom SOAP header
>
>
> Key: CXF-3414
> URL: https://issues.apache.org/jira/browse/CXF-3414
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 2.3.2
>Reporter: Jens Granseuer
> Attachments: signature-handler.zip
>
>
> When a client sends a signed message body, and also includes a custom SOAP
> header in the message, signature verification fails at the receiving end.
> {quote}
> 2011-03-23 14:33:41,159 DEBUG | verify 1 References | signature.Manifest
> 2011-03-23 14:33:41,159 DEBUG | I am not requested to follow nested Manifests
> | signature.Manifest
> 2011-03-23 14:33:41,159 DEBUG | setElement("ds:Reference", "null") |
> utils.ElementProxy
> 2011-03-23 14:33:41,159 DEBUG | setElement("ds:Transforms", "null") |
> utils.ElementProxy
> 2011-03-23 14:33:41,159 DEBUG | Request for URI
> http://www.w3.org/2000/09/xmldsig#sha1 | algorithms.JCEMapper
> 2011-03-23 14:33:41,159 DEBUG | I was asked to create a ResourceResolver and
> got 1 | resolver.ResourceResolver
> 2011-03-23 14:33:41,159 DEBUG | extra resolvers to my existing 4 system-wide
> resolvers | resolver.ResourceResolver
> 2011-03-23 14:33:41,159 DEBUG | check resolvability by class
> org.apache.ws.security.message.EnvelopeIdResolver | resolver.ResourceResolver
> 2011-03-23 14:33:41,159 DEBUG | enter engineResolve, look for: #id-2 |
> message.EnvelopeIdResolver
> 2011-03-23 14:33:41,159 DEBUG | exit engineResolve, result:
> XMLSignatureInput/Element/[soap:Body: null] exclude null comments:false/null
> | message.EnvelopeIdResolver
> 2011-03-23 14:33:41,159 DEBUG | setElement("ds:Transform", "null") |
> utils.ElementProxy
> 2011-03-23 14:33:41,159 DEBUG | Pre-digested input: |
> utils.DigesterOutputStream
> 2011-03-23 14:33:41,159 DEBUG | xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
> wsu:Id="id-2"> xmlns="http://apache.org/hello_world_soap_http/types";>Master
> xmlns="http://apache.org/hello_world_soap_http/types";>Master
> | utils.DigesterOutputStream
> 2011-03-23 14:33:41,159 WARN | Verification failed for URI "#id-2" |
> signature.Reference
> 2011-03-23 14:33:41,159 WARN | Expected Digest: yFxDQhgODwm09BOOEJwzrMzvfO4=
> | signature.Reference
> 2011-03-23 14:33:41,159 WARN | Actual Digest: l9AeEEtC5yLW+5gbX/vJunbkhrU= |
> signature.Reference
> {quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-3414) Signature verification fails with custom SOAP header
[
https://issues.apache.org/jira/browse/CXF-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Granseuer resolved CXF-3414.
-
Resolution: Invalid
> Signature verification fails with custom SOAP header
>
>
> Key: CXF-3414
> URL: https://issues.apache.org/jira/browse/CXF-3414
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 2.3.2
>Reporter: Jens Granseuer
> Attachments: signature-handler.zip
>
>
> When a client sends a signed message body, and also includes a custom SOAP
> header in the message, signature verification fails at the receiving end.
> {quote}
> 2011-03-23 14:33:41,159 DEBUG | verify 1 References | signature.Manifest
> 2011-03-23 14:33:41,159 DEBUG | I am not requested to follow nested Manifests
> | signature.Manifest
> 2011-03-23 14:33:41,159 DEBUG | setElement("ds:Reference", "null") |
> utils.ElementProxy
> 2011-03-23 14:33:41,159 DEBUG | setElement("ds:Transforms", "null") |
> utils.ElementProxy
> 2011-03-23 14:33:41,159 DEBUG | Request for URI
> http://www.w3.org/2000/09/xmldsig#sha1 | algorithms.JCEMapper
> 2011-03-23 14:33:41,159 DEBUG | I was asked to create a ResourceResolver and
> got 1 | resolver.ResourceResolver
> 2011-03-23 14:33:41,159 DEBUG | extra resolvers to my existing 4 system-wide
> resolvers | resolver.ResourceResolver
> 2011-03-23 14:33:41,159 DEBUG | check resolvability by class
> org.apache.ws.security.message.EnvelopeIdResolver | resolver.ResourceResolver
> 2011-03-23 14:33:41,159 DEBUG | enter engineResolve, look for: #id-2 |
> message.EnvelopeIdResolver
> 2011-03-23 14:33:41,159 DEBUG | exit engineResolve, result:
> XMLSignatureInput/Element/[soap:Body: null] exclude null comments:false/null
> | message.EnvelopeIdResolver
> 2011-03-23 14:33:41,159 DEBUG | setElement("ds:Transform", "null") |
> utils.ElementProxy
> 2011-03-23 14:33:41,159 DEBUG | Pre-digested input: |
> utils.DigesterOutputStream
> 2011-03-23 14:33:41,159 DEBUG | xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
> wsu:Id="id-2"> xmlns="http://apache.org/hello_world_soap_http/types";>Master
> xmlns="http://apache.org/hello_world_soap_http/types";>Master
> | utils.DigesterOutputStream
> 2011-03-23 14:33:41,159 WARN | Verification failed for URI "#id-2" |
> signature.Reference
> 2011-03-23 14:33:41,159 WARN | Expected Digest: yFxDQhgODwm09BOOEJwzrMzvfO4=
> | signature.Reference
> 2011-03-23 14:33:41,159 WARN | Actual Digest: l9AeEEtC5yLW+5gbX/vJunbkhrU= |
> signature.Reference
> {quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3415) Make JAXB-based providers endpoint-scoped
Make JAXB-based providers endpoint-scoped - Key: CXF-3415 URL: https://issues.apache.org/jira/browse/CXF-3415 Project: CXF Issue Type: Improvement Components: JAX-RS Affects Versions: 2.4 Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin Fix For: 2.4 JAXB providers have static Maps of JAXB contexts, additionally default JAXB providers are shared between all the endpoints which prevents the JAXBContexts from being recycled. Dynamically cloning the default providers seems to be the best option at this stage; adding them early to endpoint-specific ProviderFactory instances is problematic as they can interfere with other custom XML/JSON providers in cases where they are deemed to be equal by the sort algorithm or when custom providers have weaker media types (with wildcards). Adding them dynamically might create some minor contention but only at the start. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3416) Have wsdl2java generate a constructor that sets all fields
Have wsdl2java generate a constructor that sets all fields -- Key: CXF-3416 URL: https://issues.apache.org/jira/browse/CXF-3416 Project: CXF Issue Type: Improvement Components: Soap Binding Reporter: Dobes Vandermeer Be nice to have the data classes generated by wsdl2java so that you can construct them easily, either by having a constructor to fill in all the fields or have the setters return "this" so you can chain them together. Otherwise constructing a tree objects becomes quite a lot of work. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3416) Have wsdl2java generate a constructor that sets all fields
[ https://issues.apache.org/jira/browse/CXF-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010576#comment-13010576 ] Freeman Fang commented on CXF-3416: --- Hi, I think the -defaultValues flag of wsdl2java is what you want, paste the wsdl2java -h result about this flag -defaultValues<=class-name-for-DefaultValueProvider> Specifies that default values are generated for the dummy implementation and client. You can specify the name of the class to provide the default values. The default is RandomValueProvider. Freeman > Have wsdl2java generate a constructor that sets all fields > -- > > Key: CXF-3416 > URL: https://issues.apache.org/jira/browse/CXF-3416 > Project: CXF > Issue Type: Improvement > Components: Soap Binding >Reporter: Dobes Vandermeer > > Be nice to have the data classes generated by wsdl2java so that you can > construct them easily, either by having a constructor to fill in all the > fields or have the setters return "this" so you can chain them together. > Otherwise constructing a tree objects becomes quite a lot of work. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
