[
https://issues.apache.org/jira/browse/AXIOM-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13263216#comment-13263216
]
Hudson commented on AXIOM-334:
------------------------------
Integrated in ws-axiom-trunk #908 (See
[https://builds.apache.org/job/ws-axiom-trunk/908/])
AXIOM-334: Added unit tests for the "lossy prefix" feature (which had zero
test coverage) and fixed a couple of issues revealed by these tests. (Revision
1331112)
Result = SUCCESS
veithen :
Files :
*
/webservices/commons/trunk/modules/axiom/modules/axiom-impl/src/main/java/org/apache/axiom/om/impl/llom/OMSourcedElementImpl.java
*
/webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/sourcedelement/OMSourcedElementVariant.java
*
/webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/sourcedelement/TestGetNamespace.java
*
/webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/sourcedelement/TestGetPrefix.java
> Prefix mismatch of OMSourcedElement
> ------------------------------------
>
> Key: AXIOM-334
> URL: https://issues.apache.org/jira/browse/AXIOM-334
> Project: Axiom
> Issue Type: Improvement
> Reporter: Davanum Srinivas
> Assignee: Rich Scheuerle
> Priority: Critical
>
> Discussion here - http://markmail.org/message/ks7taa4upual3ufj
> ============== Text from initial email ==================
> Hi folks,
> I am facing prefix mismatch problem of OMSourcedElement. If we get a
> prefix from non-expanded OMSE by using OMSE.getNamespace().getPrefix(),
> the returned prefix is "". But if we get the prefix from expanded OMSE,
> then the returned prefix is "ns1". The first default OMNamespace is set by
> OMSE creater (can be outside of axiom and axis2) through constructor
> argument, The second OMNamespace is created from OMDatasource when it is
> expanded. Since these two OMNamespace are created by different ways, the
> prefixes can be mismatch.
> OMSourcedElement should return the same data regardless of whether it is
> expanded or not. I think the OMNamespace should not be provided by
> Constructor, but should be provided by OMDataSource to avoid such prefix
> mismatch, otherwise we have to expand OMSourcedElement when getNamespace()
> is invoked. I am not sure there are other ways to avoid this problem...
> ============== Text from initial email ==================
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
