Hi all,
I think a better solution is to put getNamespace() and getLocalName()
methods on the OMDataSource.
A particular implementation of the OMDataSource could then provide this
information without causing a full expansion.
For example an OMDataSource that is implemented with a backing InputStream
could
1) read the namespace and localpart from the stream
2) rewind the stream
This sounds fine in most of the cases.. Infact we have been doing this
sneaking in the JSONDataSource for the localpart. But with JSON badgerfish
convention namespaces are serialized as attributes. JSON follows a format as
follows in which the attributes of the first element appears at the very end
of the stream.
{firstElement {second ... {third...}} attributesOfTheFirstElement}
As you might have already noticed above, in the JSON scenario we need to
read the whole stream to read the namespace, which is as worse as parsing
the whole stream.. But again we can document the getNamspace() of the JSON
as an expensive operation..
Thanks,
Thilina
Rich Scheuerle
IBM Web Services
Apache Axis2 ([EMAIL PROTECTED])
512-838-5115 (IBM TL 678-5115)
[image: Inactive hide details for "Isuru Suriarachchi"
<[EMAIL PROTECTED]>]"Isuru Suriarachchi" <[EMAIL PROTECTED]>
*"Isuru Suriarachchi" <[EMAIL PROTECTED]>*
02/08/2007 08:24 AM Please respond to
[email protected]
To
[email protected]
cc
Subject
[Axis2] Suggesting an improvement in OMSourcedElementImpl
Hi all,
When creating an OMSourcedElementImpl object, we should provide the
expected local name and the namespace of the OMElement which will be built
by consuming the OMDataSource inside. *
public OMSourcedElementImpl(java.lang.String string,
org.apache.axiom.om.OMNamespace omNamespace,
org.apache.axiom.om.OMFactoryomFactory,
org.apache.axiom.om.OMDataSource omDataSource) *
I'm using this OMSourcedElementImpl in JSON implementation of Axis2, in
the receiving side to build the OMElement. I keep the JSON input stream in
the DataSource and consume it only when the OMElement needs to be built. If
the service is a Javascript one, it can understand JSON and I let the user
to access the JSON string directly through DataSource, without building the
OMElement.
But there is a problem of knowing the local name and the namespace of the
OMElement at the time we instantiate the OMSourcedElementImpl, because the
input stream is not consumed at that time. Whole input stream should be
passed in order to get the namespace of the incoming message. If we use a
wrong local name and a namespace, it throws an exception stating that the
local name and the namespace are not expected ones.
I think the usage of providing the local name and the namespace at the
time of instantiation exists in the case of someone calling getLocalName()
method or getNamespace() method before the DataSource is consumed.
As a solution for the above problem, can we have another constructor in
OMSourcedElementImpl which doesn't need the local name and namesapace? If
someone will call getLocalName() or getNamespace() we can let it build the
OMElement in the case of local name and namespace are not given through the
constructor. In our case regarding JSON, getLocalName() and getNamespace()
are called very rarely. So even if we use this method, the advantage of
using the OMSourcedElementImpl will remain as it was earlier.
regards,
~Isuru
--
Thilina Gunarathne
WSO2, Inc.; http://www.wso2.com/
Home page: http://webservices.apache.org/~thilina/
Blog: http://thilinag.blogspot.com/
