You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by Ajith Ranabahu <aj...@gmail.com> on 2006/06/16 14:35:27 UTC
[Proposal] 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
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: [Proposal][Axis2][Axiom] Adding writable capability to OM elements
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi Dennis,
Yes,it seems that OMSourceElementImpl has all the necessary methods
Ajith
On 6/18/06, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> In that case it seems like the existing OMSourceElementImpl should work
> for you. That way you just need to create an OMDataSource implementation
> for wrapping an ADB element, which should be very easy.
>
> - Dennis
>
> Ajith Ranabahu wrote:
> > Hi Dennis,
> > Well I was just thinking of the capability of taking in an
> > XMLStreamWriter. Yes if we ignore the other methods we are likely to
> > break code so it is adviceable to implement all the methods.
> >
> >
> > On 6/17/06, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> >> Hi Ajith,
> >>
> >> Is there a particular reason you want to only implement the
> >> XMLStreamWriter output? The OMDataSource provides a choice of output
> >> methods for compatibility with Axiom's supported output methods. If you
> >> limit your interface to doing XMLStreamWriter only, isn't that going to
> >> break code that uses the other output techniques?
> >>
> >> - Dennis
> >>
> >> Ajith Ranabahu wrote:
> >> > 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: commons-dev-unsubscribe@ws.apache.org
> >> > For additional commands, e-mail: commons-dev-help@ws.apache.org
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: commons-dev-help@ws.apache.org
> >>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
>
>
--
Ajith Ranabahu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: [Proposal][Axis2][Axiom] Adding writable capability to OM elements
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
In that case it seems like the existing OMSourceElementImpl should work
for you. That way you just need to create an OMDataSource implementation
for wrapping an ADB element, which should be very easy.
- Dennis
Ajith Ranabahu wrote:
> Hi Dennis,
> Well I was just thinking of the capability of taking in an
> XMLStreamWriter. Yes if we ignore the other methods we are likely to
> break code so it is adviceable to implement all the methods.
>
>
> On 6/17/06, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>> Hi Ajith,
>>
>> Is there a particular reason you want to only implement the
>> XMLStreamWriter output? The OMDataSource provides a choice of output
>> methods for compatibility with Axiom's supported output methods. If you
>> limit your interface to doing XMLStreamWriter only, isn't that going to
>> break code that uses the other output techniques?
>>
>> - Dennis
>>
>> Ajith Ranabahu wrote:
>> > 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: commons-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: commons-dev-help@ws.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: commons-dev-help@ws.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: [Proposal][Axis2][Axiom] Adding writable capability to OM elements
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi Dennis,
Well I was just thinking of the capability of taking in an
XMLStreamWriter. Yes if we ignore the other methods we are likely to
break code so it is adviceable to implement all the methods.
On 6/17/06, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Hi Ajith,
>
> Is there a particular reason you want to only implement the
> XMLStreamWriter output? The OMDataSource provides a choice of output
> methods for compatibility with Axiom's supported output methods. If you
> limit your interface to doing XMLStreamWriter only, isn't that going to
> break code that uses the other output techniques?
>
> - Dennis
>
> Ajith Ranabahu wrote:
> > 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: commons-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: commons-dev-help@ws.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
>
>
--
Ajith Ranabahu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: [Proposal][Axis2][Axiom] Adding writable capability to OM elements
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Hi Ajith,
Is there a particular reason you want to only implement the
XMLStreamWriter output? The OMDataSource provides a choice of output
methods for compatibility with Axiom's supported output methods. If you
limit your interface to doing XMLStreamWriter only, isn't that going to
break code that uses the other output techniques?
- Dennis
Ajith Ranabahu wrote:
> 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: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: [Proposal][Axis2][Axiom] Adding writable capability to OM elements
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Hi Ajith,
Is there a particular reason you want to only implement the
XMLStreamWriter output? The OMDataSource provides a choice of output
methods for compatibility with Axiom's supported output methods. If you
limit your interface to doing XMLStreamWriter only, isn't that going to
break code that uses the other output techniques?
- Dennis
Ajith Ranabahu wrote:
> 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: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Proposal][Axis2][Axiom] Adding writable capability to OM elements
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi Chuck,
Yep, we'll have to override both the toEnvelope and toOM methods :)
Ajith
On 6/17/06, Chuck Williams <ch...@manawiz.com> wrote:
>
> This seems like a good idea to me as it is extra work to read the events
> out of the ADBBean just to turn around and rewrite them. It's better to
> write them directly. I presume this would apply to toEnvelope() as well as
> to toOM()?
>
> Chuck
>
>
> Ajith Ranabahu wrote on 06/16/2006 02: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: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
>
> --
>
> Chuck Williams
> Manawiz
> Principal
> V: (808)885-8688
> C: (415)846-9018
> chuck@manawiz.com
> Skype: manawiz
> AIM: hawimanawiz
> Yahoo: jcwxx
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
--
Ajith Ranabahu
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Proposal][Axis2][Axiom] Adding writable capability to OM elementse
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Sanjiva Weerawarana wrote:
> On Sat, 2006-06-17 at 07:53 -0500, R J Scheuerle Jr wrote:
>
>> 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...)
>>
>
> I don't like that model .. why not say that any subclass of OMElement
> *must* be an honest-to-goodness OMElement .. which means that it MUST
> have a QName. So we can just have the constructor take that as input ..
> that way the same object can be serialized as different QNames even.
>
That's the approach I took with OMSourcedElementImpl. One side benefit
of doing things this way is that it allows data bindings to use the
equivalent of a complexType for the underlying data source, with
different element names in different places.
- Dennis
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Proposal][Axis2][Axiom] Adding writable capability to OM elementse
Posted by R J Scheuerle Jr <sc...@us.ibm.com>.
agreed +1
Rich Scheuerle
Senior Developer
IBM WebSphere Web Services Engine & Tooling
512-838-5115 (IBM TL 678-5115)
Sanjiva
Weerawarana
<sanjiva@opensour To
ce.lk> axis-dev@ws.apache.org
cc
06/17/2006 08:18
PM Subject
Re: [Proposal][Axis2][Axiom] Adding
writable capability to OM
Please respond to elementse
axis-dev@ws.apach
e.org
+1 .. as long as OMWE is a real element with a QName and all I'm
happy :).
Sanjiva.
On Sat, 2006-06-17 at 08:40 -0500, R J Scheuerle Jr wrote:
> Hi Sanjiva,
>
> Thanks for the comment.
>
> Yes, there are different cases here.
>
> Case 1) The underlying Object provides the QName.
>
> Case 2) The underlying Object does not provide the QName, The QName
> must be provided separately.
>
> Case 3) The underlying Object provides the QName, but it can be
> overriden.
>
> I agree that these cases need to be considered by the implementation
> classes of the OMObjectWrapper.
>
> ------------------
> This forces an additional methods onto the proposed OMOW.
>
> public interface OMObjectWrapper(){
>
> public XMLStreamReader getPullParser();
>
> public void writeYourSelf(XMLStreamWriter);
>
> /**
> * @return QName of the element. The QName is used to set the
> OMNamespace when the OMOWE is constructed.
> */
> public QName getQName();
>
> }
> ------------------
>
> public class OMObjectWrappingElement extends OMElement{
>
> public OMObjectWrappingElement(OMObjectWrapper wrapper){
> ...construct OMNamespace using wrapper.getQName()....
> }
>
> public void serializeWithConsume(XMLStreamWriter writer){
> wrapper.writeYourSelf(writer)
> }
>
> }
>
> ----------------
>
> Sanjiva, does this mesh with your ideas.
>
> Thanks,
>
>
> Rich Scheuerle
>
> Inactive hide details for Sanjiva Weerawarana
> <sa...@opensource.lk>Sanjiva Weerawarana <sa...@opensource.lk>
>
>
> Sanjiva Weerawarana
<sa...@opensource.lk>
>
> 06/17/2006 08:18 AM
> Please respond to
> axis-dev@ws.apache.org
>
>
> To
>
> axis-dev@ws.apache.org
>
> cc
>
>
>
> Subject
>
> Re:
> [Proposal][Axis2][Axiom] Adding writable capability to OM elementse
>
>
>
> On Sat, 2006-06-17 at 07:53 -0500, R J Scheuerle Jr wrote:
> > 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...)
>
> I don't like that model .. why not say that any subclass of OMElement
> *must* be an honest-to-goodness OMElement .. which means that it MUST
> have a QName. So we can just have the constructor take that as
> input ..
> that way the same object can be serialized as different QNames even.
>
> Sanjiva.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Proposal][Axis2][Axiom] Adding writable capability to
OM elementse
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
+1 .. as long as OMWE is a real element with a QName and all I'm
happy :).
Sanjiva.
On Sat, 2006-06-17 at 08:40 -0500, R J Scheuerle Jr wrote:
> Hi Sanjiva,
>
> Thanks for the comment.
>
> Yes, there are different cases here.
>
> Case 1) The underlying Object provides the QName.
>
> Case 2) The underlying Object does not provide the QName, The QName
> must be provided separately.
>
> Case 3) The underlying Object provides the QName, but it can be
> overriden.
>
> I agree that these cases need to be considered by the implementation
> classes of the OMObjectWrapper.
>
> ------------------
> This forces an additional methods onto the proposed OMOW.
>
> public interface OMObjectWrapper(){
>
> public XMLStreamReader getPullParser();
>
> public void writeYourSelf(XMLStreamWriter);
>
> /**
> * @return QName of the element. The QName is used to set the
> OMNamespace when the OMOWE is constructed.
> */
> public QName getQName();
>
> }
> ------------------
>
> public class OMObjectWrappingElement extends OMElement{
>
> public OMObjectWrappingElement(OMObjectWrapper wrapper){
> ...construct OMNamespace using wrapper.getQName()....
> }
>
> public void serializeWithConsume(XMLStreamWriter writer){
> wrapper.writeYourSelf(writer)
> }
>
> }
>
> ----------------
>
> Sanjiva, does this mesh with your ideas.
>
> Thanks,
>
>
> Rich Scheuerle
>
> Inactive hide details for Sanjiva Weerawarana
> <sa...@opensource.lk>Sanjiva Weerawarana <sa...@opensource.lk>
>
>
> Sanjiva Weerawarana <sa...@opensource.lk>
>
> 06/17/2006 08:18 AM
> Please respond to
> axis-dev@ws.apache.org
>
>
> To
>
> axis-dev@ws.apache.org
>
> cc
>
>
>
> Subject
>
> Re:
> [Proposal][Axis2][Axiom] Adding writable capability to OM elementse
>
>
>
> On Sat, 2006-06-17 at 07:53 -0500, R J Scheuerle Jr wrote:
> > 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...)
>
> I don't like that model .. why not say that any subclass of OMElement
> *must* be an honest-to-goodness OMElement .. which means that it MUST
> have a QName. So we can just have the constructor take that as
> input ..
> that way the same object can be serialized as different QNames even.
>
> Sanjiva.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Proposal][Axis2][Axiom] Adding writable capability to OM elementse
Posted by R J Scheuerle Jr <sc...@us.ibm.com>.
Hi Sanjiva,
Thanks for the comment.
Yes, there are different cases here.
Case 1) The underlying Object provides the QName.
Case 2) The underlying Object does not provide the QName, The QName must
be provided separately.
Case 3) The underlying Object provides the QName, but it can be overriden.
I agree that these cases need to be considered by the implementation
classes of the OMObjectWrapper.
------------------
This forces an additional methods onto the proposed OMOW.
public interface OMObjectWrapper(){
public XMLStreamReader getPullParser();
public void writeYourSelf(XMLStreamWriter);
/**
* @return QName of the element. The QName is used to set the
OMNamespace when the OMOWE is constructed.
*/
public QName getQName();
}
------------------
public class OMObjectWrappingElement extends OMElement{
public OMObjectWrappingElement(OMObjectWrapper wrapper){
...construct OMNamespace using wrapper.getQName()....
}
public void serializeWithConsume(XMLStreamWriter writer){
wrapper.writeYourSelf(writer)
}
}
----------------
Sanjiva, does this mesh with your ideas.
Thanks,
Rich Scheuerle
Sanjiva
Weerawarana
<sanjiva@opensour To
ce.lk> axis-dev@ws.apache.org
cc
06/17/2006 08:18
AM Subject
Re: [Proposal][Axis2][Axiom] Adding
writable capability to OM
Please respond to elementse
axis-dev@ws.apach
e.org
On Sat, 2006-06-17 at 07:53 -0500, R J Scheuerle Jr wrote:
> 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...)
I don't like that model .. why not say that any subclass of OMElement
*must* be an honest-to-goodness OMElement .. which means that it MUST
have a QName. So we can just have the constructor take that as input ..
that way the same object can be serialized as different QNames even.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Proposal][Axis2][Axiom] Adding writable capability to OM
elementse
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Sat, 2006-06-17 at 07:53 -0500, R J Scheuerle Jr wrote:
> 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...)
I don't like that model .. why not say that any subclass of OMElement
*must* be an honest-to-goodness OMElement .. which means that it MUST
have a QName. So we can just have the constructor take that as input ..
that way the same object can be serialized as different QNames even.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Proposal][Axis2][Axiom] Adding writable capability to OM elementse
Posted by R J Scheuerle Jr <sc...@us.ibm.com>.
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
scheu@apache.org
"Ajith Ranabahu"
<ajith.ranabahu@g
mail.com> To
axis-dev@ws.apache.org
06/17/2006 04:30 cc
AM
Subject
Re: [Proposal][Axis2][Axiom] Adding
Please respond to writable capability to OM elements
axis-dev@ws.apach
e.org
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" <aj...@gmail.com>
"Ajith Ranabahu" < ajith.ranabahu@gmail.com>
"Ajith
Ranabahu" <
ajith.ranab
ahu@gmail.c
om> To
"Axis developer list" <
06/16/2006 axis-dev@ws.apache.org>,
07:37 AM commons-dev@ws.apache.org
cc
Please respond to
axis-dev@ws.apache.org
Subject
[Proposal][Axis2][Axiom]
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
--
Ajith Ranabahu
Re: [Proposal][Axis2][Axiom] Adding writable capability to OM elements
Posted by Ajith Ranabahu <aj...@gmail.com>.
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)
> [image: Inactive hide details for "Ajith Ranabahu"
> <aj...@gmail.com>]"Ajith Ranabahu" <aj...@gmail.com>
>
>
>
> *"Ajith Ranabahu" <aj...@gmail.com>*
>
> 06/16/2006 07:37 AM Please respond to
> axis-dev@ws.apache.org
>
>
> To
>
> "Axis developer list" <ax...@ws.apache.org>, commons-dev@ws.apache.org
> cc
>
>
> Subject
>
> [Proposal][Axis2][Axiom] 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: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
>
>
--
Ajith Ranabahu
Re: [Proposal][Axis2][Axiom] Adding writable capability to OM elements
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi Paul,
I'm not really sure what you meant by a typed axiom. Did you mean to
generate special OMElements that encapsualte integer (and other type)
content directly ?
Ajith
On 6/17/06, Paul Fremantle <pz...@gmail.com> wrote:
>
> How about doing Typed STAX and a Typed AXIOM?
>
> Its possible that the "Special OMElement" could be used to do this.
> Basically I want to be able to avoid the cost of converting from
> bytes->char->int and just do byte->int. Once we get a decent binary
> serialization of XML this will improve further, because we could go
> encoded-int->int.
>
> Paul
>
>
> On 6/16/06, R J Scheuerle Jr <sc...@us.ibm.com> wrote:
> >
> > Ajith,
> >
> > Sounces like a great idea. I have some questions.
> >
> > 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.
> >
> >
> > -----------------------------------------
> > 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 ?
> >
> > -----------------------------------------
> >
> > 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 ?
> >
> > -----------------------------------------
> >
> > Thanks,
> >
> >
> > Rich Scheuerle
> > Senior Developer
> > IBM WebSphere Web Services Engine & Tooling
> > 512-838-5115 (IBM TL 678-5115)
> > [image: Inactive hide details for "Ajith Ranabahu"
> > <aj...@gmail.com>]"Ajith Ranabahu" < ajith.ranabahu@gmail.com>
> >
> >
> >
> > *"Ajith Ranabahu" <aj...@gmail.com>*
> >
> > 06/16/2006 07:37 AM Please respond to
> > axis-dev@ws.apache.org
> >
> >
> > To
> >
> > "Axis developer list" <ax...@ws.apache.org>,
> > commons-dev@ws.apache.org
> > cc
> >
> >
> > Subject
> >
> > [Proposal][Axis2][Axiom] 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: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
> >
> >
>
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
--
Ajith Ranabahu
Re: [Proposal][Axis2][Axiom] Adding writable capability to OM elements
Posted by Paul Fremantle <pz...@gmail.com>.
How about doing Typed STAX and a Typed AXIOM?
Its possible that the "Special OMElement" could be used to do this.
Basically I want to be able to avoid the cost of converting from
bytes->char->int and just do byte->int. Once we get a decent binary
serialization of XML this will improve further, because we could go
encoded-int->int.
Paul
On 6/16/06, R J Scheuerle Jr <sc...@us.ibm.com> wrote:
>
> Ajith,
>
> Sounces like a great idea. I have some questions.
>
> 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.
>
>
> -----------------------------------------
> 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 ?
>
> -----------------------------------------
>
> 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 ?
>
> -----------------------------------------
>
> Thanks,
>
>
> Rich Scheuerle
> Senior Developer
> IBM WebSphere Web Services Engine & Tooling
> 512-838-5115 (IBM TL 678-5115)
> [image: Inactive hide details for "Ajith Ranabahu"
> <aj...@gmail.com>]"Ajith Ranabahu" <aj...@gmail.com>
>
>
>
> *"Ajith Ranabahu" <aj...@gmail.com>*
>
> 06/16/2006 07:37 AM Please respond to
> axis-dev@ws.apache.org
>
>
> To
>
> "Axis developer list" <ax...@ws.apache.org>, commons-dev@ws.apache.org
> cc
>
>
> Subject
>
> [Proposal][Axis2][Axiom] 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: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
Re: [Proposal][Axis2][Axiom] Adding writable capability to OM elements
Posted by Eran Chinthaka <ch...@opensource.lk>.
Ajith Ranabahu wrote:
> Hi,
> 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
>
>
> }
> }
Ok, if its a question of where we keep the new OMElement, then either
way is fine with me.
Your initial post some how made me think that you are trying to put a
ADB dependency on Axiom :).
-- Chinthaka
Re: [Proposal][Axis2][Axiom] Adding writable capability to OM elements
Posted by Ajith Ranabahu <aj...@gmail.com>.
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Proposal][Axis2][Axiom] Adding writable capability to OM elements
Posted by R J Scheuerle Jr <sc...@us.ibm.com>.
+1 to Eran's comments.
Question 1: Will there be a factory for creating the
"OMObjectWrappingElement" for a particular OM implemenatation ?
Question 2: (Restating my question from an earlier post) When you insert
an OMOWE into a tree, what is the defined behavior when it is touched ?
Is this the behavior:
i) The OMOWE is a child of a normal parent OMElement. A consumer invokes
an method (i..e "get child") on the parent.
ii) The OM implementation detaches the "OMOWE" 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
OMOWE
Great work, I would like to see more posts
Rich Scheuerle
Senior Developer
IBM WebSphere Web Services Engine & Tooling
512-838-5115 (IBM TL 678-5115)
Eran Chinthaka
<chinthaka@openso
urce.lk> To
axis-dev@ws.apache.org
06/17/2006 02:57 cc
AM
Subject
Re: [Proposal][Axis2][Axiom] Adding
Please respond to writable capability to OM elements
axis-dev@ws.apach
e.org
Ajith,
I'd like to suggest a small change for your proposal.
> 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.
OMDataSource having dependency on ADBBean? I think u didn't mean it :).
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.
(See attached file: signature.asc)
Re: [Proposal][Axis2][Axiom] Adding writable capability to OM elements
Posted by Eran Chinthaka <ch...@opensource.lk>.
Ajith,
I'd like to suggest a small change for your proposal.
> 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.
OMDataSource having dependency on ADBBean? I think u didn't mean it :).
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.
Re: [Proposal][Axis2][Axiom] Adding writable capability to OM elements
Posted by R J Scheuerle Jr <sc...@us.ibm.com>.
Ajith,
Sounces like a great idea. I have some questions.
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.
-----------------------------------------
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 ?
-----------------------------------------
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 ?
-----------------------------------------
Thanks,
Rich Scheuerle
Senior Developer
IBM WebSphere Web Services Engine & Tooling
512-838-5115 (IBM TL 678-5115)
"Ajith Ranabahu"
<ajith.ranabahu@g
mail.com> To
"Axis developer list"
06/16/2006 07:37 <ax...@ws.apache.org>,
AM commons-dev@ws.apache.org
cc
Please respond to Subject
axis-dev@ws.apach [Proposal][Axis2][Axiom] Adding
e.org 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[Proposal][Axis2][Axiom] Adding writable capability to OM elements
Posted by Ajith Ranabahu <aj...@gmail.com>.
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: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
[Proposal][Axis2][Axiom] Adding writable capability to OM elements
Posted by Ajith Ranabahu <aj...@gmail.com>.
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org