[
https://issues.apache.org/jira/browse/CXF-4920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13614058#comment-13614058
]
Piotr Klimczak edited comment on CXF-4920 at 3/26/13 2:37 PM:
--------------------------------------------------------------
Hi Aki,
Thanks for your answer.
What is the name of that test? I would like to take a look at it.
I know that it sounds crazy when i'm saying that i found such a bug that exists
from the very beginning of CXF 2.X (or meybe even 1.X). The exact situation is
quite difficult to reproduce as i've hitted this bug using CXF to handle
WebServices over HTTP with this interceptors:
* WS Security Signature + timestamp
* LoggingInInterceptor
* TransformInInterceptors (transforming namespaces)
Similar interceptors are used for OUT.
Using WS Security altogether with TransformIn/OutInterceptor was very difficult
to get it work as default position for in/out interceptors in interceptor chain
makes them unusable.
So finally in such a complicated configuration i've hitted this bug.
I have found it in CXF code doing tracing and debuging.
I was not able to reproduce this situation in any unit test that covers hughe
part of code (basing on existing unit test). Also the real life situation was
too dificult to be reproduced in unit test. But as I remember the exception was
raised with some kind of unknown prefix exception.
The only way to reproduce this bug in a test case was to test the very small
piece of code.
Those patches have solved my problems but i need them to be official.
But let's go back to your test.
In your example you are transforming different namespace that the one making
problems.
Try to transform "http://bar.com/foo"; to anyhing else. Then it should fail.
I know that testcases are saying everything is ok, but if you take a look at
the code and analyze it, you will see there is a bug in cache strategy.
It caches two maps:
1 prefix as key, ns as a value => MAPPING PREFIXES TO NAMESPACES
2 ns as a key, prefix as a value => MAPPING PREFIXES TO NAMESPACES
The problem is with mapping prefixes to namespaces.
When it find in XML shuch part: q1="http://bar.com/foo"; then it adds to cache
maps:
PREFIXES:
{code}
q1 =>http://bar.com/foo
{code}
NAMESPACES:
{code}
http://bar.com/foo => q1
{code}
So when it hits: q2="http://bar.com/foo";, then it adds:
PREFIXES:
{code}
q2 => http://bar.com/foo
{code}
NAMESPACES:
{code}
http://bar.com/foo => q2
{code}
So after second prefix with same name, PREFIXES contains 2 elements but
NAMESPACES cache contains only one element with the key q2. So the q1 prefix is
forgotten in NAMESPACES when it is known in PREFIXES.
This situation is unexpected and it is solved in my patches.
Greetings
Piotr Klimczak
was (Author: nannou9):
Hi Aki,
Thanks for your answer.
What is the name of that test? I would like to take a look at it.
I know that it sounds crazy when i'm saying that i found such a bug that exists
from the very beginning of CXF 2.X (or meybe even 1.X). The exact situation is
quite difficult to reproduce as i've hitted this bug using CXF to handle
WebServices over HTTP with this interceptors:
* WS Security Signature + timestamp
* LoggingInInterceptor
* TransformInInterceptors (transforming namespaces)
Similar interceptors are used for OUT.
Using WS Security altogether with TransformIn/OutInterceptor was very difficult
to get it work as default position for in/out interceptors in interceptor chain
makes them unusable.
So finally in such a complicated configuration i've hitted this bug.
I have found it in CXF code doing tracing and debuging.
I was not able to reproduce this situation in any unit test that covers hughe
part of code (basing on existing unit test. Also the real life situation was
too dificult to be reproduced in unit test.
The only way to reproduce this bug in a test case was to test the very small
piece of code.
But let's go back to your test.
In your example you are transforming different namespace that the one making
problems.
Try to transform "http://bar.com/foo"; to anyhing else. Then it should fail.
I know that testcases are saying everything is ok, but if you take a look at
the code and analyze it, you will see there is a bug in cache strategy.
It caches two maps:
1 prefix as key, ns as a value => MAPPING PREFIXES TO NAMESPACES
2 ns as a key, prefix as a value => MAPPING PREFIXES TO NAMESPACES
The problem is with mapping prefixes to namespaces.
When it find in XML shuch part: q1="http://bar.com/foo"; then it adds to cache
maps:
PREFIXES:
{code}
q1 =>http://bar.com/foo
{code}
NAMESPACES:
{code}
http://bar.com/foo => q1
{code}
So when it hits: q2="http://bar.com/foo";, then it adds:
PREFIXES:
{code}
q2 => http://bar.com/foo
{code}
NAMESPACES:
{code}
http://bar.com/foo => q2
{code}
So after second prefix with same name, PREFIXES contains 2 elements but
NAMESPACES cache contains only one element with the key q2. So the q1 prefix is
forgotten in NAMESPACES when it is known in PREFIXES.
This situation is unexpected and it is solved in my patches.
Greetings
Piotr Klimczak
> TransformationInInterceptor fails when XML contains same namespace with
> different prefixes
> ------------------------------------------------------------------------------------------
>
> Key: CXF-4920
> URL: https://issues.apache.org/jira/browse/CXF-4920
> Project: CXF
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.3, 2.4, 2.5, 2.6, 2.7.3, 2.8.0
> Environment: FuseESB 4.4.1-07-11 on SLES
> Reporter: Piotr Klimczak
> Assignee: Aki Yoshida
> Priority: Critical
> Labels: core, failed, interceptors, missing, namespace, prefix,
> transform
> Attachments: CXF4920.diff, CXF4920-v2.5.X.diff, CXF4920-v2.6.X.diff
>
>
> TransformationInInterceptor fails when XML contains same namespace with
> different prefixes.
> So for example this will fail:
> {code}
> <wireTransfer xmlns:q1="http://bar.com/foo"; xsi:type="q1:SwiftWireTransfer">
> ...
> </wireTransfer>
> <wireTransfer xmlns:q2="http://bar.com/foo"; xsi:type="q2:SwiftWireTransfer">
> ...
> </wireTransfer>
> {code}
> as for "q2:SwiftWireTransfer" the prefix q2 would be never found due to
> internal cache strategy.
> So the above bug blocks usage of such kind of XML message.
> Of cource using different prefixes for same namespaces is not a good
> practice, but when there is a need to "talk" with external vendor software
> (as in my situation) there might be no chance to fix it on second side.
> I have this already fixed.
> Will apply patch in few moments.
> Greetings,
> Piotr Klimczak
--
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
