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 ([EMAIL PROTECTED])
512-838-5115 (IBM TL 678-5115)
"Takahide
Nogayama"
<[EMAIL PROTECTED] To
om> [email protected]
cc
07/08/2008 11:46
AM Subject
Re: [AXIOM] Prefix mismatch of
OMSourcedElement
Please respond to
[EMAIL PROTECTED]
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 <[EMAIL PROTECTED]>:
>
> 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 ([EMAIL PROTECTED])
> 512-838-5115 (IBM TL 678-5115)
> [image: Inactive hide details for Nicholas L
Gallardo/Austin/[EMAIL PROTECTED]
> L Gallardo/Austin/[EMAIL PROTECTED]
>
>
>
> *Nicholas L Gallardo/Austin/[EMAIL PROTECTED]
>
> 07/02/2008 08:51 AM Please respond to
> [email protected]
>
>
>
> To
>
> [email protected]
> 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 <[EMAIL PROTECTED]>
>
>
> *Davanum Srinivas <[EMAIL PROTECTED]>*
>
> 07/02/2008 07:52 AM
>
> Please respond to
> [email protected]
> To
>
> [email protected] 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: [EMAIL PROTECTED]
> | ---------------------------
> |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFIa3nwgNg6eWEDv1kRAkPDAJwLFZdNGDxZCM4Dw3fjlX8tBi1QSgCePtc0
> JWecKvm+rRNlmAjm+flSJNA=
> =ztK8
> -----END PGP SIGNATURE-----
>
>
