axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From R J Scheuerle Jr <sc...@us.ibm.com>
Subject Re: [Axis2] Suggesting an improvement in OMSourcedElementImpl
Date Thu, 08 Feb 2007 17:04:04 GMT





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
Mime
View raw message