[
https://issues.apache.org/jira/browse/WSCOMMONS-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612926#action_12612926
]
Rich Scheuerle commented on WSCOMMONS-360:
------------------------------------------
After some design work, I have decided to take a different approach.
Here is the design that I am currently testing.
1) The OMDataSourceExt has a new property, "lossyPrefix". If the
implementation of the OMDataSource can change the prefix, then it must set the
property to Boolean.TRUE. Example, the JAXBDataSource in Axis2 will set this
property to true.
2) When an OMSourcedElement is constructed (or its OMDataSource is updated),
then the "lossyPrefix" property is queried. If it is set to true, then a
special OMNamespace is constructed, DeferredNamespace. The DeferredNamespace
will force expansion of the OMSE if the prefix is requested.
This design more clearly satisfies Takehide's request to have the OMDataSource
define the prefix. The design is more predictable (i.e.it does not depending
on null or empty prefix settings).
I am currently testing the changes. If they are successful I will commit them
later today.
> Prefix mismatch of OMSourcedElement
> ------------------------------------
>
> Key: WSCOMMONS-360
> URL: https://issues.apache.org/jira/browse/WSCOMMONS-360
> Project: WS-Commons
> Issue Type: Improvement
> Components: AXIOM
> 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.
-
You can reply to this email to add a comment to the issue online.
