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 Takahide Nogayama <NO...@jp.ibm.com> on 2008/07/02 13:24:27 UTC
[AXIOM] Prefix mismatch of OMSourcedElement
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...
Let me know your comments.
Regards,
---------------------------
Takahide Nogayama, IBM Tokyo Research Laboratory
E-mail: nogayama@jp.ibm.com
---------------------------
Re: [AXIOM] Prefix mismatch of OMSourcedElement
Posted by Takahide Nogayama <no...@gmail.com>.
Two methods OMSE.getNamespace() and OMSE.getLocalName() do not involve
expansion to avoid the expansion as late as possible. Typical XML processor
checks localname and namespace URI first, then decides whether it should
process the sub-tree or not. Caching Localname and Namespace is smart way
for lazy evaluation.
2008/7/2, Nicholas L Gallardo <nl...@us.ibm.com>:
>
> That doesn't necessarily make sense to me. If all we want to know is
> possibly the namespace/localname of the element, then we've blown out all
> the of the content of the OMSourcedElement.
>
> So for instance, anyone that just checks the QName of the element on an
> outbound flow for JAX-WS is going to blow out the element. That eliminates
> the performance gains of writing to the outbound stream as late as possible.
>
> Takahide, I see your point. There is potential for inconsistency with the
> way prefixes are returned.
>
> The problem is that not all sources of OMSourcedElements can know ahead of
> time what the root element prefix is going to be. For example, if your OMSE
> is backed by JAXB then there's no way to specify what that prefix is going
> to be in the JAXB Marshaller. Because of that, we're at the mercy of what
> JAXB returns.
>
> Regards,
>
> -Nick
>
>
> [image: Inactive hide details for Davanum Srinivas <da...@gmail.com>]Davanum
> Srinivas <da...@gmail.com>
>
>
>
> *Davanum Srinivas <da...@gmail.com>*
>
> 07/02/2008 07:52 AM Please respond to
> commons-dev@ws.apache.org
>
>
> To
>
> commons-dev@ws.apache.org
> cc
>
>
> Subject
>
> Re: [AXIOM] Prefix mismatch of OMSourcedElement
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Takahide,
>
> Does it make sense to trigger the expanion when getNamespace() is called?
>
> thanks,
> dims
>
> Takahide Nogayama wrote:
> | 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...
> |
> | Let me know your comments.
> |
> | Regards,
> | ---------------------------
> | Takahide Nogayama, IBM Tokyo Research Laboratory
> | E-mail: nogayama@jp.ibm.com
> | ---------------------------
> |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFIa3nwgNg6eWEDv1kRAkPDAJwLFZdNGDxZCM4Dw3fjlX8tBi1QSgCePtc0
> JWecKvm+rRNlmAjm+flSJNA=
> =ztK8
> -----END PGP SIGNATURE-----
>
>
Re: [AXIOM] Prefix mismatch of OMSourcedElement
Posted by R J Scheuerle Jr <sc...@us.ibm.com>.
WSCOMMONS-360 was opened to track this issue.
Currently it is assigned to me.
I will start working on it this week.
Thanks,
Rich Scheuerle
IBM Web Services
Apache Axis2 (scheu@apache.org)
512-838-5115 (IBM TL 678-5115)
"Takahide
Nogayama"
<nogayama@gmail.c To
om> commons-dev@ws.apache.org
cc
07/08/2008 11:46
AM Subject
Re: [AXIOM] Prefix mismatch of
OMSourcedElement
Please respond to
commons-dev@ws.ap
ache.org
But many people uses OMElement.getOMNamepace().getPrefix() or
OMElement.getQName().getPrefix() instead of OMSE.getPrefix() because
OMSE.getPrefix is not in the OMElement interface.
How about adding "String prefix" fields into OMSourcedElement? If the
prefix
is not null, the prefix is the same as the serialized prefix. The prefix is
set by user or Sun namespace mapping. If the prefix is null, and
OMSE.getNamespace() or OMSE.getQName() invoked, then OMSE is expanded.
I have not opened JIRA for this issue.
2008/7/8, R J Scheuerle Jr <sc...@us.ibm.com>:
>
> When the OMSourcedElement is created, the local name, namespace and
> prefix are provided.
>
> It seems reasonable to me that if the prefix is null, that this could be
an
> indication that the backing object does not know the prefix name.
>
> Thus we can make a simple change to the OMSE.getPrefix logic to expand
the
> tree if the initial prefix is null (or perhaps empty). In most cases this
> will be sufficient.
>
> ----------------------
> If we want to improve this for JAXB processing, then we will need to use
> Sun properties to set the namespace/prefix mapping information.
>
> ----------------------
>
> Is there a JIRA open for this work ?
>
>
>
> Rich Scheuerle
> IBM Web Services
> Apache Axis2 (scheu@apache.org)
> 512-838-5115 (IBM TL 678-5115)
> [image: Inactive hide details for Nicholas L
Gallardo/Austin/IBM@IBMUS]Nicholas
> L Gallardo/Austin/IBM@IBMUS
>
>
>
> *Nicholas L Gallardo/Austin/IBM@IBMUS*
>
> 07/02/2008 08:51 AM Please respond to
> commons-dev@ws.apache.org
>
>
>
> To
>
> commons-dev@ws.apache.org
> cc
>
>
> Subject
>
> Re: [AXIOM] Prefix mismatch of OMSourcedElement
>
> That doesn't necessarily make sense to me. If all we want to know is
> possibly the namespace/localname of the element, then we've blown out all
> the of the content of the OMSourcedElement.
>
> So for instance, anyone that just checks the QName of the element on an
> outbound flow for JAX-WS is going to blow out the element. That
eliminates
> the performance gains of writing to the outbound stream as late as
possible.
>
> Takahide, I see your point. There is potential for inconsistency with the
> way prefixes are returned.
>
> The problem is that not all sources of OMSourcedElements can know ahead
of
> time what the root element prefix is going to be. For example, if your
OMSE
> is backed by JAXB then there's no way to specify what that prefix is
going
> to be in the JAXB Marshaller. Because of that, we're at the mercy of what
> JAXB returns.
>
> Regards,
>
> -Nick
>
>
> Davanum Srinivas <da...@gmail.com>
>
>
> *Davanum Srinivas <da...@gmail.com>*
>
> 07/02/2008 07:52 AM
>
> Please respond to
> commons-dev@ws.apache.org
> To
>
> commons-dev@ws.apache.org cc
> Subject
>
> Re: [AXIOM] Prefix mismatch of OMSourcedElement
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Takahide,
>
> Does it make sense to trigger the expanion when getNamespace() is called?
>
> thanks,
> dims
>
> Takahide Nogayama wrote:
> | 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...
> |
> | Let me know your comments.
> |
> | Regards,
> | ---------------------------
> | Takahide Nogayama, IBM Tokyo Research Laboratory
> | E-mail: nogayama@jp.ibm.com
> | ---------------------------
> |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFIa3nwgNg6eWEDv1kRAkPDAJwLFZdNGDxZCM4Dw3fjlX8tBi1QSgCePtc0
> JWecKvm+rRNlmAjm+flSJNA=
> =ztK8
> -----END PGP SIGNATURE-----
>
>
Re: [AXIOM] Prefix mismatch of OMSourcedElement
Posted by Takahide Nogayama <no...@gmail.com>.
But many people uses OMElement.getOMNamepace().getPrefix() or
OMElement.getQName().getPrefix() instead of OMSE.getPrefix() because
OMSE.getPrefix is not in the OMElement interface.
How about adding "String prefix" fields into OMSourcedElement? If the prefix
is not null, the prefix is the same as the serialized prefix. The prefix is
set by user or Sun namespace mapping. If the prefix is null, and
OMSE.getNamespace() or OMSE.getQName() invoked, then OMSE is expanded.
I have not opened JIRA for this issue.
2008/7/8, R J Scheuerle Jr <sc...@us.ibm.com>:
>
> When the OMSourcedElement is created, the local name, namespace and
> prefix are provided.
>
> It seems reasonable to me that if the prefix is null, that this could be an
> indication that the backing object does not know the prefix name.
>
> Thus we can make a simple change to the OMSE.getPrefix logic to expand the
> tree if the initial prefix is null (or perhaps empty). In most cases this
> will be sufficient.
>
> ----------------------
> If we want to improve this for JAXB processing, then we will need to use
> Sun properties to set the namespace/prefix mapping information.
>
> ----------------------
>
> Is there a JIRA open for this work ?
>
>
>
> Rich Scheuerle
> IBM Web Services
> Apache Axis2 (scheu@apache.org)
> 512-838-5115 (IBM TL 678-5115)
> [image: Inactive hide details for Nicholas L Gallardo/Austin/IBM@IBMUS]Nicholas
> L Gallardo/Austin/IBM@IBMUS
>
>
>
> *Nicholas L Gallardo/Austin/IBM@IBMUS*
>
> 07/02/2008 08:51 AM Please respond to
> commons-dev@ws.apache.org
>
>
>
> To
>
> commons-dev@ws.apache.org
> cc
>
>
> Subject
>
> Re: [AXIOM] Prefix mismatch of OMSourcedElement
>
> That doesn't necessarily make sense to me. If all we want to know is
> possibly the namespace/localname of the element, then we've blown out all
> the of the content of the OMSourcedElement.
>
> So for instance, anyone that just checks the QName of the element on an
> outbound flow for JAX-WS is going to blow out the element. That eliminates
> the performance gains of writing to the outbound stream as late as possible.
>
> Takahide, I see your point. There is potential for inconsistency with the
> way prefixes are returned.
>
> The problem is that not all sources of OMSourcedElements can know ahead of
> time what the root element prefix is going to be. For example, if your OMSE
> is backed by JAXB then there's no way to specify what that prefix is going
> to be in the JAXB Marshaller. Because of that, we're at the mercy of what
> JAXB returns.
>
> Regards,
>
> -Nick
>
>
> Davanum Srinivas <da...@gmail.com>
>
>
> *Davanum Srinivas <da...@gmail.com>*
>
> 07/02/2008 07:52 AM
>
> Please respond to
> commons-dev@ws.apache.org
> To
>
> commons-dev@ws.apache.org cc
> Subject
>
> Re: [AXIOM] Prefix mismatch of OMSourcedElement
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Takahide,
>
> Does it make sense to trigger the expanion when getNamespace() is called?
>
> thanks,
> dims
>
> Takahide Nogayama wrote:
> | 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...
> |
> | Let me know your comments.
> |
> | Regards,
> | ---------------------------
> | Takahide Nogayama, IBM Tokyo Research Laboratory
> | E-mail: nogayama@jp.ibm.com
> | ---------------------------
> |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFIa3nwgNg6eWEDv1kRAkPDAJwLFZdNGDxZCM4Dw3fjlX8tBi1QSgCePtc0
> JWecKvm+rRNlmAjm+flSJNA=
> =ztK8
> -----END PGP SIGNATURE-----
>
>
Re: [AXIOM] Prefix mismatch of OMSourcedElement
Posted by R J Scheuerle Jr <sc...@us.ibm.com>.
When the OMSourcedElement is created, the local name, namespace and prefix
are provided.
It seems reasonable to me that if the prefix is null, that this could be an
indication that the backing object does not know the prefix name.
Thus we can make a simple change to the OMSE.getPrefix logic to expand the
tree if the initial prefix is null (or perhaps empty). In most cases this
will be sufficient.
----------------------
If we want to improve this for JAXB processing, then we will need to use
Sun properties to set the namespace/prefix mapping information.
----------------------
Is there a JIRA open for this work ?
Rich Scheuerle
IBM Web Services
Apache Axis2 (scheu@apache.org)
512-838-5115 (IBM TL 678-5115)
Nicholas L
Gallardo/Austin/I
BM@IBMUS To
commons-dev@ws.apache.org
07/02/2008 08:51 cc
AM
Subject
Re: [AXIOM] Prefix mismatch of
Please respond to OMSourcedElement
commons-dev@ws.ap
ache.org
That doesn't necessarily make sense to me. If all we want to know is
possibly the namespace/localname of the element, then we've blown out all
the of the content of the OMSourcedElement.
So for instance, anyone that just checks the QName of the element on an
outbound flow for JAX-WS is going to blow out the element. That eliminates
the performance gains of writing to the outbound stream as late as
possible.
Takahide, I see your point. There is potential for inconsistency with the
way prefixes are returned.
The problem is that not all sources of OMSourcedElements can know ahead of
time what the root element prefix is going to be. For example, if your OMSE
is backed by JAXB then there's no way to specify what that prefix is going
to be in the JAXB Marshaller. Because of that, we're at the mercy of what
JAXB returns.
Regards,
-Nick
Inactive hide details for Davanum Srinivas <da...@gmail.com>Davanum
Srinivas <da...@gmail.com>
Davanum
Srinivas
<davanum@gmai
l.com>
To
07/02/2008 commons-dev@ws.apach
07:52 AM e.org
cc
Please respond to
commons-dev@ws.apache.org
Subject
Re: [AXIOM] Prefix
mismatch of
OMSourcedElement
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Takahide,
Does it make sense to trigger the expanion when getNamespace() is called?
thanks,
dims
Takahide Nogayama wrote:
| 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...
|
| Let me know your comments.
|
| Regards,
| ---------------------------
| Takahide Nogayama, IBM Tokyo Research Laboratory
| E-mail: nogayama@jp.ibm.com
| ---------------------------
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFIa3nwgNg6eWEDv1kRAkPDAJwLFZdNGDxZCM4Dw3fjlX8tBi1QSgCePtc0
JWecKvm+rRNlmAjm+flSJNA=
=ztK8
-----END PGP SIGNATURE-----
Re: [AXIOM] Prefix mismatch of OMSourcedElement
Posted by Nicholas L Gallardo <nl...@us.ibm.com>.
That doesn't necessarily make sense to me. If all we want to know is
possibly the namespace/localname of the element, then we've blown out all
the of the content of the OMSourcedElement.
So for instance, anyone that just checks the QName of the element on an
outbound flow for JAX-WS is going to blow out the element. That eliminates
the performance gains of writing to the outbound stream as late as
possible.
Takahide, I see your point. There is potential for inconsistency with the
way prefixes are returned.
The problem is that not all sources of OMSourcedElements can know ahead of
time what the root element prefix is going to be. For example, if your
OMSE is backed by JAXB then there's no way to specify what that prefix is
going to be in the JAXB Marshaller. Because of that, we're at the mercy of
what JAXB returns.
Regards,
-Nick
Davanum Srinivas
<davanum@gmail.co
m> To
commons-dev@ws.apache.org
07/02/2008 07:52 cc
AM
Subject
Re: [AXIOM] Prefix mismatch of
Please respond to OMSourcedElement
commons-dev@ws.ap
ache.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Takahide,
Does it make sense to trigger the expanion when getNamespace() is called?
thanks,
dims
Takahide Nogayama wrote:
| 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...
|
| Let me know your comments.
|
| Regards,
| ---------------------------
| Takahide Nogayama, IBM Tokyo Research Laboratory
| E-mail: nogayama@jp.ibm.com
| ---------------------------
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFIa3nwgNg6eWEDv1kRAkPDAJwLFZdNGDxZCM4Dw3fjlX8tBi1QSgCePtc0
JWecKvm+rRNlmAjm+flSJNA=
=ztK8
-----END PGP SIGNATURE-----
Re: [AXIOM] Prefix mismatch of OMSourcedElement
Posted by Davanum Srinivas <da...@gmail.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Takahide,
Does it make sense to trigger the expanion when getNamespace() is called?
thanks,
dims
Takahide Nogayama wrote:
| 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...
|
| Let me know your comments.
|
| Regards,
| ---------------------------
| Takahide Nogayama, IBM Tokyo Research Laboratory
| E-mail: nogayama@jp.ibm.com
| ---------------------------
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFIa3nwgNg6eWEDv1kRAkPDAJwLFZdNGDxZCM4Dw3fjlX8tBi1QSgCePtc0
JWecKvm+rRNlmAjm+flSJNA=
=ztK8
-----END PGP SIGNATURE-----