[jira] [Commented] (CXF-5367) 2.7.7 schema validation incorrectly detects schema include recursion
[
https://issues.apache.org/jira/browse/CXF-5367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809516#comment-13809516
]
Jesse Pangburn commented on CXF-5367:
-
I have tested the 2.7.8-SNAPSHOT against this test case and it works great!
Thanks Dan!
> 2.7.7 schema validation incorrectly detects schema include recursion
>
>
> Key: CXF-5367
> URL: https://issues.apache.org/jira/browse/CXF-5367
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 2.7.7
>Reporter: Jesse Pangburn
> Labels: schema, validation
> Fix For: 2.7.8
>
> Attachments: jaxws_dispatch_provider_schematest_XDSb_276.zip,
> jaxws_dispatch_provider_schematest_XDSb_277.zip
>
>
> With 2.7.7 it does validate schemas when configured correctly but fails with
> schemas that have circular references to each other (not illegal according to
> W3C spec or their schema validator tool online). The schemas it's having
> trouble with are from the HL7 standards body, which are used by hundreds of
> companies. I tested the schema that it complains about using the W3C online
> validator like this:
> {quote}
> http://www.w3.org/2001/03/webdata/xsv?docAddrs=http%3A%2F%2Fdl.dropboxusercontent.com%2Fu%2F13558558%2Fschematest%2Fschema%2FHL7V3%2FNE2008%2Fcoreschemas%2Fvoc.xsd&warnings=on&independent=on&style=xsl#
> {quote}
> It comes back and says (among many things):
> {quote}
> The schema(s) used for schema-validation had no errors
> {quote}
> I will attach two samples, one for 2.7.6 and one for 2.7.7. With 2.7.6, it
> validates correctly. With 2.7.7 it complains about a recursive reference.
> The problem it seems is that voc.xsd includes datatypes.xsd includes
> datatypes-base.xsd includes voc.xsd. The schema validator gets around to the
> recursive point and says:
> {quote}
> Attempt to load a schema document from
> http://dl.dropboxusercontent.com/u/13558558/schematest/schema/HL7V3/NE2008/coreschemas/voc.xsd
> (source: include) for no namespace, skipped, already loaded
> {quote}
> So the W3C validator sees the loop and knows its already been included so it
> ignores the recursion beyond the first loop.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CXF-5367) 2.7.7 schema validation incorrectly detects schema include recursion
[
https://issues.apache.org/jira/browse/CXF-5367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Pangburn updated CXF-5367:
Attachment: jaxws_dispatch_provider_schematest_XDSb_277.zip
jaxws_dispatch_provider_schematest_XDSb_276.zip
To test these, expand the samples into the corresponding 2.7.6 or 2.7.7
installation's samples directory. Run by start the server in one terminal:
{quote}
mvn -P server
{quote}
And after it starts, then the client in another:
{quote}
mvn -P client
{quote}
In 2.7.6, you'll see the response from the server printed out on the client
indicating success. In 2.7.7, you'll see a long output from the schema
validation system about why it failed. If you look for the first "SEVERE" log
output, you'll see it talking about recursion.
> 2.7.7 schema validation incorrectly detects schema include recursion
>
>
> Key: CXF-5367
> URL: https://issues.apache.org/jira/browse/CXF-5367
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 2.7.7
>Reporter: Jesse Pangburn
> Labels: schema, validation
> Attachments: jaxws_dispatch_provider_schematest_XDSb_276.zip,
> jaxws_dispatch_provider_schematest_XDSb_277.zip
>
>
> With 2.7.7 it does validate schemas when configured correctly but fails with
> schemas that have circular references to each other (not illegal according to
> W3C spec or their schema validator tool online). The schemas it's having
> trouble with are from the HL7 standards body, which are used by hundreds of
> companies. I tested the schema that it complains about using the W3C online
> validator like this:
> {quote}
> http://www.w3.org/2001/03/webdata/xsv?docAddrs=http%3A%2F%2Fdl.dropboxusercontent.com%2Fu%2F13558558%2Fschematest%2Fschema%2FHL7V3%2FNE2008%2Fcoreschemas%2Fvoc.xsd&warnings=on&independent=on&style=xsl#
> {quote}
> It comes back and says (among many things):
> {quote}
> The schema(s) used for schema-validation had no errors
> {quote}
> I will attach two samples, one for 2.7.6 and one for 2.7.7. With 2.7.6, it
> validates correctly. With 2.7.7 it complains about a recursive reference.
> The problem it seems is that voc.xsd includes datatypes.xsd includes
> datatypes-base.xsd includes voc.xsd. The schema validator gets around to the
> recursive point and says:
> {quote}
> Attempt to load a schema document from
> http://dl.dropboxusercontent.com/u/13558558/schematest/schema/HL7V3/NE2008/coreschemas/voc.xsd
> (source: include) for no namespace, skipped, already loaded
> {quote}
> So the W3C validator sees the loop and knows its already been included so it
> ignores the recursion beyond the first loop.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (CXF-5367) 2.7.7 schema validation incorrectly detects schema include recursion
Jesse Pangburn created CXF-5367:
---
Summary: 2.7.7 schema validation incorrectly detects schema
include recursion
Key: CXF-5367
URL: https://issues.apache.org/jira/browse/CXF-5367
Project: CXF
Issue Type: Bug
Components: JAX-WS Runtime
Affects Versions: 2.7.7
Reporter: Jesse Pangburn
With 2.7.7 it does validate schemas when configured correctly but fails with
schemas that have circular references to each other (not illegal according to
W3C spec or their schema validator tool online). The schemas it's having
trouble with are from the HL7 standards body, which are used by hundreds of
companies. I tested the schema that it complains about using the W3C online
validator like this:
{quote}
http://www.w3.org/2001/03/webdata/xsv?docAddrs=http%3A%2F%2Fdl.dropboxusercontent.com%2Fu%2F13558558%2Fschematest%2Fschema%2FHL7V3%2FNE2008%2Fcoreschemas%2Fvoc.xsd&warnings=on&independent=on&style=xsl#
{quote}
It comes back and says (among many things):
{quote}
The schema(s) used for schema-validation had no errors
{quote}
I will attach two samples, one for 2.7.6 and one for 2.7.7. With 2.7.6, it
validates correctly. With 2.7.7 it complains about a recursive reference. The
problem it seems is that voc.xsd includes datatypes.xsd includes
datatypes-base.xsd includes voc.xsd. The schema validator gets around to the
recursive point and says:
{quote}
Attempt to load a schema document from
http://dl.dropboxusercontent.com/u/13558558/schematest/schema/HL7V3/NE2008/coreschemas/voc.xsd
(source: include) for no namespace, skipped, already loaded
{quote}
So the W3C validator sees the loop and knows its already been included so it
ignores the recursion beyond the first loop.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CXF-5365) 2.7.7 schema validation seems broken
[ https://issues.apache.org/jira/browse/CXF-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808464#comment-13808464 ] Jesse Pangburn commented on CXF-5365: - OK, verified with addition of that dependency that the problem goes away and 2.7.7 is validating correctly. However, it seems this sample is not triggering the original problem that caused me to notice this. I'll create a separate issue for that problem since you found and fixed related bugs in this one already. thanks! > 2.7.7 schema validation seems broken > > > Key: CXF-5365 > URL: https://issues.apache.org/jira/browse/CXF-5365 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Affects Versions: 2.7.7 >Reporter: Jesse Pangburn >Assignee: Daniel Kulp > Labels: schema, validation > Fix For: 2.7.8 > > Attachments: jaxws_dispatch_provider_schematest_276.zip, > jaxws_dispatch_provider_schematest_277.zip > > > Turning on schema validation in 2.7.7 seems to have a number of problems. In > the case of my own embedded CXF, it does validate but fails with schemas that > have circular references to each other (not illegal according to W3C spec or > their schema validator tool online). > So I wrote a test sample but found that in the test sample that it doesn't > validate the schema at all- just lets the bad elements go through with no > error. The 2.7.6 version of the sample properly throws an error- and all I > did to create the 2.7.6 version was to copy the sample folder under 2.7.6 and > search/replace 2.7.7 in the pom.xml with 2.7.6. > For this issue, I think we should try to solve why 2.7.6 properly throws an > exception on a request with a bad schema and why 2.7.7 does not. I'll check > separately if the resolution to this fixes my initial problem and if it > doesn't then I'll create a separate issue for that along with a test case. > I will attach the test sample after creating the issue. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CXF-5365) 2.7.7 schema validation seems broken
[ https://issues.apache.org/jira/browse/CXF-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Pangburn updated CXF-5365: Attachment: jaxws_dispatch_provider_schematest_276.zip jaxws_dispatch_provider_schematest_277.zip To run these, expand in the 2.7.6 or 2.7.7 samples folder accordingly. Then in one terminal run: mvn -P server This starts up two different services (same types, different URL only). One is configured in Java to have schema validation on, the other is configured in spring to have schema validation on. Correspondingly, there are two client profiles. They are run like this: mvn -P client mvn -P clientspring The "clientspring" profile targets the Spring configured service. Both of these profiles send two messages- one which doesn't violate schema and one which does. In 2.7.6, both profiles correctly send the first message and then the second message generates a schema error. In 2.7.7, both messages in both profiles are accepted and the response is sent normally with no errors. So schema validation is either off entirely, or it's not engaging because the schema files referred to by the WSDLs import each other. > 2.7.7 schema validation seems broken > > > Key: CXF-5365 > URL: https://issues.apache.org/jira/browse/CXF-5365 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Affects Versions: 2.7.7 >Reporter: Jesse Pangburn > Labels: schema, validation > Attachments: jaxws_dispatch_provider_schematest_276.zip, > jaxws_dispatch_provider_schematest_277.zip > > > Turning on schema validation in 2.7.7 seems to have a number of problems. In > the case of my own embedded CXF, it does validate but fails with schemas that > have circular references to each other (not illegal according to W3C spec or > their schema validator tool online). > So I wrote a test sample but found that in the test sample that it doesn't > validate the schema at all- just lets the bad elements go through with no > error. The 2.7.6 version of the sample properly throws an error- and all I > did to create the 2.7.6 version was to copy the sample folder under 2.7.6 and > search/replace 2.7.7 in the pom.xml with 2.7.6. > For this issue, I think we should try to solve why 2.7.6 properly throws an > exception on a request with a bad schema and why 2.7.7 does not. I'll check > separately if the resolution to this fixes my initial problem and if it > doesn't then I'll create a separate issue for that along with a test case. > I will attach the test sample after creating the issue. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CXF-5365) 2.7.7 schema validation seems broken
Jesse Pangburn created CXF-5365: --- Summary: 2.7.7 schema validation seems broken Key: CXF-5365 URL: https://issues.apache.org/jira/browse/CXF-5365 Project: CXF Issue Type: Bug Components: JAX-WS Runtime Affects Versions: 2.7.7 Reporter: Jesse Pangburn Turning on schema validation in 2.7.7 seems to have a number of problems. In the case of my own embedded CXF, it does validate but fails with schemas that have circular references to each other (not illegal according to W3C spec or their schema validator tool online). So I wrote a test sample but found that in the test sample that it doesn't validate the schema at all- just lets the bad elements go through with no error. The 2.7.6 version of the sample properly throws an error- and all I did to create the 2.7.6 version was to copy the sample folder under 2.7.6 and search/replace 2.7.7 in the pom.xml with 2.7.6. For this issue, I think we should try to solve why 2.7.6 properly throws an exception on a request with a bad schema and why 2.7.7 does not. I'll check separately if the resolution to this fixes my initial problem and if it doesn't then I'll create a separate issue for that along with a test case. I will attach the test sample after creating the issue. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CXF-5354) faultTo address is ignored when fault is thrown
[
https://issues.apache.org/jira/browse/CXF-5354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13804783#comment-13804783
]
Jesse Pangburn commented on CXF-5354:
-
I ran the test module and it was successful. I also ran it in my own system
where I initially found the problem and verified that faults (from a couple
different causes) are sent back to the faultTo address, and successful replies
are sent to the replyTo (whether using anonymous or a callback URL). Looks all
good to me, thanks for the super quick fix Dan!!!
> faultTo address is ignored when fault is thrown
> ---
>
> Key: CXF-5354
> URL: https://issues.apache.org/jira/browse/CXF-5354
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 2.7.7
>Reporter: Jesse Pangburn
>Assignee: Daniel Kulp
> Fix For: 2.7.8, 2.6.11
>
> Attachments: jaxws_dispatch_provider_test_faultto.zip
>
>
> I have a Provider based service and find that with WS-Addressing enabled, it
> doesn't handle FaultTo addresses properly. The case I found that caused this
> is when I turned on Schema Validation and sent a request that doesn't match
> the schema, then it throws a fault but instead sends the reply to the replyTo
> address. I then tried using a bogus mustUnderstand header to cause a fault
> to see if it was just related to the schema validation, but it has the same
> problem.
> Here's a sample request message to cause this (using mustUnderstand header so
> you don't have to setup schema validation to test):
> {code:xml}
>
> http://www.w3.org/2003/05/soap-envelope";>
>
> http://www.w3.org/2005/08/addressing";>anything
> xmlns="http://www.w3.org/2005/08/addressing";>urn:uuid:2eae8433-d42a-4749-b053-f5b5805fe8e9
> xmlns="http://www.w3.org/2005/08/addressing";>http://localhost:9003/xdsregistryb
> http://www.w3.org/2005/08/addressing";>
> http://localhost:9003/replyBack
>
> http://www.w3.org/2005/08/addressing";>
> http://localhost:9003/faultBack
>
> this junk will fault
>
>
>
>
>
> {code}
> Note the ReplyTo is http://localhost:9003/replyBack and the FaultTo is
> http://localhost:9003/faultBack. When I send to my Provider service, the log
> file shows the response going to the replyBack url, but the To address in
> WS-Addressing header shows the faultBack url- so it's halfway right! This is
> the case with both schema validation faults and the above example of bogus
> mustUnderstand header.
> Here's the Wireshark network trace (so there is no possibility of bad logging
> being the issue):
> {quote}
> POST /replyBack HTTP/1.1
> Content-Type: application/soap+xml; charset=UTF-8
> Accept: */*
> User-Agent: Apache CXF 2.7.7
> Cache-Control: no-cache
> Pragma: no-cache
> Host: localhost:9003
> Connection: keep-alive
> Content-Length: 706
> xmlns:soap="http://www.w3.org/2003/05/soap-envelope";> xmlns="http://www.w3.org/2005/08/addressing"/> xmlns="http://www.w3.org/2005/08/addressing";>urn:uuid:6a5190fc-256f-428c-9e5e-8b79520bbf0c
> xmlns="http://www.w3.org/2005/08/addressing";>http://localhost:9003/faultBack
> xmlns="http://www.w3.org/2005/08/addressing";>urn:uuid:2eae8433-d42a-4749-b053-f5b5805fe8e9soap:MustUnderstand xml:lang="en">MustUnderstand headers: [bogus] are not
> understood.
> {quote}
> Sorry, wiki markup is making bogus in red, not intentional. See how the
> address listed at the top doesn't match the WS-Addressing To address? With
> anonymous replyTo address then you get the fault back on the same synchronous
> request channel, and it still shows the /faultBack url in the To address.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (CXF-5354) faultTo address is ignored when fault is thrown
[
https://issues.apache.org/jira/browse/CXF-5354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13803572#comment-13803572
]
Jesse Pangburn edited comment on CXF-5354 at 10/23/13 11:58 PM:
See attachment for a modification of the 2.7.6 jaxws_dispatch_provider sample
(first noticed the problem on my 2.7.7 installation, so used an older 2.7.6
installation to make sure it wasn't a problem specific to 2.7.7) to illustrate
the problem. To run it, open a terminal and execute:
mvn -P server
Then open another terminal and execute:
mvn -P client
The client requests a replyTo at one URL and a faultTo at another. There's
nothing actually listening on these URLs but they are on the same port (9000)
that the server is listening on, so in the server output you see:
org.apache.cxf.transport.http.HTTPException: HTTP response '404: Not Found'
when communicating with http://localhost:9000/replyBack
This is where it's trying to send the fault- to the replyTo address instead of
the faultTo address.
was (Author: jpangburn):
This is a modification of the 2.7.6 jaxws_dispatch_provider sample (first
noticed the problem on my 2.7.7 installation, so used an older 2.7.6
installation to make sure it wasn't a problem specific to 2.7.7) to illustrate
the problem. To run it, open a terminal and execute:
mvn -P server
Then open another terminal and execute:
mvn -P client
The client requests a replyTo at one URL and a faultTo at another. There's
nothing actually listening on these URLs but they are on the same port (9000)
that the server is listening on, so in the server output you see:
org.apache.cxf.transport.http.HTTPException: HTTP response '404: Not Found'
when communicating with http://localhost:9000/replyBack
This is where it's trying to send the fault- to the replyTo address instead of
the faultTo address.
> faultTo address is ignored when fault is thrown
> ---
>
> Key: CXF-5354
> URL: https://issues.apache.org/jira/browse/CXF-5354
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 2.7.7
>Reporter: Jesse Pangburn
> Attachments: jaxws_dispatch_provider_test_faultto.zip
>
>
> I have a Provider based service and find that with WS-Addressing enabled, it
> doesn't handle FaultTo addresses properly. The case I found that caused this
> is when I turned on Schema Validation and sent a request that doesn't match
> the schema, then it throws a fault but instead sends the reply to the replyTo
> address. I then tried using a bogus mustUnderstand header to cause a fault
> to see if it was just related to the schema validation, but it has the same
> problem.
> Here's a sample request message to cause this (using mustUnderstand header so
> you don't have to setup schema validation to test):
> {code:xml}
>
> http://www.w3.org/2003/05/soap-envelope";>
>
> http://www.w3.org/2005/08/addressing";>anything
> xmlns="http://www.w3.org/2005/08/addressing";>urn:uuid:2eae8433-d42a-4749-b053-f5b5805fe8e9
> xmlns="http://www.w3.org/2005/08/addressing";>http://localhost:9003/xdsregistryb
> http://www.w3.org/2005/08/addressing";>
> http://localhost:9003/replyBack
>
> http://www.w3.org/2005/08/addressing";>
> http://localhost:9003/faultBack
>
> this junk will fault
>
>
>
>
>
> {code}
> Note the ReplyTo is http://localhost:9003/replyBack and the FaultTo is
> http://localhost:9003/faultBack. When I send to my Provider service, the log
> file shows the response going to the replyBack url, but the To address in
> WS-Addressing header shows the faultBack url- so it's halfway right! This is
> the case with both schema validation faults and the above example of bogus
> mustUnderstand header.
> Here's the Wireshark network trace (so there is no possibility of bad logging
> being the issue):
> {quote}
> POST /replyBack HTTP/1.1
> Content-Type: application/soap+xml; charset=UTF-8
> Accept: */*
> User-Agent: Apache CXF 2.7.7
> Cache-Control: no-cache
> Pragma: no-cache
> Host: localhost:9003
> Connection: keep-alive
> Content-Length: 706
> xmlns:soap="http://www.w3.org/2003/05/soap-envelope";> xmlns="http://www.w3.org/2005/08/addressing"/> xmlns="http://www.w3.org/2005/08/addressing";>urn:uuid:6a5190fc-256f-428c-9e5e-8b79520bbf0c
> xmlns="http://www.w3.org/2005/08/addressing";>http://localhost:9003/faultBack
> xmlns="http://www.w3.org/2005/08/addressing";>urn:uuid:2eae8433-d42a-4749-b053-f5b5805fe8e9soap:MustUnderstand xml:lang="en">MustUnderstand headers: [bogus] are not
> understood.
> {quote}
> Sorry, wiki markup is making bogus in red, not intentional. See how the
> address listed at the top doesn't match the WS-Addressing To address? With
> anonymous replyTo address then you get
[jira] [Updated] (CXF-5354) faultTo address is ignored when fault is thrown
[
https://issues.apache.org/jira/browse/CXF-5354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Pangburn updated CXF-5354:
Attachment: jaxws_dispatch_provider_test_faultto.zip
This is a modification of the 2.7.6 jaxws_dispatch_provider sample (first
noticed the problem on my 2.7.7 installation, so used an older 2.7.6
installation to make sure it wasn't a problem specific to 2.7.7) to illustrate
the problem. To run it, open a terminal and execute:
mvn -P server
Then open another terminal and execute:
mvn -P client
The client requests a replyTo at one URL and a faultTo at another. There's
nothing actually listening on these URLs but they are on the same port (9000)
that the server is listening on, so in the server output you see:
org.apache.cxf.transport.http.HTTPException: HTTP response '404: Not Found'
when communicating with http://localhost:9000/replyBack
This is where it's trying to send the fault- to the replyTo address instead of
the faultTo address.
> faultTo address is ignored when fault is thrown
> ---
>
> Key: CXF-5354
> URL: https://issues.apache.org/jira/browse/CXF-5354
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 2.7.7
>Reporter: Jesse Pangburn
> Attachments: jaxws_dispatch_provider_test_faultto.zip
>
>
> I have a Provider based service and find that with WS-Addressing enabled, it
> doesn't handle FaultTo addresses properly. The case I found that caused this
> is when I turned on Schema Validation and sent a request that doesn't match
> the schema, then it throws a fault but instead sends the reply to the replyTo
> address. I then tried using a bogus mustUnderstand header to cause a fault
> to see if it was just related to the schema validation, but it has the same
> problem.
> Here's a sample request message to cause this (using mustUnderstand header so
> you don't have to setup schema validation to test):
> {code:xml}
>
> http://www.w3.org/2003/05/soap-envelope";>
>
> http://www.w3.org/2005/08/addressing";>anything
> xmlns="http://www.w3.org/2005/08/addressing";>urn:uuid:2eae8433-d42a-4749-b053-f5b5805fe8e9
> xmlns="http://www.w3.org/2005/08/addressing";>http://localhost:9003/xdsregistryb
> http://www.w3.org/2005/08/addressing";>
> http://localhost:9003/replyBack
>
> http://www.w3.org/2005/08/addressing";>
> http://localhost:9003/faultBack
>
> this junk will fault
>
>
>
>
>
> {code}
> Note the ReplyTo is http://localhost:9003/replyBack and the FaultTo is
> http://localhost:9003/faultBack. When I send to my Provider service, the log
> file shows the response going to the replyBack url, but the To address in
> WS-Addressing header shows the faultBack url- so it's halfway right! This is
> the case with both schema validation faults and the above example of bogus
> mustUnderstand header.
> Here's the Wireshark network trace (so there is no possibility of bad logging
> being the issue):
> {quote}
> POST /replyBack HTTP/1.1
> Content-Type: application/soap+xml; charset=UTF-8
> Accept: */*
> User-Agent: Apache CXF 2.7.7
> Cache-Control: no-cache
> Pragma: no-cache
> Host: localhost:9003
> Connection: keep-alive
> Content-Length: 706
> xmlns:soap="http://www.w3.org/2003/05/soap-envelope";> xmlns="http://www.w3.org/2005/08/addressing"/> xmlns="http://www.w3.org/2005/08/addressing";>urn:uuid:6a5190fc-256f-428c-9e5e-8b79520bbf0c
> xmlns="http://www.w3.org/2005/08/addressing";>http://localhost:9003/faultBack
> xmlns="http://www.w3.org/2005/08/addressing";>urn:uuid:2eae8433-d42a-4749-b053-f5b5805fe8e9soap:MustUnderstand xml:lang="en">MustUnderstand headers: [bogus] are not
> understood.
> {quote}
> Sorry, wiki markup is making bogus in red, not intentional. See how the
> address listed at the top doesn't match the WS-Addressing To address? With
> anonymous replyTo address then you get the fault back on the same synchronous
> request channel, and it still shows the /faultBack url in the To address.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CXF-5354) faultTo address is ignored when fault is thrown
[
https://issues.apache.org/jira/browse/CXF-5354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13802531#comment-13802531
]
Jesse Pangburn commented on CXF-5354:
-
Issue 4382 indicates this should work, but at least in these cases listed it
does not.
> faultTo address is ignored when fault is thrown
> ---
>
> Key: CXF-5354
> URL: https://issues.apache.org/jira/browse/CXF-5354
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 2.7.7
>Reporter: Jesse Pangburn
>
> I have a Provider based service and find that with WS-Addressing enabled, it
> doesn't handle FaultTo addresses properly. The case I found that caused this
> is when I turned on Schema Validation and sent a request that doesn't match
> the schema, then it throws a fault but instead sends the reply to the replyTo
> address. I then tried using a bogus mustUnderstand header to cause a fault
> to see if it was just related to the schema validation, but it has the same
> problem.
> Here's a sample request message to cause this (using mustUnderstand header so
> you don't have to setup schema validation to test):
> {code:xml}
>
> http://www.w3.org/2003/05/soap-envelope";>
>
> http://www.w3.org/2005/08/addressing";>anything
> xmlns="http://www.w3.org/2005/08/addressing";>urn:uuid:2eae8433-d42a-4749-b053-f5b5805fe8e9
> xmlns="http://www.w3.org/2005/08/addressing";>http://localhost:9003/xdsregistryb
> http://www.w3.org/2005/08/addressing";>
> http://localhost:9003/replyBack
>
> http://www.w3.org/2005/08/addressing";>
> http://localhost:9003/faultBack
>
> this junk will fault
>
>
>
>
>
> {code}
> Note the ReplyTo is http://localhost:9003/replyBack and the FaultTo is
> http://localhost:9003/faultBack. When I send to my Provider service, the log
> file shows the response going to the replyBack url, but the To address in
> WS-Addressing header shows the faultBack url- so it's halfway right! This is
> the case with both schema validation faults and the above example of bogus
> mustUnderstand header.
> Here's the Wireshark network trace (so there is no possibility of bad logging
> being the issue):
> {quote}
> POST /replyBack HTTP/1.1
> Content-Type: application/soap+xml; charset=UTF-8
> Accept: */*
> User-Agent: Apache CXF 2.7.7
> Cache-Control: no-cache
> Pragma: no-cache
> Host: localhost:9003
> Connection: keep-alive
> Content-Length: 706
> xmlns:soap="http://www.w3.org/2003/05/soap-envelope";> xmlns="http://www.w3.org/2005/08/addressing"/> xmlns="http://www.w3.org/2005/08/addressing";>urn:uuid:6a5190fc-256f-428c-9e5e-8b79520bbf0c
> xmlns="http://www.w3.org/2005/08/addressing";>http://localhost:9003/faultBack
> xmlns="http://www.w3.org/2005/08/addressing";>urn:uuid:2eae8433-d42a-4749-b053-f5b5805fe8e9soap:MustUnderstand xml:lang="en">MustUnderstand headers: [bogus] are not
> understood.
> {quote}
> Sorry, wiki markup is making bogus in red, not intentional. See how the
> address listed at the top doesn't match the WS-Addressing To address? With
> anonymous replyTo address then you get the fault back on the same synchronous
> request channel, and it still shows the /faultBack url in the To address.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (CXF-5354) faultTo address is ignored when fault is thrown
Jesse Pangburn created CXF-5354:
---
Summary: faultTo address is ignored when fault is thrown
Key: CXF-5354
URL: https://issues.apache.org/jira/browse/CXF-5354
Project: CXF
Issue Type: Bug
Components: WS-* Components
Affects Versions: 2.7.7
Reporter: Jesse Pangburn
I have a Provider based service and find that with WS-Addressing enabled, it
doesn't handle FaultTo addresses properly. The case I found that caused this
is when I turned on Schema Validation and sent a request that doesn't match the
schema, then it throws a fault but instead sends the reply to the replyTo
address. I then tried using a bogus mustUnderstand header to cause a fault to
see if it was just related to the schema validation, but it has the same
problem.
Here's a sample request message to cause this (using mustUnderstand header so
you don't have to setup schema validation to test):
{code:xml}
http://www.w3.org/2003/05/soap-envelope";>
http://www.w3.org/2005/08/addressing";>anything
http://www.w3.org/2005/08/addressing";>urn:uuid:2eae8433-d42a-4749-b053-f5b5805fe8e9
http://www.w3.org/2005/08/addressing";>http://localhost:9003/xdsregistryb
http://www.w3.org/2005/08/addressing";>
http://localhost:9003/replyBack
http://www.w3.org/2005/08/addressing";>
http://localhost:9003/faultBack
this junk will fault
{code}
Note the ReplyTo is http://localhost:9003/replyBack and the FaultTo is
http://localhost:9003/faultBack. When I send to my Provider service, the log
file shows the response going to the replyBack url, but the To address in
WS-Addressing header shows the faultBack url- so it's halfway right! This is
the case with both schema validation faults and the above example of bogus
mustUnderstand header.
Here's the Wireshark network trace (so there is no possibility of bad logging
being the issue):
{quote}
POST /replyBack HTTP/1.1
Content-Type: application/soap+xml; charset=UTF-8
Accept: */*
User-Agent: Apache CXF 2.7.7
Cache-Control: no-cache
Pragma: no-cache
Host: localhost:9003
Connection: keep-alive
Content-Length: 706
http://www.w3.org/2003/05/soap-envelope";>http://www.w3.org/2005/08/addressing"/>http://www.w3.org/2005/08/addressing";>urn:uuid:6a5190fc-256f-428c-9e5e-8b79520bbf0chttp://www.w3.org/2005/08/addressing";>http://localhost:9003/faultBackhttp://www.w3.org/2005/08/addressing";>urn:uuid:2eae8433-d42a-4749-b053-f5b5805fe8e9soap:MustUnderstandMustUnderstand headers: [bogus] are not
understood.
{quote}
Sorry, wiki markup is making bogus in red, not intentional. See how the
address listed at the top doesn't match the WS-Addressing To address? With
anonymous replyTo address then you get the fault back on the same synchronous
request channel, and it still shows the /faultBack url in the To address.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CXF-5317) Policy exception handler throws away useful exception stack trace
[ https://issues.apache.org/jira/browse/CXF-5317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Pangburn updated CXF-5317: Description: I had a working WS-Policy which was encrypting the SOAP body with a UsernameToken using Basic128 encryption, then I modified the policy to use Basic256 encryption instead. I got the following stack trace cause: Caused by: org.apache.cxf.ws.policy.PolicyException: Cannot encrypt data at org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.policyNotAsserted(AbstractBindingBuilder.java:294) Since the exception was short on detail, I went to the source code and found that AbstractBindingBuilder.java:294 was simply throwing away the rest of the Exception object. There's a method existing already to take the exception too so I changed that line to call it and now get the following MUCH more useful error message on the end of the stack trace: Caused by: org.apache.xml.security.encryption.XMLEncryptionException: Invalid AES key length: 20 bytes Original Exception was java.security.InvalidKeyException: Invalid AES key length: 20 bytes I chose priority Major because without this user will report the error "cannot encrypt data" which will give developers very little to go on. The only way to find the real problem is to attach a debugger which is not an option for everybody. I'll attach a patch to this issue to resolve this. was: I had a working WS-Policy which was encrypting the SOAP body with a UsernameToken using Basic128 encryption, then I modified the policy to use Basic256 encryption instead. I got the following stack trace cause: Caused by: org.apache.cxf.ws.policy.PolicyException: Cannot encrypt data at org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.policyNotAsserted(AbstractBindingBuilder.java:294) Since the exception was short on detail, I went to the source code and found that AbstractBindingBuilder.java:294 was simply throwing away the rest of the Exception object. There's a method existing already to take the exception too so I changed that line to call it and now get the following MUCH more useful error message on the end of the stack trace: Caused by: org.apache.xml.security.encryption.XMLEncryptionException: Invalid AES key length: 20 bytes Original Exception was java.security.InvalidKeyException: Invalid AES key length: 20 bytes I'll attach a patch to this issue to resolve this. > Policy exception handler throws away useful exception stack trace > - > > Key: CXF-5317 > URL: https://issues.apache.org/jira/browse/CXF-5317 > Project: CXF > Issue Type: Improvement > Components: WS-* Components >Affects Versions: 2.7.6, 2.7.7 >Reporter: Jesse Pangburn > Labels: patch, ws-policy, ws-security > Attachments: AbstractBindingBuilder.patch > > > I had a working WS-Policy which was encrypting the SOAP body with a > UsernameToken using Basic128 encryption, then I modified the policy to use > Basic256 encryption instead. I got the following stack trace cause: > Caused by: org.apache.cxf.ws.policy.PolicyException: Cannot encrypt data > at > org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.policyNotAsserted(AbstractBindingBuilder.java:294) > Since the exception was short on detail, I went to the source code and found > that AbstractBindingBuilder.java:294 was simply throwing away the rest of the > Exception object. There's a method existing already to take the exception > too so I changed that line to call it and now get the following MUCH more > useful error message on the end of the stack trace: > Caused by: org.apache.xml.security.encryption.XMLEncryptionException: Invalid > AES key length: 20 bytes > Original Exception was java.security.InvalidKeyException: Invalid AES key > length: 20 bytes > I chose priority Major because without this user will report the error > "cannot encrypt data" which will give developers very little to go on. The > only way to find the real problem is to attach a debugger which is not an > option for everybody. > I'll attach a patch to this issue to resolve this. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CXF-5317) Policy exception handler throws away useful exception stack trace
[ https://issues.apache.org/jira/browse/CXF-5317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Pangburn updated CXF-5317: Attachment: AbstractBindingBuilder.patch I copied the original 2.7.7 AbstractBindingBuilder.java to AbstractBindingBuilder.orig. Then updated the file with my improvement and created this patch file. > Policy exception handler throws away useful exception stack trace > - > > Key: CXF-5317 > URL: https://issues.apache.org/jira/browse/CXF-5317 > Project: CXF > Issue Type: Improvement > Components: WS-* Components >Affects Versions: 2.7.6, 2.7.7 >Reporter: Jesse Pangburn > Labels: patch, ws-policy, ws-security > Attachments: AbstractBindingBuilder.patch > > > I had a working WS-Policy which was encrypting the SOAP body with a > UsernameToken using Basic128 encryption, then I modified the policy to use > Basic256 encryption instead. I got the following stack trace cause: > Caused by: org.apache.cxf.ws.policy.PolicyException: Cannot encrypt data > at > org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.policyNotAsserted(AbstractBindingBuilder.java:294) > Since the exception was short on detail, I went to the source code and found > that AbstractBindingBuilder.java:294 was simply throwing away the rest of the > Exception object. There's a method existing already to take the exception > too so I changed that line to call it and now get the following MUCH more > useful error message on the end of the stack trace: > Caused by: org.apache.xml.security.encryption.XMLEncryptionException: Invalid > AES key length: 20 bytes > Original Exception was java.security.InvalidKeyException: Invalid AES key > length: 20 bytes > I'll attach a patch to this issue to resolve this. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CXF-5317) Policy exception handler throws away useful exception stack trace
Jesse Pangburn created CXF-5317: --- Summary: Policy exception handler throws away useful exception stack trace Key: CXF-5317 URL: https://issues.apache.org/jira/browse/CXF-5317 Project: CXF Issue Type: Improvement Components: WS-* Components Affects Versions: 2.7.7, 2.7.6 Reporter: Jesse Pangburn I had a working WS-Policy which was encrypting the SOAP body with a UsernameToken using Basic128 encryption, then I modified the policy to use Basic256 encryption instead. I got the following stack trace cause: Caused by: org.apache.cxf.ws.policy.PolicyException: Cannot encrypt data at org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.policyNotAsserted(AbstractBindingBuilder.java:294) Since the exception was short on detail, I went to the source code and found that AbstractBindingBuilder.java:294 was simply throwing away the rest of the Exception object. There's a method existing already to take the exception too so I changed that line to call it and now get the following MUCH more useful error message on the end of the stack trace: Caused by: org.apache.xml.security.encryption.XMLEncryptionException: Invalid AES key length: 20 bytes Original Exception was java.security.InvalidKeyException: Invalid AES key length: 20 bytes I'll attach a patch to this issue to resolve this. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CXF-5267) WebClient using POST with chunking enabled (the default) can't read 401 error response stream
[
https://issues.apache.org/jira/browse/CXF-5267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13776510#comment-13776510
]
Jesse Pangburn commented on CXF-5267:
-
Fixed in Java 7 is good to know, thanks! So for users reading this, the
summary of fixes are:
- use a Conduit and turn off chunking
- use Java 7
- add the jar specified above and set the property on your WebClient to use it
> WebClient using POST with chunking enabled (the default) can't read 401 error
> response stream
> -
>
> Key: CXF-5267
> URL: https://issues.apache.org/jira/browse/CXF-5267
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.5.3, 2.7.5
> Environment: Linux
>Reporter: Jesse Pangburn
>Priority: Minor
>
> If I use WebClient to POST a message to a server, then I can't read the 401
> error response stream. If I use GET, then I can read the response stream
> just fine. If I use a HTTPConduit and disable chunking then I can read the
> response content just fine in all cases.
> Here's a short grid showing the tests I performed:
> ||GET/POST||chunking||return code||result||
> |GET|disabled|401|response message ok|
> |POST|disabled|401|response message ok|
> |POST|enabled (default)|401|response message BLANK!|
> |GET|enabled (default)|401|response message ok|
> |POST|enabled (default)|200|response message ok|
> Here's the code I'm using (requestStream and webClient are initialized above.
> webClient is a WebClient and requestStream is an InputStream.):
> {code:title=TestWSClient.java|borderStyle=solid}
> String requestMethod = "POST";
> InputStream responseStream = null;
> Response response = null;
> try{
> responseStream = webClient.invoke(requestMethod, requestStream,
> InputStream.class);
> } catch (Exception e){
> logger.log(Level.WARNING, "caught exception using webClient to call " +
> webClient.getCurrentURI().toString(), e);
> }finally{
> // always assign the Response object
> response = webClient.getResponse();
> // if the response entity is a LoadingByteArrayOutputStream, then we
> can still grab that response content
> try{
> Object entity = response.getEntity();
> if (entity instanceof ByteArrayInputStream){
> ByteArrayInputStream bais =
> (ByteArrayInputStream)entity;
> // the stream needs to be reset before we can really
> use it
> bais.reset();
> responseStream = bais;
> }
> }catch (Exception e){
> // darn, failed to get that response entity
> logger.log(Level.WARNING, "tried to get response message despite
> webClient exception, but failed", e);
> // nothing else we can do, at least Cloverleaf will get the 500
> response code and error is in the log
> }
> }
> {code}
> In the failure case, when I try to read (not shown) from the response stream
> I get a "-1" indicating the stream is empty.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-5267) WebClient using POST with chunking enabled (the default) can't read 401 error response stream
[
https://issues.apache.org/jira/browse/CXF-5267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13765849#comment-13765849
]
Jesse Pangburn commented on CXF-5267:
-
I found this page about it:
http://cxf.apache.org/docs/asynchronous-client-http-transport.html
Only trouble was I don't use Maven on my project, but I found the appropriate
jar, put it on my classpath, and with your suggested code then the problem went
away!
So looks to me like this is a good workaround for anyone else that may have
this same problem. For people on projects without Maven, here's the URL:
http://mvnrepository.com/artifact/org.apache.cxf/cxf-rt-transports-http-hc
Thanks for your help!
> WebClient using POST with chunking enabled (the default) can't read 401 error
> response stream
> -
>
> Key: CXF-5267
> URL: https://issues.apache.org/jira/browse/CXF-5267
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.5.3, 2.7.5
> Environment: Linux
>Reporter: Jesse Pangburn
>Priority: Minor
>
> If I use WebClient to POST a message to a server, then I can't read the 401
> error response stream. If I use GET, then I can read the response stream
> just fine. If I use a HTTPConduit and disable chunking then I can read the
> response content just fine in all cases.
> Here's a short grid showing the tests I performed:
> ||GET/POST||chunking||return code||result||
> |GET|disabled|401|response message ok|
> |POST|disabled|401|response message ok|
> |POST|enabled (default)|401|response message BLANK!|
> |GET|enabled (default)|401|response message ok|
> |POST|enabled (default)|200|response message ok|
> Here's the code I'm using (requestStream and webClient are initialized above.
> webClient is a WebClient and requestStream is an InputStream.):
> {code:title=TestWSClient.java|borderStyle=solid}
> String requestMethod = "POST";
> InputStream responseStream = null;
> Response response = null;
> try{
> responseStream = webClient.invoke(requestMethod, requestStream,
> InputStream.class);
> } catch (Exception e){
> logger.log(Level.WARNING, "caught exception using webClient to call " +
> webClient.getCurrentURI().toString(), e);
> }finally{
> // always assign the Response object
> response = webClient.getResponse();
> // if the response entity is a LoadingByteArrayOutputStream, then we
> can still grab that response content
> try{
> Object entity = response.getEntity();
> if (entity instanceof ByteArrayInputStream){
> ByteArrayInputStream bais =
> (ByteArrayInputStream)entity;
> // the stream needs to be reset before we can really
> use it
> bais.reset();
> responseStream = bais;
> }
> }catch (Exception e){
> // darn, failed to get that response entity
> logger.log(Level.WARNING, "tried to get response message despite
> webClient exception, but failed", e);
> // nothing else we can do, at least Cloverleaf will get the 500
> response code and error is in the log
> }
> }
> {code}
> In the failure case, when I try to read (not shown) from the response stream
> I get a "-1" indicating the stream is empty.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-5267) WebClient using POST with chunking enabled (the default) can't read 401 error response stream
[
https://issues.apache.org/jira/browse/CXF-5267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13764784#comment-13764784
]
Jesse Pangburn commented on CXF-5267:
-
Do you mean write a similar test using Apache HttpClient? That's what I
thought at first, but then the WebClient line is clearly CXF. I don't build
with Maven so not sure what to do about the dependency part you mentioned. So
I just added the line you provided right before my invoke method call, but it
didn't change anything.
Converting to HttpClient is easy enough to try. It didn't care whether chunked
or not, in both cases the 401 response stream was available and printed out
from the following code as one would hope:
{code}
public static void main(String[] args) throws Exception {
DefaultHttpClient httpclient = new DefaultHttpClient();
HttpPost httpPost = new HttpPost("http://localhost:9005/raw/customers";);
List nvps = new ArrayList ();
nvps.add(new BasicNameValuePair("username", "vip"));
nvps.add(new BasicNameValuePair("password", "secret"));
UrlEncodedFormEntity requestEntity = new UrlEncodedFormEntity(nvps);
requestEntity.setChunked(true);
httpPost.setEntity(requestEntity);
HttpResponse response2 = httpclient.execute(httpPost);
BufferedReader in = null;
try {
System.out.println(response2.getStatusLine());
HttpEntity entity2 = response2.getEntity();
in = new BufferedReader(new InputStreamReader(
entity2.getContent()));
String response;
while ((response = in.readLine()) != null) {
System.out.println(response);
}
// ensure it is fully consumed
EntityUtils.consume(entity2);
} finally {
httpPost.releaseConnection();
}
}
{code}
Has there been some other movement within CXF to convert to using Apache's
HttpClient?
> WebClient using POST with chunking enabled (the default) can't read 401 error
> response stream
> -
>
> Key: CXF-5267
> URL: https://issues.apache.org/jira/browse/CXF-5267
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.5.3, 2.7.5
> Environment: Linux
>Reporter: Jesse Pangburn
>Priority: Minor
>
> If I use WebClient to POST a message to a server, then I can't read the 401
> error response stream. If I use GET, then I can read the response stream
> just fine. If I use a HTTPConduit and disable chunking then I can read the
> response content just fine in all cases.
> Here's a short grid showing the tests I performed:
> ||GET/POST||chunking||return code||result||
> |GET|disabled|401|response message ok|
> |POST|disabled|401|response message ok|
> |POST|enabled (default)|401|response message BLANK!|
> |GET|enabled (default)|401|response message ok|
> |POST|enabled (default)|200|response message ok|
> Here's the code I'm using (requestStream and webClient are initialized above.
> webClient is a WebClient and requestStream is an InputStream.):
> {code:title=TestWSClient.java|borderStyle=solid}
> String requestMethod = "POST";
> InputStream responseStream = null;
> Response response = null;
> try{
> responseStream = webClient.invoke(requestMethod, requestStream,
> InputStream.class);
> } catch (Exception e){
> logger.log(Level.WARNING, "caught exception using webClient to call " +
> webClient.getCurrentURI().toString(), e);
> }finally{
> // always assign the Response object
> response = webClient.getResponse();
> // if the response entity is a LoadingByteArrayOutputStream, then we
> can still grab that response content
> try{
> Object entity = response.getEntity();
> if (entity instanceof ByteArrayInputStream){
> ByteArrayInputStream bais =
> (ByteArrayInputStream)entity;
> // the stream needs to be reset before we can really
> use it
> bais.reset();
> responseStream = bais;
> }
> }catch (Exception e){
> // darn, failed to get that response entity
> logger.log(Level.WARNING, "tried to get response message despite
> webClient exception, but failed", e);
> // nothing else we can do, at least Cloverleaf will get the 500
> response code and error is in the log
> }
> }
> {code}
> In the failure case, when I try to read (not shown) from the response stream
> I get a "-1" indicating the stream is empty.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
F
[jira] [Commented] (CXF-5268) Automatic WS-Policy computation should be possible on Dispatch clients without setting operation manually
[
https://issues.apache.org/jira/browse/CXF-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13764476#comment-13764476
]
Jesse Pangburn commented on CXF-5268:
-
Awesome! From the first time I looked at this code for WS-Addressing use, I
wondered about this whole dispatchToOperation thing. Why not just set the
operation itself? I assumed there was a complicated reason and left it alone.
Great to see you felt like it could just be ripped out altogether! Good
riddance hacks.
> Automatic WS-Policy computation should be possible on Dispatch clients
> without setting operation manually
> -
>
> Key: CXF-5268
> URL: https://issues.apache.org/jira/browse/CXF-5268
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 2.7.6
> Environment: Linux
>Reporter: Jesse Pangburn
>Assignee: Daniel Kulp
> Labels: Dispatch, WS-Policy, patch
> Fix For: 2.7.7
>
> Attachments: DispatchImpl.java.patch
>
>
> If a WSDL contains a WS-Policy with separate policies on the Operation
> message elements, CXF should compute the correct policy for Dispatch clients
> by looking at the message content. It already does this to determine the
> operation so it can compute the correct WS-Addressing values, if the Dispatch
> developer does the following:
> {code}
> disp.getRequestContext().put("find.dispatch.operation", Boolean.TRUE);
> {code}
> So we're already doing that work. It's a one line fix to update the
> operation at that time, so that the WS-Policy computation engine can read the
> correct operation and use that to get the right set of policies from the WSDL
> to mix together. I will supply that patch :-) after submitting this issue
> for it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-5267) WebClient using POST with chunking enabled (the default) can't read 401 error response stream
[
https://issues.apache.org/jira/browse/CXF-5267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13764565#comment-13764565
]
Jesse Pangburn commented on CXF-5267:
-
Hi Sergey, well I can say I'm completely surprised by this result! That was a
good question. I thought maybe you were wondering if the server wasn't
returning the same thing in both cases, but I had run it while watching with
Wireshark and saw the exact same response. So NEVER would have guessed that
HttpURLConnection was treating it differently.
Here's the test code I wrote to check this:
{code}
public static void main(String[] args) throws Exception {
URL testServer = new URL("http://localhost:9005/raw/customers";);
HttpURLConnection connection = (HttpURLConnection) testServer
.openConnection();
// connection.setChunkedStreamingMode(0);
connection.setDoOutput(true);
OutputStreamWriter out = new OutputStreamWriter(
connection.getOutputStream());
out.write("hello!");
out.close();
BufferedReader in = null;
try {
in = new BufferedReader(new InputStreamReader(
connection.getInputStream()));
String response;
while ((response = in.readLine()) != null) {
System.out.println(response);
}
} catch (Exception e) {
BufferedReader errorIn = null;
try {
errorIn = new BufferedReader(new InputStreamReader(
connection.getErrorStream()));
String response;
while ((response = errorIn.readLine()) != null) {
System.out.println("ERROR: " + response);
}
} finally {
if (errorIn != null)
errorIn.close();
}
} finally {
if (in != null)
in.close();
}
}
{code}
As it stands, it's in non-chunking mode and it prints out the error stream just
fine. But uncomment the line to turn chunking on and that error stream becomes
null!
So it seems this is a problem inherent in the Java HttpURLConnection
implementation that the error response stream is lost in this case. The API
doc for that method has this:
{quote}
When output streaming is enabled, authentication and redirection cannot be
handled automatically. A HttpRetryException will be thrown when reading the
response if authentication or redirection are required. This exception can be
queried for the details of the error.
{quote}
Not sure why they didn't make the error stream available anyway in this case
(it's there on the network, I can see it with Wireshark), but clearly the
problem is upstream from CXF since you're saying that CXF uses this internally.
So I guess nothing we can do? It's kind of surprising to users that flipping
this request bit has anything to do with processing the response.
thanks,
Jesse
> WebClient using POST with chunking enabled (the default) can't read 401 error
> response stream
> -
>
> Key: CXF-5267
> URL: https://issues.apache.org/jira/browse/CXF-5267
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.5.3, 2.7.5
> Environment: Linux
>Reporter: Jesse Pangburn
>Priority: Minor
>
> If I use WebClient to POST a message to a server, then I can't read the 401
> error response stream. If I use GET, then I can read the response stream
> just fine. If I use a HTTPConduit and disable chunking then I can read the
> response content just fine in all cases.
> Here's a short grid showing the tests I performed:
> ||GET/POST||chunking||return code||result||
> |GET|disabled|401|response message ok|
> |POST|disabled|401|response message ok|
> |POST|enabled (default)|401|response message BLANK!|
> |GET|enabled (default)|401|response message ok|
> |POST|enabled (default)|200|response message ok|
> Here's the code I'm using (requestStream and webClient are initialized above.
> webClient is a WebClient and requestStream is an InputStream.):
> {code:title=TestWSClient.java|borderStyle=solid}
> String requestMethod = "POST";
> InputStream responseStream = null;
> Response response = null;
> try{
> responseStream = webClient.invoke(requestMethod, requestStream,
> InputStream.class);
> } catch (Exception e){
> logger.log(Level.WARNING, "caught exception using webClient to call " +
> webClient.getCurrentURI().toString(), e);
> }finally{
> // always assign the Response object
> response = webClient.getResponse();
> // if the response entity is a LoadingByteArrayOutputStream, then we
> can still grab that response content
>
[jira] [Updated] (CXF-5268) Automatic WS-Policy computation should be possible on Dispatch clients without setting operation manually
[
https://issues.apache.org/jira/browse/CXF-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Pangburn updated CXF-5268:
Attachment: DispatchImpl.java.patch
This patch goes on the 2.7.6 release version of DispatchImpl.java. The full
path is
apache-cxf-2.7.6-src/rt/frontend/jaxws/src/main/java/org/apache/cxf/DispatchImpl.java
> Automatic WS-Policy computation should be possible on Dispatch clients
> without setting operation manually
> -
>
> Key: CXF-5268
> URL: https://issues.apache.org/jira/browse/CXF-5268
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 2.7.6
> Environment: Linux
>Reporter: Jesse Pangburn
> Labels: Dispatch, WS-Policy, patch
> Attachments: DispatchImpl.java.patch
>
>
> If a WSDL contains a WS-Policy with separate policies on the Operation
> message elements, CXF should compute the correct policy for Dispatch clients
> by looking at the message content. It already does this to determine the
> operation so it can compute the correct WS-Addressing values, if the Dispatch
> developer does the following:
> {code}
> disp.getRequestContext().put("find.dispatch.operation", Boolean.TRUE);
> {code}
> So we're already doing that work. It's a one line fix to update the
> operation at that time, so that the WS-Policy computation engine can read the
> correct operation and use that to get the right set of policies from the WSDL
> to mix together. I will supply that patch :-) after submitting this issue
> for it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-5268) Automatic WS-Policy computation should be possible on Dispatch clients without setting operation manually
Jesse Pangburn created CXF-5268:
---
Summary: Automatic WS-Policy computation should be possible on
Dispatch clients without setting operation manually
Key: CXF-5268
URL: https://issues.apache.org/jira/browse/CXF-5268
Project: CXF
Issue Type: Bug
Components: WS-* Components
Affects Versions: 2.7.6
Environment: Linux
Reporter: Jesse Pangburn
If a WSDL contains a WS-Policy with separate policies on the Operation message
elements, CXF should compute the correct policy for Dispatch clients by looking
at the message content. It already does this to determine the operation so it
can compute the correct WS-Addressing values, if the Dispatch developer does
the following:
{code}
disp.getRequestContext().put("find.dispatch.operation", Boolean.TRUE);
{code}
So we're already doing that work. It's a one line fix to update the operation
at that time, so that the WS-Policy computation engine can read the correct
operation and use that to get the right set of policies from the WSDL to mix
together. I will supply that patch :-) after submitting this issue for it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-5267) WebClient using POST with chunking enabled (the default) can't read 401 error response stream
Jesse Pangburn created CXF-5267:
---
Summary: WebClient using POST with chunking enabled (the default)
can't read 401 error response stream
Key: CXF-5267
URL: https://issues.apache.org/jira/browse/CXF-5267
Project: CXF
Issue Type: Bug
Components: Core
Affects Versions: 2.7.5, 2.5.3
Environment: Linux
Reporter: Jesse Pangburn
Priority: Minor
If I use WebClient to POST a message to a server, then I can't read the 401
error response stream. If I use GET, then I can read the response stream just
fine. If I use a HTTPConduit and disable chunking then I can read the response
content just fine in all cases.
Here's a short grid showing the tests I performed:
||GET/POST||chunking||return code||result||
|GET|disabled|401|response message ok|
|POST|disabled|401|response message ok|
|POST|enabled (default)|401|response message BLANK!|
|GET|enabled (default)|401|response message ok|
|POST|enabled (default)|200|response message ok|
Here's the code I'm using (requestStream and webClient are initialized above.
webClient is a WebClient and requestStream is an InputStream.):
{code:title=TestWSClient.java|borderStyle=solid}
String requestMethod = "POST";
InputStream responseStream = null;
Response response = null;
try{
responseStream = webClient.invoke(requestMethod, requestStream,
InputStream.class);
} catch (Exception e){
logger.log(Level.WARNING, "caught exception using webClient to call " +
webClient.getCurrentURI().toString(), e);
}finally{
// always assign the Response object
response = webClient.getResponse();
// if the response entity is a LoadingByteArrayOutputStream, then we
can still grab that response content
try{
Object entity = response.getEntity();
if (entity instanceof ByteArrayInputStream){
ByteArrayInputStream bais =
(ByteArrayInputStream)entity;
// the stream needs to be reset before we can really
use it
bais.reset();
responseStream = bais;
}
}catch (Exception e){
// darn, failed to get that response entity
logger.log(Level.WARNING, "tried to get response message despite
webClient exception, but failed", e);
// nothing else we can do, at least Cloverleaf will get the 500
response code and error is in the log
}
}
{code}
In the failure case, when I try to read (not shown) from the response stream I
get a "-1" indicating the stream is empty.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4339) Dispatch client fails to set soap action header automatically unless WS-Addressing is enabled
[
https://issues.apache.org/jira/browse/CXF-4339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13281997#comment-13281997
]
Jesse Pangburn commented on CXF-4339:
-
Hi Aki,
I'm sorry, I thought the action taken when "find.dispatch.operation" is set to
TRUE was the default. I thought it was automatically supposed to resolve this
through the WSDL like it does when WS-Addressing is enabled.
Clearly this was my own misunderstanding and not a bug. Again, my apology for
filing a bug as I thought this was unintended behavior.
I've verified that after setting that property like this:
disp.getRequestContext().put("find.dispatch.operation", Boolean.TRUE);
Now for SOAP 1.1 and SOAP 1.2 the soap action is set properly with/without
WS-Addressing enabled.
I'll close this issue.
thanks,
Jesse
> Dispatch client fails to set soap action header automatically unless
> WS-Addressing is enabled
> -
>
> Key: CXF-4339
> URL: https://issues.apache.org/jira/browse/CXF-4339
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 2.5.3
>Reporter: Jesse Pangburn
>Priority: Minor
> Labels: client, dispatch, soap
> Fix For: Invalid
>
>
> If I have a Dispatch client and I have WS-Addressing enabled on it and I send
> a request then I see the following:
> {quote}
> Content-Type: application/soap+xml;
> *action="urn:ihe:iti:2007:RegistryStoredQuery"*
> Headers: \{Accept=[*/*]}
> Payload: xmlns:soap="http://www.w3.org/2003/05/soap-envelope";> xmlns="http://www.w3.org/2005/08/addressing";>urn:ihe:iti:2007:RegistryStoredQuery
> {quote}
> But when I just disable WS-Addressing then the content-type header changes to
> the following:
> {quote}
> Content-Type: application/soap+xml; charset=UTF-8
> {quote}
> There's no action attribute any more. Manually setting the soap action uri
> on the dispatch object puts it back:
> {code}
> disp.getRequestContext().put(Dispatch.SOAPACTION_URI_PROPERTY, soapAction);
> {code}
> So there's a workaround possible (where your dispatch use case can
> accommodate it) but the problem is that CXF shouldn't require WS-Addressing
> enabled to set the Content-Type header's action attribute automatically.
> This is a bigger problem in SOAP 1.1 where many services rely on the
> SOAPAction header and CXF is sending a blank SOAPAction header by default
> unless WS-Addressing is enabled.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CXF-4339) Dispatch client fails to set soap action header automatically unless WS-Addressing is enabled
[
https://issues.apache.org/jira/browse/CXF-4339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Pangburn closed CXF-4339.
---
Resolution: Not A Problem
Fix Version/s: Invalid
This was not a bug, it was my own misunderstanding.
> Dispatch client fails to set soap action header automatically unless
> WS-Addressing is enabled
> -
>
> Key: CXF-4339
> URL: https://issues.apache.org/jira/browse/CXF-4339
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 2.5.3
>Reporter: Jesse Pangburn
>Priority: Minor
> Labels: client, dispatch, soap
> Fix For: Invalid
>
>
> If I have a Dispatch client and I have WS-Addressing enabled on it and I send
> a request then I see the following:
> {quote}
> Content-Type: application/soap+xml;
> *action="urn:ihe:iti:2007:RegistryStoredQuery"*
> Headers: \{Accept=[*/*]}
> Payload: xmlns:soap="http://www.w3.org/2003/05/soap-envelope";> xmlns="http://www.w3.org/2005/08/addressing";>urn:ihe:iti:2007:RegistryStoredQuery
> {quote}
> But when I just disable WS-Addressing then the content-type header changes to
> the following:
> {quote}
> Content-Type: application/soap+xml; charset=UTF-8
> {quote}
> There's no action attribute any more. Manually setting the soap action uri
> on the dispatch object puts it back:
> {code}
> disp.getRequestContext().put(Dispatch.SOAPACTION_URI_PROPERTY, soapAction);
> {code}
> So there's a workaround possible (where your dispatch use case can
> accommodate it) but the problem is that CXF shouldn't require WS-Addressing
> enabled to set the Content-Type header's action attribute automatically.
> This is a bigger problem in SOAP 1.1 where many services rely on the
> SOAPAction header and CXF is sending a blank SOAPAction header by default
> unless WS-Addressing is enabled.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4339) Dispatch client fails to set soap action header automatically unless WS-Addressing is enabled
[
https://issues.apache.org/jira/browse/CXF-4339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Pangburn updated CXF-4339:
Description:
If I have a Dispatch client and I have WS-Addressing enabled on it and I send a
request then I see the following:
{quote}
Content-Type: application/soap+xml;
*action="urn:ihe:iti:2007:RegistryStoredQuery"*
Headers: \{Accept=[*/*]}
Payload: http://www.w3.org/2003/05/soap-envelope";>http://www.w3.org/2005/08/addressing";>urn:ihe:iti:2007:RegistryStoredQuery
{quote}
But when I just disable WS-Addressing then the content-type header changes to
the following:
{quote}
Content-Type: application/soap+xml; charset=UTF-8
{quote}
There's no action attribute any more. Manually setting the soap action uri on
the dispatch object puts it back:
{code}
disp.getRequestContext().put(Dispatch.SOAPACTION_URI_PROPERTY, soapAction);
{code}
So there's a workaround possible (where your dispatch use case can accommodate
it) but the problem is that CXF shouldn't require WS-Addressing enabled to set
the Content-Type header's action attribute automatically.
This is a bigger problem in SOAP 1.1 where many services rely on the SOAPAction
header and CXF is sending a blank SOAPAction header by default unless
WS-Addressing is enabled.
was:
If I have a Dispatch client and I have WS-Addressing enabled on it and I send a
request then I see the following:
{quote}
Content-Type: application/soap+xml;
*action="urn:ihe:iti:2007:RegistryStoredQuery"*
Headers: \{Accept=[*/*]}
Payload: http://www.w3.org/2003/05/soap-envelope";>http://www.w3.org/2005/08/addressing";>urn:ihe:iti:2007:RegistryStoredQuery
{quote}
But when I just disable WS-Addressing then the content-type header changes to
the following:
{quote}
Content-Type: application/soap+xml; charset=UTF-8
{quote}
There's no action attribute any more. Manually setting the soap action uri on
the dispatch object puts it back:
{code}
disp.getRequestContext().put(Dispatch.SOAPACTION_URI_PROPERTY, soapAction);
{code}
So there's a workaround possible (where your dispatch use case can accommodate
it) but the problem is that CXF shouldn't require WS-Addressing enabled to set
the Content-Type header's action attribute automatically.
> Dispatch client fails to set soap action header automatically unless
> WS-Addressing is enabled
> -
>
> Key: CXF-4339
> URL: https://issues.apache.org/jira/browse/CXF-4339
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 2.5.3
>Reporter: Jesse Pangburn
>Priority: Minor
> Labels: client, dispatch, soap
>
> If I have a Dispatch client and I have WS-Addressing enabled on it and I send
> a request then I see the following:
> {quote}
> Content-Type: application/soap+xml;
> *action="urn:ihe:iti:2007:RegistryStoredQuery"*
> Headers: \{Accept=[*/*]}
> Payload: xmlns:soap="http://www.w3.org/2003/05/soap-envelope";> xmlns="http://www.w3.org/2005/08/addressing";>urn:ihe:iti:2007:RegistryStoredQuery
> {quote}
> But when I just disable WS-Addressing then the content-type header changes to
> the following:
> {quote}
> Content-Type: application/soap+xml; charset=UTF-8
> {quote}
> There's no action attribute any more. Manually setting the soap action uri
> on the dispatch object puts it back:
> {code}
> disp.getRequestContext().put(Dispatch.SOAPACTION_URI_PROPERTY, soapAction);
> {code}
> So there's a workaround possible (where your dispatch use case can
> accommodate it) but the problem is that CXF shouldn't require WS-Addressing
> enabled to set the Content-Type header's action attribute automatically.
> This is a bigger problem in SOAP 1.1 where many services rely on the
> SOAPAction header and CXF is sending a blank SOAPAction header by default
> unless WS-Addressing is enabled.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4339) Dispatch client fails to set soap action header automatically unless WS-Addressing is enabled
Jesse Pangburn created CXF-4339:
---
Summary: Dispatch client fails to set soap action header
automatically unless WS-Addressing is enabled
Key: CXF-4339
URL: https://issues.apache.org/jira/browse/CXF-4339
Project: CXF
Issue Type: Bug
Components: JAX-WS Runtime
Affects Versions: 2.5.3
Reporter: Jesse Pangburn
Priority: Minor
If I have a Dispatch client and I have WS-Addressing enabled on it and I send a
request then I see the following:
{quote}
Content-Type: application/soap+xml;
*action="urn:ihe:iti:2007:RegistryStoredQuery"*
Headers: \{Accept=[*/*]}
Payload: http://www.w3.org/2003/05/soap-envelope";>http://www.w3.org/2005/08/addressing";>urn:ihe:iti:2007:RegistryStoredQuery
{quote}
But when I just disable WS-Addressing then the content-type header changes to
the following:
{quote}
Content-Type: application/soap+xml; charset=UTF-8
{quote}
There's no action attribute any more. Manually setting the soap action uri on
the dispatch object puts it back:
{code}
disp.getRequestContext().put(Dispatch.SOAPACTION_URI_PROPERTY, soapAction);
{code}
So there's a workaround possible (where your dispatch use case can accommodate
it) but the problem is that CXF shouldn't require WS-Addressing enabled to set
the Content-Type header's action attribute automatically.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4262) oauth sample in 2.5.3 release does not build without POM changes
[ https://issues.apache.org/jira/browse/CXF-4262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261193#comment-13261193 ] Jesse Pangburn commented on CXF-4262: - That is a better example in many ways, the only thing I don't like is that both client and server endpoints reside on the same port. The sample that comes with CXF has them on different ports so it's easy to see what stuff belongs to the client service and what belongs to the server service. That said, are the examples in the CXF source code not maintained anymore? Seems like they should at least compile and run, even if they're not the most advanced samples around. thanks, Jesse > oauth sample in 2.5.3 release does not build without POM changes > > > Key: CXF-4262 > URL: https://issues.apache.org/jira/browse/CXF-4262 > Project: CXF > Issue Type: Bug > Components: Samples >Affects Versions: 2.5.3 >Reporter: Jesse Pangburn >Assignee: Sergey Beryozkin >Priority: Minor > Labels: oauth, samples > Fix For: 2.5.4 > > > Tried building oauth client and server samples in 2.5.3 release using > provided instruction: > mvn jetty:run > Also tried: > mvn clean install > These attempts in both client and server fail with the following relevant > exception from the stack trace: > * > Caused by: org.apache.maven.project.ProjectBuildingException: POM > 'org.apache.cxf.samples:cxf-samples' not found in repository: Unable to > download the artifact from any repository > org.apache.cxf.samples:cxf-samples:pom:2.5.3-SNAPSHOT > * > Looking in the pom.xml file for this 2.5.3-SNAPSHOT problem, I find this > entry: > 2.5.3-SNAPSHOT > Changing it to the following resolves the problem and lets the samples build: > 2.5.3 > The client now starts with "mvn jetty:run", but the server still fails with > an apparently unrelated error. Still, at least it builds with this change. > The server error is: > java.lang.NoSuchMethodError: org.objectweb.asm.ClassWriter.(Z)V > This is apparently due to the use of cglib in the pom.xml. It can be > resolved and let the server start by changing this entry in the pom.xml: > > cglib > cglib > 2.1 > > to this: > > cglib > cglib-nodep > 2.1 > > After this it is possible to start "mvn jetty:run" with no errors, though I > don't know enough about the sample to verify its functionality yet. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4262) oauth sample in 2.5.3 release does not build without POM changes
[ https://issues.apache.org/jira/browse/CXF-4262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Pangburn updated CXF-4262: Description: Tried building oauth client and server samples in 2.5.3 release using provided instruction: mvn jetty:run Also tried: mvn clean install These attempts in both client and server fail with the following relevant exception from the stack trace: * Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.cxf.samples:cxf-samples' not found in repository: Unable to download the artifact from any repository org.apache.cxf.samples:cxf-samples:pom:2.5.3-SNAPSHOT * Looking in the pom.xml file for this 2.5.3-SNAPSHOT problem, I find this entry: 2.5.3-SNAPSHOT Changing it to the following resolves the problem and lets the samples build: 2.5.3 The client now starts with "mvn jetty:run", but the server still fails with an apparently unrelated error. Still, at least it builds with this change. The server error is: java.lang.NoSuchMethodError: org.objectweb.asm.ClassWriter.(Z)V This is apparently due to the use of cglib in the pom.xml. It can be resolved and let the server start by changing this entry in the pom.xml: cglib cglib 2.1 to this: cglib cglib-nodep 2.1 After this it is possible to start "mvn jetty:run" with no errors, though I don't know enough about the sample to verify its functionality yet. was: Tried building oauth client and server samples in 2.5.3 release using provided instruction: mvn jetty:run Also tried: mvn clean install These attempts in both client and server fail with the following relevant exception from the stack trace: * Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.cxf.samples:cxf-samples' not found in repository: Unable to download the artifact from any repository org.apache.cxf.samples:cxf-samples:pom:2.5.3-SNAPSHOT * Looking in the pom.xml file for this 2.5.3-SNAPSHOT problem, I find this entry: 2.5.3-SNAPSHOT Changing it to the following resolves the problem and lets the samples build: 2.5.3 The client now starts with "mvn jetty:run", but the server still fails with an apparently unrelated error. Still, at least it builds with this change. > oauth sample in 2.5.3 release does not build without POM changes > > > Key: CXF-4262 > URL: https://issues.apache.org/jira/browse/CXF-4262 > Project: CXF > Issue Type: Bug > Components: Samples >Affects Versions: 2.5.3 >Reporter: Jesse Pangburn >Priority: Minor > Labels: oauth, samples > > Tried building oauth client and server samples in 2.5.3 release using > provided instruction: > mvn jetty:run > Also tried: > mvn clean install > These attempts in both client and server fail with the following relevant > exception from the stack trace: > * > Caused by: org.apache.maven.project.ProjectBuildingException: POM > 'org.apache.cxf.samples:cxf-samples' not found in repository: Unable to > download the artifact from any repository > org.apache.cxf.samples:cxf-samples:pom:2.5.3-SNAPSHOT > * > Looking in the pom.xml file for this 2.5.3-SNAPSHOT problem, I find this > entry: > 2.5.3-SNAPSHOT > Changing it to the following resolves the problem and lets the samples build: > 2.5.3 > The client now starts with "mvn jetty:run", but the server still fails with > an apparently unrelated error. Still, at least it builds with this change. > The server error is: > java.lang.NoSuchMethodError: org.objectweb.asm.ClassWriter.(Z)V > This is apparently due to the use of cglib in the pom.xml. It can be > resolved and let the server start by changing this entry in the pom.xml: > > cglib > cglib > 2.1 > > to this: > > cglib > cglib-nodep > 2.1 > > After this it is possible to start "mvn jetty:run" with no errors, though I > don't know enough about the sample to verify its functionality yet. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4262) oauth sample in 2.5.3 release does not build without POM changes
Jesse Pangburn created CXF-4262: --- Summary: oauth sample in 2.5.3 release does not build without POM changes Key: CXF-4262 URL: https://issues.apache.org/jira/browse/CXF-4262 Project: CXF Issue Type: Bug Components: Samples Affects Versions: 2.5.3 Reporter: Jesse Pangburn Priority: Minor Tried building oauth client and server samples in 2.5.3 release using provided instruction: mvn jetty:run Also tried: mvn clean install These attempts in both client and server fail with the following relevant exception from the stack trace: * Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.cxf.samples:cxf-samples' not found in repository: Unable to download the artifact from any repository org.apache.cxf.samples:cxf-samples:pom:2.5.3-SNAPSHOT * Looking in the pom.xml file for this 2.5.3-SNAPSHOT problem, I find this entry: 2.5.3-SNAPSHOT Changing it to the following resolves the problem and lets the samples build: 2.5.3 The client now starts with "mvn jetty:run", but the server still fails with an apparently unrelated error. Still, at least it builds with this change. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3802) jaxws Provider doesn't allow override of outbound ws addressing headers
jaxws Provider doesn't allow override of outbound ws addressing headers
---
Key: CXF-3802
URL: https://issues.apache.org/jira/browse/CXF-3802
Project: CXF
Issue Type: Bug
Components: JAX-WS Runtime
Affects Versions: 2.4.2
Reporter: Jesse Pangburn
Priority: Minor
I have a jaxws Provider configured to do WS-Addressing and the defaults seem to
work fine. However, if I try to override some of the WS-Addressing headers in
the MessageContext, it gets ignored. I've tried the following :
AddressingProperties wsaServer = new AddressingPropertiesImpl();
AttributedURIType aut = new AttributedURIType(); aut.setValue("urn:get:some");
wsaServer.setAction(aut);
messageContext.put(JAXWSAConstants.SERVER_ADDRESSING_PROPERTIES_OUTBOUND,
wsaServer);
But the Action header sent in the response is the default from the WSDL, not my
override value. Am I doing something wrong or this never worked? I've tried
doing:
messageContext.get(JAXWSAConstants.SERVER_ADDRESSING_PROPERTIES_OUTBOUND)
But that returns null, so I've been using the put instead. I tried overriding
the messageId as well, but that didn't work either.
Debugging through the code illustrates that you can't just set this property on
the MessageContext object for the Provider, you must set it on the outbound
message object, like this:
((org.apache.cxf.jaxws.context.WrappedMessageContext)messageContext).getWrappedMessage().getExchange().getOutMessage().put(JAXWSAConstants.SERVER_ADDRESSING_PROPERTIES_OUTBOUND,
wsaServer);
So the working code for me becomes something like:
AddressingProperties wsaServer = new AddressingPropertiesImpl();
AttributedURIType aut = new AttributedURIType(); aut.setValue("urn:get:some");
wsaServer.setAction(aut);
((org.apache.cxf.jaxws.context.WrappedMessageContext)messageContext).getWrappedMessage().getExchange().getOutMessage().put(JAXWSAConstants.SERVER_ADDRESSING_PROPERTIES_OUTBOUND,
wsaServer);
I've tried overriding the message id and the action headers, both were
successful.
Dan suggested the following fix in ContextUtils. Change these lines:
AddressingPropertiesImpl maps =
(AddressingPropertiesImpl)message.get(mapProperty);
if (maps != null) {
LOG.log(Level.FINE, "current MAPs {0}", maps);
}
to:
AddressingPropertiesImpl maps =
(AddressingPropertiesImpl)message.get(mapProperty);
if (maps == null && isOutbound && !isRequestor) {
maps =
(AddressingPropertiesImpl)message.getExchange().getInMessage().get(mapProperty);
}
if (maps != null) {
LOG.log(Level.FINE, "current MAPs {0}", maps);
}
I've tested this and it is successful with just the expected
messageContext.put() call. Thanks Dan!
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CXF-3754) Dispatch API's ServiceImpl class fails to copy address/properties/bus/handlers from jaxws:client spring configuration
[ https://issues.apache.org/jira/browse/CXF-3754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Pangburn closed CXF-3754. --- Verified by downloading latest version of affected file(s) from SVN on the 2.4.x fixes branch, building CXF 2.4.2 with the fixed file(s) and testing this defect > Dispatch API's ServiceImpl class fails to copy > address/properties/bus/handlers from jaxws:client spring configuration > - > > Key: CXF-3754 > URL: https://issues.apache.org/jira/browse/CXF-3754 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Affects Versions: 2.4.1 >Reporter: Jesse Pangburn >Assignee: Daniel Kulp >Priority: Minor > Labels: dispatch, jaxws > Fix For: 2.3.7, 2.4.3 > > Attachments: patch3754.txt, patch3754_partial.txt > > Original Estimate: 3h > Remaining Estimate: 3h > > When using the Dispatch API to create a dispatch object, the ServiceImpl > class helps create the Dispatch object and copies in a number of objects from > the jaxws:client spring configuration (if present and properly configured). > However, it fails to copy the following: > address, properties, bus, handlers > These overrides can be required in some deployments to make things work > right. The workaround is to use the default bus and set those things there > but this limits the amount of services that can be configured in one instance > when those services need to have different bus settings. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CXF-3755) setting wsa:addressing feature in cxf:bus causes wrong action header to be sent when using Dispatch API
[
https://issues.apache.org/jira/browse/CXF-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Pangburn closed CXF-3755.
---
Verified by downloading latest version of affected file(s) from SVN on the
2.4.x fixes branch, building CXF 2.4.2 with the fixed file(s) and testing this
defect
> setting wsa:addressing feature in cxf:bus causes wrong action header to be
> sent when using Dispatch API
> ---
>
> Key: CXF-3755
> URL: https://issues.apache.org/jira/browse/CXF-3755
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 2.4.1
>Reporter: Jesse Pangburn
>Assignee: Daniel Kulp
>Priority: Minor
> Labels: dispatch, jaxws, ws-addressing
> Fix For: 2.3.7, 2.4.3
>
> Attachments: patch3754_partial_and3755.txt, patch3754and3755.txt
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> I configured ws addressing on the cxf bus like this, instead of adding the
> feature directly to the dispatch client:
>
>
>
>
>
> However using both SOAP 1.1 and 1.2 Dispatch API clients, I found that it
> sets the wrong Action header by just using a default rather than the one from
> the WSDL. I'm not certain which code is responsible for this but I see in
> the DispatchImpl.java the following code:
> boolean wsaEnabled = false;
> for (AbstractFeature feature :
> ((JaxWsClientEndpointImpl)client.getEndpoint()).getFeatures()) {
> if (feature instanceof WSAddressingFeature) {
> wsaEnabled = true;
> }
> }
> This only looks for the features on the endpoint to determine if it should do
> ws addressing, not the features on the bus too. So the DispatchImpl doesn't
> set this stuff up. Further investigation shows that if the wsAddressing
> feature is added via jaxws:client spring configuration, the action header is
> wrong here too.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CXF-3749) Using Dispatch API with Source type fails to set WS-Addressing action header properly in MESSAGE mode with SOAP 1.2
[
https://issues.apache.org/jira/browse/CXF-3749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Pangburn closed CXF-3749.
---
Verified by downloading latest version of affected file(s) from SVN on the
2.4.x fixes branch and checked code contains the fix
> Using Dispatch API with Source type fails to set WS-Addressing action header
> properly in MESSAGE mode with SOAP 1.2
> ---
>
> Key: CXF-3749
> URL: https://issues.apache.org/jira/browse/CXF-3749
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 2.4.1
>Reporter: Jesse Pangburn
>Assignee: Daniel Kulp
>Priority: Minor
> Labels: dispatch, jaxws, soap12
> Fix For: 2.3.7, 2.4.3
>
> Attachments: patch3747and3748and3749.txt
>
>
> Prior tests with PAYLOAD mode were successful with SOAP 1.2, but a quick test
> on MESSAGE mode with a StaxSource revealed that the WS-Addressing action
> header is not properly set in SOAP 1.2. In one of the DispatchImpl.java's
> getPayloadElementName methods, there is the following code with a SOAP 1.1
> namespace hardcoded:
> if (this.mode == Service.Mode.MESSAGE) {
> StaxUtils.skipToStartOfElement(reader);
> StaxUtils.toNextTag(reader,
> new
> QName("http://schemas.xmlsoap.org/soap/envelope/";, "Body"));
> reader.nextTag();
> return reader.getName().toString();
> }
> To work with SOAP 1.1 or SOAP 1.2, it should be changed to:
> if (this.mode == Service.Mode.MESSAGE) {
> StaxUtils.skipToStartOfElement(reader);
> StaxUtils.toNextTag(reader,
> new QName(ele.getNamespaceURI(), "Body"));
> reader.nextTag();
> return reader.getName().toString();
> }
> I've tested this fix with a Source type in MESSAGE mode and it works with
> SOAP 1.1 and 1.2.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CXF-3747) Dispatch client fails to set WS-Addressing Action header when WSDL's soap:operation does not have a style attribute
[
https://issues.apache.org/jira/browse/CXF-3747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Pangburn closed CXF-3747.
---
Verified by downloading latest version of affected file(s) from SVN on the
2.4.x fixes branch, building CXF 2.4.2 with the fixed file(s) and testing this
defect
> Dispatch client fails to set WS-Addressing Action header when WSDL's
> soap:operation does not have a style attribute
> ---
>
> Key: CXF-3747
> URL: https://issues.apache.org/jira/browse/CXF-3747
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 2.4.1
>Reporter: Jesse Pangburn
>Assignee: Daniel Kulp
>Priority: Minor
> Labels: dispatch, ws-addressing
> Fix For: 2.3.7, 2.4.3
>
> Attachments: patch3747.txt, patch3747and3748.txt
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> I found the cause of the problem to be a bug in this method in CXF (I have
> version 2.4.1):
> private Map createPayloadEleOpNameMap(BindingInfo
> bindingInfo) {
> Map payloadElementMap = new java.util.HashMap QName>();
> for (BindingOperationInfo bop : bindingInfo.getOperations()) {
> SoapOperationInfo soi =
> (SoapOperationInfo)bop.getExtensor(SoapOperationInfo.class);
> if (soi != null) {
> if ("document".equals(soi.getStyle())) {
> // if doc
> if (bop.getOperationInfo().getInput() != null
> &&
> !bop.getOperationInfo().getInput().getMessageParts().isEmpty()) {
> QName qn =
> bop.getOperationInfo().getInput().getMessagePartByIndex(0)
> .getElementQName();
> payloadElementMap.put(qn.toString(),
> bop.getOperationInfo().getName());
> }
> } else if ("rpc".equals(soi.getStyle())) {
> // if rpc
>
> payloadElementMap.put(bop.getOperationInfo().getName().toString(),
> bop.getOperationInfo()
> .getName());
> }
> }
> }
> return payloadElementMap;
> }
> The problem is that it requires the SoapOperationInfo to have a style
> attribute, but in the W3C spec for WSDL it says the style attribute on the
> soap operation is optional, specifically 'If the attribute is not specified,
> it defaults to the value specified in the soap:binding element. If the
> soap:binding element does not specify a style, it is assumed to be
> "document".' So the code needs to check if the soi has a style and if not
> read it from the binding and if not then set it as "document". This is not a
> problem in the WSDLs generated by CXF (as I found out with a HelloWorld test)
> because it creates these optional style attributes, but since W3C says people
> can generate WSDLs without these (and I ran into one) I think it's worth
> fixing.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CXF-3748) Using Dispatch API with SOAPMessage type fails to set WS-Addressing action header properly if there's whitespace after the soap:body
[
https://issues.apache.org/jira/browse/CXF-3748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Pangburn closed CXF-3748.
---
Verified by downloading latest version of affected file(s) from SVN on the
2.4.x fixes branch and checking the code contains the fix
> Using Dispatch API with SOAPMessage type fails to set WS-Addressing action
> header properly if there's whitespace after the soap:body
>
>
> Key: CXF-3748
> URL: https://issues.apache.org/jira/browse/CXF-3748
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 2.4.1
>Reporter: Jesse Pangburn
>Assignee: Daniel Kulp
>Priority: Minor
> Labels: dispatch, soapmessage, ws-addressing
> Fix For: 2.3.7, 2.4.3
>
> Attachments: patch3747and3748.txt, patch3748.txt
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> if you use a SOAPMessage instead of a Source then the following function
> fails (ignoring the exception) and your ws-addressing action doesn't get set-
> if you have any whitespace after the soap:body element before your first
> payload element:
> private String getPayloadElementName(SOAPMessage soapMessage) {
> try {
> SOAPElement element =
> (SOAPElement)soapMessage.getSOAPBody().getChildElements().next();
> return new QName(element.getNamespaceURI(),
> element.getLocalName()).toString();
> } catch (Exception e) {
> //ignore
> }
> return null;
>
> }
> This fails because the .next() call at the end gets a text node instead of an
> element object so the cast fails. So inexplicably your ws-addressing action
> header doesn't get set as far as the user sees.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-3754) Dispatch API's ServiceImpl class fails to copy address/properties/bus/handlers from jaxws:client spring configuration
[ https://issues.apache.org/jira/browse/CXF-3754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Pangburn updated CXF-3754: Attachment: patch3754.txt This patch is the same as the first one except it adds the handler chain support so it completely resolves this issue. > Dispatch API's ServiceImpl class fails to copy > address/properties/bus/handlers from jaxws:client spring configuration > - > > Key: CXF-3754 > URL: https://issues.apache.org/jira/browse/CXF-3754 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Affects Versions: 2.4.1 >Reporter: Jesse Pangburn >Priority: Minor > Labels: dispatch, jaxws > Attachments: patch3754.txt, patch3754_partial.txt > > Original Estimate: 3h > Remaining Estimate: 3h > > When using the Dispatch API to create a dispatch object, the ServiceImpl > class helps create the Dispatch object and copies in a number of objects from > the jaxws:client spring configuration (if present and properly configured). > However, it fails to copy the following: > address, properties, bus, handlers > These overrides can be required in some deployments to make things work > right. The workaround is to use the default bus and set those things there > but this limits the amount of services that can be configured in one instance > when those services need to have different bus settings. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-3755) setting wsa:addressing feature in cxf:bus causes wrong action header to be sent when using Dispatch API
[
https://issues.apache.org/jira/browse/CXF-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Pangburn updated CXF-3755:
Attachment: patch3754and3755.txt
The attached patch file fixes this bug (3755) and also includes the full patch
for 3754 because 3754 required a change to the same file which I cannot commit
separately.
Previously attached patch file only had the partial fix for 3754.
> setting wsa:addressing feature in cxf:bus causes wrong action header to be
> sent when using Dispatch API
> ---
>
> Key: CXF-3755
> URL: https://issues.apache.org/jira/browse/CXF-3755
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 2.4.1
>Reporter: Jesse Pangburn
>Priority: Minor
> Labels: dispatch, jaxws, ws-addressing
> Attachments: patch3754_partial_and3755.txt, patch3754and3755.txt
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> I configured ws addressing on the cxf bus like this, instead of adding the
> feature directly to the dispatch client:
>
>
>
>
>
> However using both SOAP 1.1 and 1.2 Dispatch API clients, I found that it
> sets the wrong Action header by just using a default rather than the one from
> the WSDL. I'm not certain which code is responsible for this but I see in
> the DispatchImpl.java the following code:
> boolean wsaEnabled = false;
> for (AbstractFeature feature :
> ((JaxWsClientEndpointImpl)client.getEndpoint()).getFeatures()) {
> if (feature instanceof WSAddressingFeature) {
> wsaEnabled = true;
> }
> }
> This only looks for the features on the endpoint to determine if it should do
> ws addressing, not the features on the bus too. So the DispatchImpl doesn't
> set this stuff up. Further investigation shows that if the wsAddressing
> feature is added via jaxws:client spring configuration, the action header is
> wrong here too.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-3755) setting wsa:addressing feature in cxf:bus causes wrong action header to be sent when using Dispatch API
[
https://issues.apache.org/jira/browse/CXF-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Pangburn updated CXF-3755:
Attachment: patch3754_partial_and3755.txt
The attached patch file fixes this bug (3755) and also includes the patch for
3754 because 3754 required a change to the same file which I cannot commit
separately.
> setting wsa:addressing feature in cxf:bus causes wrong action header to be
> sent when using Dispatch API
> ---
>
> Key: CXF-3755
> URL: https://issues.apache.org/jira/browse/CXF-3755
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 2.4.1
>Reporter: Jesse Pangburn
>Priority: Minor
> Labels: dispatch, jaxws, ws-addressing
> Attachments: patch3754_partial_and3755.txt
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> I configured ws addressing on the cxf bus like this, instead of adding the
> feature directly to the dispatch client:
>
>
>
>
>
> However using both SOAP 1.1 and 1.2 Dispatch API clients, I found that it
> sets the wrong Action header by just using a default rather than the one from
> the WSDL. I'm not certain which code is responsible for this but I see in
> the DispatchImpl.java the following code:
> boolean wsaEnabled = false;
> for (AbstractFeature feature :
> ((JaxWsClientEndpointImpl)client.getEndpoint()).getFeatures()) {
> if (feature instanceof WSAddressingFeature) {
> wsaEnabled = true;
> }
> }
> This only looks for the features on the endpoint to determine if it should do
> ws addressing, not the features on the bus too. So the DispatchImpl doesn't
> set this stuff up. Further investigation shows that if the wsAddressing
> feature is added via jaxws:client spring configuration, the action header is
> wrong here too.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3755) setting wsa:addressing feature in cxf:bus causes wrong action header to be sent when using Dispatch API
setting wsa:addressing feature in cxf:bus causes wrong action header to be sent
when using Dispatch API
---
Key: CXF-3755
URL: https://issues.apache.org/jira/browse/CXF-3755
Project: CXF
Issue Type: Bug
Components: JAX-WS Runtime
Affects Versions: 2.4.1
Reporter: Jesse Pangburn
Priority: Minor
I configured ws addressing on the cxf bus like this, instead of adding the
feature directly to the dispatch client:
However using both SOAP 1.1 and 1.2 Dispatch API clients, I found that it sets
the wrong Action header by just using a default rather than the one from the
WSDL. I'm not certain which code is responsible for this but I see in the
DispatchImpl.java the following code:
boolean wsaEnabled = false;
for (AbstractFeature feature :
((JaxWsClientEndpointImpl)client.getEndpoint()).getFeatures()) {
if (feature instanceof WSAddressingFeature) {
wsaEnabled = true;
}
}
This only looks for the features on the endpoint to determine if it should do
ws addressing, not the features on the bus too. So the DispatchImpl doesn't
set this stuff up. Further investigation shows that if the wsAddressing
feature is added via jaxws:client spring configuration, the action header is
wrong here too.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-3754) Dispatch API's ServiceImpl class fails to copy address/properties/bus/handlers from jaxws:client spring configuration
[ https://issues.apache.org/jira/browse/CXF-3754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Pangburn updated CXF-3754: Attachment: patch3754_partial.txt This patch addresses all issues in this bug report except for the handlers. I looked around but couldn't see how to construct a handler chain from the config to call dispatch.getBinding().setHandlerChain(..) with. > Dispatch API's ServiceImpl class fails to copy > address/properties/bus/handlers from jaxws:client spring configuration > - > > Key: CXF-3754 > URL: https://issues.apache.org/jira/browse/CXF-3754 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Affects Versions: 2.4.1 >Reporter: Jesse Pangburn >Priority: Minor > Labels: dispatch, jaxws > Attachments: patch3754_partial.txt > > Original Estimate: 3h > Remaining Estimate: 3h > > When using the Dispatch API to create a dispatch object, the ServiceImpl > class helps create the Dispatch object and copies in a number of objects from > the jaxws:client spring configuration (if present and properly configured). > However, it fails to copy the following: > address, properties, bus, handlers > These overrides can be required in some deployments to make things work > right. The workaround is to use the default bus and set those things there > but this limits the amount of services that can be configured in one instance > when those services need to have different bus settings. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3754) Dispatch API's ServiceImpl class fails to copy address/properties/bus/handlers from jaxws:client spring configuration
Dispatch API's ServiceImpl class fails to copy address/properties/bus/handlers from jaxws:client spring configuration - Key: CXF-3754 URL: https://issues.apache.org/jira/browse/CXF-3754 Project: CXF Issue Type: Bug Components: JAX-WS Runtime Affects Versions: 2.4.1 Reporter: Jesse Pangburn Priority: Minor When using the Dispatch API to create a dispatch object, the ServiceImpl class helps create the Dispatch object and copies in a number of objects from the jaxws:client spring configuration (if present and properly configured). However, it fails to copy the following: address, properties, bus, handlers These overrides can be required in some deployments to make things work right. The workaround is to use the default bus and set those things there but this limits the amount of services that can be configured in one instance when those services need to have different bus settings. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3749) Using Dispatch API with Source type fails to set WS-Addressing action header properly in MESSAGE mode with SOAP 1.2
Using Dispatch API with Source type fails to set WS-Addressing action header
properly in MESSAGE mode with SOAP 1.2
---
Key: CXF-3749
URL: https://issues.apache.org/jira/browse/CXF-3749
Project: CXF
Issue Type: Bug
Components: JAX-WS Runtime
Affects Versions: 2.4.1
Reporter: Jesse Pangburn
Priority: Minor
Attachments: patch3747and3748and3749.txt
Prior tests with PAYLOAD mode were successful with SOAP 1.2, but a quick test
on MESSAGE mode with a StaxSource revealed that the WS-Addressing action header
is not properly set in SOAP 1.2. In one of the DispatchImpl.java's
getPayloadElementName methods, there is the following code with a SOAP 1.1
namespace hardcoded:
if (this.mode == Service.Mode.MESSAGE) {
StaxUtils.skipToStartOfElement(reader);
StaxUtils.toNextTag(reader,
new
QName("http://schemas.xmlsoap.org/soap/envelope/";, "Body"));
reader.nextTag();
return reader.getName().toString();
}
To work with SOAP 1.1 or SOAP 1.2, it should be changed to:
if (this.mode == Service.Mode.MESSAGE) {
StaxUtils.skipToStartOfElement(reader);
StaxUtils.toNextTag(reader,
new QName(ele.getNamespaceURI(), "Body"));
reader.nextTag();
return reader.getName().toString();
}
I've tested this fix with a Source type in MESSAGE mode and it works with SOAP
1.1 and 1.2.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-3749) Using Dispatch API with Source type fails to set WS-Addressing action header properly in MESSAGE mode with SOAP 1.2
[
https://issues.apache.org/jira/browse/CXF-3749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Pangburn updated CXF-3749:
Attachment: patch3747and3748and3749.txt
Since I've patched two other defects on this same file in the same revision,
this patch fixes those defects as well as this one.
> Using Dispatch API with Source type fails to set WS-Addressing action header
> properly in MESSAGE mode with SOAP 1.2
> ---
>
> Key: CXF-3749
> URL: https://issues.apache.org/jira/browse/CXF-3749
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 2.4.1
>Reporter: Jesse Pangburn
>Priority: Minor
> Labels: dispatch, jaxws, soap12
> Attachments: patch3747and3748and3749.txt
>
>
> Prior tests with PAYLOAD mode were successful with SOAP 1.2, but a quick test
> on MESSAGE mode with a StaxSource revealed that the WS-Addressing action
> header is not properly set in SOAP 1.2. In one of the DispatchImpl.java's
> getPayloadElementName methods, there is the following code with a SOAP 1.1
> namespace hardcoded:
> if (this.mode == Service.Mode.MESSAGE) {
> StaxUtils.skipToStartOfElement(reader);
> StaxUtils.toNextTag(reader,
> new
> QName("http://schemas.xmlsoap.org/soap/envelope/";, "Body"));
> reader.nextTag();
> return reader.getName().toString();
> }
> To work with SOAP 1.1 or SOAP 1.2, it should be changed to:
> if (this.mode == Service.Mode.MESSAGE) {
> StaxUtils.skipToStartOfElement(reader);
> StaxUtils.toNextTag(reader,
> new QName(ele.getNamespaceURI(), "Body"));
> reader.nextTag();
> return reader.getName().toString();
> }
> I've tested this fix with a Source type in MESSAGE mode and it works with
> SOAP 1.1 and 1.2.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-3747) Dispatch client fails to set WS-Addressing Action header when WSDL's soap:operation does not have a style attribute
[
https://issues.apache.org/jira/browse/CXF-3747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Pangburn updated CXF-3747:
Attachment: patch3747and3748.txt
patch3747.txt
Two patches are attached. patch3747.txt fixes just this bug.
patch3747and3748.txt fixes this bug and 3748 together since they're both in the
same file and I am editing on the same revision.
> Dispatch client fails to set WS-Addressing Action header when WSDL's
> soap:operation does not have a style attribute
> ---
>
> Key: CXF-3747
> URL: https://issues.apache.org/jira/browse/CXF-3747
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 2.4.1
>Reporter: Jesse Pangburn
>Priority: Minor
> Labels: dispatch, ws-addressing
> Attachments: patch3747.txt, patch3747and3748.txt
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> I found the cause of the problem to be a bug in this method in CXF (I have
> version 2.4.1):
> private Map createPayloadEleOpNameMap(BindingInfo
> bindingInfo) {
> Map payloadElementMap = new java.util.HashMap QName>();
> for (BindingOperationInfo bop : bindingInfo.getOperations()) {
> SoapOperationInfo soi =
> (SoapOperationInfo)bop.getExtensor(SoapOperationInfo.class);
> if (soi != null) {
> if ("document".equals(soi.getStyle())) {
> // if doc
> if (bop.getOperationInfo().getInput() != null
> &&
> !bop.getOperationInfo().getInput().getMessageParts().isEmpty()) {
> QName qn =
> bop.getOperationInfo().getInput().getMessagePartByIndex(0)
> .getElementQName();
> payloadElementMap.put(qn.toString(),
> bop.getOperationInfo().getName());
> }
> } else if ("rpc".equals(soi.getStyle())) {
> // if rpc
>
> payloadElementMap.put(bop.getOperationInfo().getName().toString(),
> bop.getOperationInfo()
> .getName());
> }
> }
> }
> return payloadElementMap;
> }
> The problem is that it requires the SoapOperationInfo to have a style
> attribute, but in the W3C spec for WSDL it says the style attribute on the
> soap operation is optional, specifically 'If the attribute is not specified,
> it defaults to the value specified in the soap:binding element. If the
> soap:binding element does not specify a style, it is assumed to be
> "document".' So the code needs to check if the soi has a style and if not
> read it from the binding and if not then set it as "document". This is not a
> problem in the WSDLs generated by CXF (as I found out with a HelloWorld test)
> because it creates these optional style attributes, but since W3C says people
> can generate WSDLs without these (and I ran into one) I think it's worth
> fixing.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-3748) Using Dispatch API with SOAPMessage type fails to set WS-Addressing action header properly if there's whitespace after the soap:body
[
https://issues.apache.org/jira/browse/CXF-3748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Pangburn updated CXF-3748:
Attachment: patch3747and3748.txt
patch3748.txt
Two patches are attached. patch3748.txt fixes just this bug.
patch3747and3748.txt fixes this bug and 3747 together since they're both in the
same file and I am editing on the same revision.
> Using Dispatch API with SOAPMessage type fails to set WS-Addressing action
> header properly if there's whitespace after the soap:body
>
>
> Key: CXF-3748
> URL: https://issues.apache.org/jira/browse/CXF-3748
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 2.4.1
>Reporter: Jesse Pangburn
>Priority: Minor
> Labels: dispatch, soapmessage, ws-addressing
> Attachments: patch3747and3748.txt, patch3748.txt
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> if you use a SOAPMessage instead of a Source then the following function
> fails (ignoring the exception) and your ws-addressing action doesn't get set-
> if you have any whitespace after the soap:body element before your first
> payload element:
> private String getPayloadElementName(SOAPMessage soapMessage) {
> try {
> SOAPElement element =
> (SOAPElement)soapMessage.getSOAPBody().getChildElements().next();
> return new QName(element.getNamespaceURI(),
> element.getLocalName()).toString();
> } catch (Exception e) {
> //ignore
> }
> return null;
>
> }
> This fails because the .next() call at the end gets a text node instead of an
> element object so the cast fails. So inexplicably your ws-addressing action
> header doesn't get set as far as the user sees.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3748) Using Dispatch API with SOAPMessage type fails to set WS-Addressing action header properly if there's whitespace after the soap:body
Using Dispatch API with SOAPMessage type fails to set WS-Addressing action
header properly if there's whitespace after the soap:body
Key: CXF-3748
URL: https://issues.apache.org/jira/browse/CXF-3748
Project: CXF
Issue Type: Bug
Components: JAX-WS Runtime
Affects Versions: 2.4.1
Reporter: Jesse Pangburn
Priority: Minor
if you use a SOAPMessage instead of a Source then the following function fails
(ignoring the exception) and your ws-addressing action doesn't get set- if you
have any whitespace after the soap:body element before your first payload
element:
private String getPayloadElementName(SOAPMessage soapMessage) {
try {
SOAPElement element =
(SOAPElement)soapMessage.getSOAPBody().getChildElements().next();
return new QName(element.getNamespaceURI(),
element.getLocalName()).toString();
} catch (Exception e) {
//ignore
}
return null;
}
This fails because the .next() call at the end gets a text node instead of an
element object so the cast fails. So inexplicably your ws-addressing action
header doesn't get set as far as the user sees.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3747) Dispatch client fails to set WS-Addressing Action header when WSDL's soap:operation does not have a style attribute
Dispatch client fails to set WS-Addressing Action header when WSDL's
soap:operation does not have a style attribute
---
Key: CXF-3747
URL: https://issues.apache.org/jira/browse/CXF-3747
Project: CXF
Issue Type: Bug
Components: JAX-WS Runtime
Affects Versions: 2.4.1
Reporter: Jesse Pangburn
Priority: Minor
I found the cause of the problem to be a bug in this method in CXF (I have
version 2.4.1):
private Map createPayloadEleOpNameMap(BindingInfo
bindingInfo) {
Map payloadElementMap = new java.util.HashMap();
for (BindingOperationInfo bop : bindingInfo.getOperations()) {
SoapOperationInfo soi =
(SoapOperationInfo)bop.getExtensor(SoapOperationInfo.class);
if (soi != null) {
if ("document".equals(soi.getStyle())) {
// if doc
if (bop.getOperationInfo().getInput() != null
&&
!bop.getOperationInfo().getInput().getMessageParts().isEmpty()) {
QName qn =
bop.getOperationInfo().getInput().getMessagePartByIndex(0)
.getElementQName();
payloadElementMap.put(qn.toString(),
bop.getOperationInfo().getName());
}
} else if ("rpc".equals(soi.getStyle())) {
// if rpc
payloadElementMap.put(bop.getOperationInfo().getName().toString(),
bop.getOperationInfo()
.getName());
}
}
}
return payloadElementMap;
}
The problem is that it requires the SoapOperationInfo to have a style
attribute, but in the W3C spec for WSDL it says the style attribute on the soap
operation is optional, specifically 'If the attribute is not specified, it
defaults to the value specified in the soap:binding element. If the
soap:binding element does not specify a style, it is assumed to be "document".'
So the code needs to check if the soi has a style and if not read it from the
binding and if not then set it as "document". This is not a problem in the
WSDLs generated by CXF (as I found out with a HelloWorld test) because it
creates these optional style attributes, but since W3C says people can generate
WSDLs without these (and I ran into one) I think it's worth fixing.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
