axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jayachandra <jayachan...@gmail.com>
Subject Re: [Axis2] Integrating Complete XML infoset support
Date Mon, 27 Jun 2005 13:25:23 GMT
Guys!
I'll take care of reflecting these changes. I'm more than half way.
I'm posting this just to ensure others won't waste their time redoing
the same.

Jaya

On 6/24/05, Eran Chinthaka <chinthaka@opensource.lk> wrote:
> +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.
> > > > >
> > > > >
> > > > >
> > > >
> > >
> 
> 
> 
> 


-- 
-- Jaya

Mime
View raw message