You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by "Davanum Srinivas (JIRA)" <ji...@apache.org> on 2008/07/07 20:20:31 UTC
[jira] Created: (WSCOMMONS-360) Prefix mismatch of
OMSourcedElement
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.
[jira] Work started: (WSCOMMONS-360) Prefix mismatch of
OMSourcedElement
Posted by "Rich Scheuerle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSCOMMONS-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on WSCOMMONS-360 started by Rich Scheuerle.
> 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.
[jira] Commented: (WSCOMMONS-360) Prefix mismatch of
OMSourcedElement
Posted by "Takahide Nogayama (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSCOMMONS-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12613080#action_12613080 ]
Takahide Nogayama commented on WSCOMMONS-360:
---------------------------------------------
It looks good. Thanks.
> 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.
[jira] Commented: (WSCOMMONS-360) Prefix mismatch of
OMSourcedElement
Posted by "Rich Scheuerle (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (WSCOMMONS-360) Prefix mismatch of
OMSourcedElement
Posted by "Takahide Nogayama (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSCOMMONS-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612584#action_12612584 ]
Takahide Nogayama commented on WSCOMMONS-360:
---------------------------------------------
OK, I was misunderstanding that the OMNamespace does not have prefix.
Then, if (the prefix of the OMNamespace/QName is not null/"") and (the prefix is not same as the serialized prefix at the fourceExapnd), then do you plan to throw Exception?
> 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.
[jira] Resolved: (WSCOMMONS-360) Prefix mismatch of
OMSourcedElement
Posted by "Rich Scheuerle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSCOMMONS-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rich Scheuerle resolved WSCOMMONS-360.
--------------------------------------
Resolution: Fixed
I just changed axis2 jaxws to set the "lossyPrefix" property when JAXB is used.
Committed revision 676623.
> 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.
[jira] Commented: (WSCOMMONS-360) Prefix mismatch of
OMSourcedElement
Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSCOMMONS-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611764#action_12611764 ]
Davanum Srinivas commented on WSCOMMONS-360:
--------------------------------------------
Sounds good Rich!
> 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.
[jira] Commented: (WSCOMMONS-360) Prefix mismatch of
OMSourcedElement
Posted by "Takahide Nogayama (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSCOMMONS-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612379#action_12612379 ]
Takahide Nogayama commented on WSCOMMONS-360:
---------------------------------------------
I agree the solution to expand OMSE as late as possible. Let me confirm my understanding. Currently we have five constructors in OMSE below.
(1) public OMSourcedElementImpl(String localName, OMNamespace ns, OMFactory factory, OMDataSource source);
(2) public OMSourcedElementImpl(QName qName, OMFactory factory, OMDataSource source);
(3) public OMSourcedElementImpl(String localName, OMNamespace ns, OMContainer parent, OMFactory factory);
(4) public OMSourcedElementImpl(String localName, OMNamespace ns, OMContainer parent, OMXMLParserWrapper builder, OMFactory factory);
(5) public OMSourcedElementImpl(String localName, OMNamespace ns, OMFactory factory);
If one of (1), (3), (4), and (5) is used, OMSE creater does not know the prefix, or prefix is "". The OMSE should be expanded by using Rich's solution when prefix is needed.
IF (2) is used, OMSE creater knows the prefix beforehand. The OMSE should not be expanded when the prefix is needed. becuase the first prefix and the second prefix (it appears at serialization) are the same.
That is, If the prefix in QName is different from the second prefix, (we can detect this at "forceExpand()") then the forceExpand should throw exception("prefix mismatch"). To avoid expantion for the prefix, if the OMSE creater knows that the prefix will be used, then the creater uses constructor (2).
Is my understanding correct?
> 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.
[jira] Commented: (WSCOMMONS-360) Prefix mismatch of
OMSourcedElement
Posted by "Rich Scheuerle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSCOMMONS-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612473#action_12612473 ]
Rich Scheuerle commented on WSCOMMONS-360:
------------------------------------------
Takahide,
The implementation will be different from what you proposed above.
An OMNamespace object contains both the uri and the prefix. Thus if constructors (1), (3), (4), (5) are used then no expansion is necessary when
"OMNamespace getOMNamespace()" is invoked.
Constructor (2) uses a QName. A QName stores the local name, namespace uri and optionally the prefix. If the prefix is "", then the OM will be expanded when the prefix is needed.
I am working on a solution now.
> 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.
[jira] Commented: (WSCOMMONS-360) Prefix mismatch of
OMSourcedElement
Posted by "Rich Scheuerle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSCOMMONS-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611714#action_12611714 ]
Rich Scheuerle commented on WSCOMMONS-360:
------------------------------------------
Primary Problem:
An OMSourcedElement is created with a backing OMDataSource. The namespace and local part are known at the point of creation. However the prefix may not be known.
(Example, the namespace and local part are known for a JAXB object, but we don't know the prefix that will be used).
Possible Solution:
The OMSE getNamespace() method should return a special OMNamespace.
The OMNamespace.getPrefix() method can then be coded to obtain the prefix (if not known) from the OMSE. This will defer the expansion of the
OMSE until the prefix is actually requested.
Secondary Problem:
This issue is caused by an OMSE wrapping a JAXB object. In such cases, we don't know the prefix. If we implement the solution above, we will still get
OMSE expansion when the getPrefix code is queried.
Secondary Solution:
Some JAXB implementations (i.e. Sun) provide vendor properties that control the prefix>namespace mapping when marshalling. We could use such a property in the
Axis2 JAXB datasource layer to ensure that a specific prefix is used. Thus we can use this information to get the prefix information without causing expansion.
> 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.