axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From R J Scheuerle Jr <>
Subject Re: [Proposal][Axis2][Axiom] Adding writable capability to OM elementse
Date Sat, 17 Jun 2006 12:53:56 GMT

Hi Ajith,

Thanks for the response.

I agree with your general intent.  But I would like to present a scenario
to help shape the proposal.

At the client, we have an Object (for the purpose of this scenario let's
assume that it is a JAXB object).
The Object represents the payload of the message.  We want to logically
insert this into the OM tree underneath the body.
Once the Object is added into the OM tree, one of the following two things
could happen:
    1) No qos handlers touch the body of the message.  Thus the Object
remains in the tree until the transport layer and is directly written to an
XMLStreamWriter.  No Object->OM transformation occurs.
    2) A qos touches the body.  A transformation needs to occur to convert
the Object into OM via an XMLStreamReader.


I agree with Eran's proposal for an OMObjectWrapper.  The "OMOW" contains
methods for obtaining the XMLStreamReader and writing to an

Developers would implement concrete OMOW classes for their objects.  For
example, there would be an OMJAXBWrapper object.

public class OMJAXBWrapper {
   public OMJAXBWrapper(JAXBContext context, Object jaxb) {
   public XMLStreamReader getPullParser() { ... }

 public void writeYourSelf(XMLStreamWriter) { ...use jaxb context
marshaller to write the jaxb object to the XMLStreamWriter ... }

We would need a concrete class in Axiom whose job is hold a
OMObjectWrapper.  Again I agree (I think) with Eran's proposal:

public class OMObjectWrappingElement extends OMElement{

  public OMObjectWrappingElement(OMObjectWrapper wrapper){


  public void serializeWithConsume(XMLStreamWriter writer){


My concern is that the OMOWE is not like a normal OMElement.  It will not
have a Namespace when it is constructed.
(To get the namespace/localpart, the implementation would need to examine
the underlying Object...which would cause a serialization (for JAXB)...
which defeats the whole effort...)

Ajith, this is a great idea!  I would like to see more details so that I
can mesh the proposal with what we need for JAX-WS/JAX-B.
This is very similar (but much, much cleaner) to the SAAJ code that I
worked on in Axis 1.0.

Rich Scheuerle
Senior Developer
IBM WebSphere Web Services Engine & Tooling

             "Ajith Ranabahu"                                              
   >                                                  To 
             06/17/2006 04:30                                           cc 
                                       Re: [Proposal][Axis2][Axiom] Adding 
             Please respond to         writable capability to OM elements  

Hi Rich,
please see my comments inline

  A) Should the "Special OMElement" have a constructor that takes an Object
  It would be nice if a user could create a derivation of the "Special
  OMElement" and source it with other (non-ADB) objects.

Of course, there are multiple implementation of these special OMElements. I
was only talking about the ADB specific implementation but there can be
multiples of them :)

  B) If an OM tree contains a "Special OMElement" as a leaf node and the
  "Special OMElement" is touched, is the "Special OMElement" converted into
  a normal OMElement subtree ?

  I assume that the following takes place:
  i) The "Special OMElement" is touched.
  ii) The OM implementation detaches the "Special OMElement" from the tree.
  iii) A new OMElement is inserted into the tree at the same location.
  iv) The new OMElement is sourced by the XMLStreamReader obtained from the
  "Special OMElement".

  Is this correct ?

Well I'm not sure whether it should be that difficult. I mean the given
OMElement can act as a  usual OMElement in every other aspect except for
the special method of writing. Anyway this is one point that we have to
think carefully.


  C) Assuming that the answer to (B) is true, can the "Special OMElement"
  represent more than a single sub-tree ?

  Suppose the logical content of the "Special OMElement" is the following.
  <p:a xmlns:p="urn://sample" />
  <p:b xmlns:p="urn://sample" />

  Does the above get converted into two peer elements, or is this an
  erroneous situation ?


Hmm... The special OMElement can never have two peer elements. It is just
one OMElement (with its own local name) and represents a single sub tree.


  Rich Scheuerle
  Senior Developer
  IBM WebSphere Web Services Engine & Tooling
  512-838-5115 (IBM TL 678-5115)
  Inactive hide details for "Ajith Ranabahu" <>
  "Ajith Ranabahu" <>

                         Ranabahu" <                                       
                         om>                                            To 
                                               "Axis developer list" <     
                         06/16/2006  >,    
                         07:37 AM       
          Please respond to                                                                                            
                                               Adding writable capability  
                                               to OM elements              

  Hi All,
  There have been some talk about performance improvements for Axis2
  next steps. So here is a small proposal of how to do a possible
  optimization with AXIOM and ADB.

  1. AXIOM needs to have an interface that allows a XMLStreamWriter to
  passed. This allows the implementer (of the interface) to have code
  that directly uses the writer. (Currently the OMDataSource has the
  necessary methods. We actually need only one, the write method).

  2. We have a special OMElement abstract class that implements the
  OMDataSource that has a constructor taking in an ADBBean.

  3. All ADB beans are added an extra method to pump out a special
  OMElement that have the write code generated. Note that this is a
  concrete class based on the special OMElement mentioned in [2].

  4. The ADB databinding template is changed to get the OMElement from
  the ADBBean instead of building one. We basically change the
  implementation of the toOM method.

  Thoughts ?

  BTW - I am still writing the answer to Dennis about unwrapping :)
  Ajith Ranabahu

  p.s. - sorry for resending. Messed up the subject in the first one :(

  To unsubscribe, e-mail:
  For additional commands, e-mail:

Ajith Ranabahu
View raw message