Hi,
Please see my answers inline
OMDataSource having dependency on ADBBean? I think u didn't mean it :).
No not at all. The special "ADBOMElement" that I am talking about
lives inside the ADB runtime and depends on AXIOM, not the other way
around.
Let me re-phrase this. Ajith, please confirm if you agree.
There will be a new OMElement implementation (say,
ObjectWrappingOMElement) which extends from OMElement. It will have a
constructor to get an instance of OMObjectWrapper.
public interface OMObjectWrapper(){
public XMLStreamReader getPullParser();
public void writeYourSelf(XMLStreamWriter);
}
public class OMObjectWrappingElement extends OMElement{
public OMObjectWrappingElement(OMObjectWrapper wrapper){
}
public void serializeWithConsume(XMLStreamWriter writer){
wrapper.writeYourSelf(writer)
}
}
And perhaps implement the OMObjectWrapper interface to ADBBean so that
ADBBean can be directly input to the constructor of the
OMObjectWrappingElement.
I was thinking a slightly different approach. We have an
'ADBOMElement' abstract class that has the write method unimplemented
(and the rest of the methods are implemented in a generic way which I
suppose is reasonable)
During the codegen ADBBeans will have a method "getOMElement" which
returns the ADBOMElement with the write method implemented!
public OMElement getOMElement(){
return new ADBOMElement(this){
public void write(XMLStreamWriter writer){
// generated code that writes the output directly
}
}
}
--
Ajith Ranabahu
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
