Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Date: Tue, 26 Mar 2013 14:47:17 +0000 (UTC)
From: "Piotr Klimczak (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: <JIRA.12638855.1364209614895.56592.1364309237554@arcas>
In-Reply-To: <JIRA.12638855.1364209614895@arcas>
References: <JIRA.12638855.1364209614895@arcas>
Subject: [jira] [Comment Edited] (CXF-4920) TransformationInInterceptor
 fails when XML contains same namespace with different prefixes
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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:46 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.

Cache is using this two maps:
NAMESPACES: prefix as key, ns as a value => MAPPING PREFIXES TO NAMESPACES
PREFIXES: ns as a key, prefix as a value => MAPPING NAMESPACES TO PREFIXES

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:
NAMESPACES:
{code}
q1 =>http://bar.com/foo
{code}
PREFIXES: 
{code}
http://bar.com/foo => q1
{code}

So when it hits: q2="http://bar.com/foo", then it adds:
NAMESPACES:
{code}
q2 => http://bar.com/foo
{code}
PREFIXES: 
{code}
http://bar.com/foo => q2
{code}

So after second prefix with same name, NAMESPACES contains 2 elements but PREFIXES cache contains only one element with the key q2. So the q1 prefix is forgotten in PREFIXES when it is known in NAMESPACES.

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. 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.

Cache is using this two maps:
PREFIXES: prefix as key, ns as a value => MAPPING PREFIXES TO NAMESPACES
NAMESPACES: ns as a key, prefix as a value => MAPPING NAMESPACES TO PREFIXES

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