You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Isuru Suriarachchi <is...@gmail.com> on 2007/02/08 15:24:18 UTC
[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
Re: [Axis2] Suggesting an improvement in OMSourcedElementImpl
Posted by Thilina Gunarathne <cs...@gmail.com>.
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 (scheu@apache.org)
> 512-838-5115 (IBM TL 678-5115)
> [image: Inactive hide details for "Isuru Suriarachchi"
> <is...@gmail.com>]"Isuru Suriarachchi" <is...@gmail.com>
>
>
>
> *"Isuru Suriarachchi" <is...@gmail.com>*
>
> 02/08/2007 08:24 AM Please respond to
> axis-dev@ws.apache.org
>
>
> To
>
> axis-dev@ws.apache.org
> 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/
Re: [Axis2] Suggesting an improvement in OMSourcedElementImpl
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
+1 to Rich's solution:
- add getNamespace() and getLocalName() to OMDataSource
- add new constructor
- change OMSourcedElementImpl.getNamespace() etc. to call down to the
OMDataSource when needed.
Sanjiva.
On Thu, 2007-02-08 at 11:04 -0600, R J Scheuerle Jr wrote:
> So let me rephrase the reqest.
>
> Introduce a constructor without a namespace and localPart.
> OMSourcedElementImpl(OMDataSource dataSouce)
>
> When the namespace or localName are needed, a OMSourceElement obtains
> them by expanding the tree.
>
> ----------------------------------------
>
> My response:
>
> +1 as an intermediate solution.
>
> 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
>
> Rich Scheuerle
> IBM Web Services
> Apache Axis2 (scheu@apache.org)
> 512-838-5115 (IBM TL 678-5115)
> Inactive hide details for Isuru"Isuru Suriarachchi"
> <is...@gmail.com>
>
>
> "Isuru Suriarachchi" <is...@gmail.com>
>
> 02/08/2007 08:24 AM
> Please respond to
> axis-dev@ws.apache.org
>
>
> To
>
> axis-dev@ws.apache.org
>
> 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.OMFactory omFactory,
> 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
>
>
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Suggesting an improvement in OMSourcedElementImpl
Posted by R J Scheuerle Jr <sc...@us.ibm.com>.
So let me rephrase the reqest.
Introduce a constructor without a namespace and localPart.
OMSourcedElementImpl(OMDataSource dataSouce)
When the namespace or localName are needed, a OMSourceElement obtains them
by expanding the tree.
----------------------------------------
My response:
+1 as an intermediate solution.
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
Rich Scheuerle
IBM Web Services
Apache Axis2 (scheu@apache.org)
512-838-5115 (IBM TL 678-5115)
"Isuru
Suriarachchi"
<isurues@gmail.co To
m> axis-dev@ws.apache.org
cc
02/08/2007 08:24
AM Subject
[Axis2] Suggesting an improvement
in OMSourcedElementImpl
Please respond to
axis-dev@ws.apach
e.org
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.OMFactory
omFactory, 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