axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eran Chinthaka" <chinth...@opensource.lk>
Subject RE: [Axis2] Integrating Complete XML infoset support
Date Fri, 24 Jun 2005 11:12:00 GMT
+1.

Sorry I'm bit late to express my ideas. Anyway, this seems fine.

Chinthaka. 

PS : "OM'ers" sounds bit weird :)

> -----Original Message-----
> From: Venkat Reddy [mailto:vreddyp@gmail.com]
> Sent: Friday, June 24, 2005 4:55 PM
> To: axis-dev@ws.apache.org
> Subject: Re: [Axis2] Integrating Complete XML infoset support
> 
> If no more objections are raised, lets conclude the discussion with
> following decisions:
> 
> 1. Shift Child API from OMElement to OMContainer.
> 2. OMElement extends OMContainer
> 3. OMDocument implements OMContainer
> 4. Resolve Axis2 - 22 after these changes are made.
> 
> OM'ers, if this is OK with you, Jaya will go ahead and make the
> changes, and close the task of integrating Infoset support.
> 
> - venkat
> 
> 
> On 6/24/05, Venkat Reddy <vreddyp@gmail.com> wrote:
> > hmm... my assumption is that OMElementImpl will implement both
> > OMContainer and OMElement, but not OMElement extending OMContainer. If
> > OMElement extends OMContainer, then it is OK - no problem.
> >
> > On 6/24/05, Venkat Reddy <vreddyp@gmail.com> wrote:
> > > For example, userguide.clients.ClientUtil.getEchoOMElement() uses the
> > > following syntax to build the message.
> > >         OMFactory fac = OMAbstractFactory.getOMFactory();
> > >         OMNamespace omNs =
> > > fac.createOMNamespace("http://example1.org/example1", "example1");
> > >         OMElement method = fac.createOMElement("echo", omNs);
> > >         OMElement value = fac.createOMElement("Text", omNs);
> > >         value.addChild(fac.createText(value, "Axis2 Echo String "));
> > >         method.addChild(value);
> > >
> > > If the addChild method is moved from OMElement to OMContainer, this
> > > syntax doesn't work. OMContainer will replace OMElement all over the
> > > client programming. The other not-so-good alternative is to typecast
> > > OMElement to OMElementImpl and then call addChild, because
> > > OMElementImpl implements OMContainer.
> > >
> > > - venkat
> > >
> > >
> > >
> > > On 6/24/05, Sanjiva Weerawarana <sanjiva@opensource.lk> wrote:
> > > > On Fri, 2005-06-24 at 13:03 +0530, Venkat Reddy wrote:
> > > > > Alek,
> > > > >
> > > > > Like i said in the earlier thread on the same subject, there are
> > > > > couple of issues if we move the child API from OMElement to a
> seperate
> > > > > interface. The excerpt from my old mail:
> > > > >
> > > > > "The client API currently uses OMElement.addChild() to build the
> > > > > message. Even if
> > > > > we try to use setParent() instead of addChild() here, the user has
> to
> > > > > typecast the OMElement into OMElementImpl and pass it to
> setParent,
> > > > > which is not elegant."
> > > > >
> > > > > Do have any ideas to resolve this? Until we get new ideas, here is
> my
> > > > > +1 for OMDocument extends OMElement.
> > > >
> > > > Maybe I didn't understand it (I didn't follow the previous thread
> > > > carefully) but if there's an OmContainer interface containing
> > > > addChild(), getChild() etc. etc., then if
> > > >         interface OmElement extends OmContainer
> > > >         interface OmDocument extends OmContainer
> > > > etc. then I'm not clear why one needs to do a cast. Can you expand
> > > > please Venkat?
> > > >
> > > > Sanjiva.
> > > >
> > > >
> > > >
> > >
> >




Mime
View raw message