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.
Scenario:
--------------
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.
Structure
-------------
I agree with Eran's proposal for an OMObjectWrapper. The "OMOW" contains methods for obtaining the XMLStreamReader and writing to an XMLStreamWriter.
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){
wrapper.writeYourSelf(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
[EMAIL PROTECTED]
![Inactive hide details for "Ajith Ranabahu" <[EMAIL PROTECTED]>](gifQ5P3Ivgas6.gif){kind=small}
"Ajith Ranabahu" <[EMAIL PROTECTED]>
06/17/2006 04:30 AM
|
|
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.
- Thanks,
Rich Scheuerle
Senior Developer
IBM WebSphere Web Services Engine & Tooling
512-838-5115 (IBM TL 678-5115)
![Inactive hide details for "Ajith Ranabahu" <[EMAIL PROTECTED]>](gifUvVffhyHZ2.gif){kind=small}
"Ajith Ranabahu" < [EMAIL PROTECTED]>
06/16/2006 07:37 AM
|
|
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ajith Ranabahu
