--- jayachandra <[EMAIL PROTECTED]> wrote:
> element.detach() removes element info item also
> along with all its
> children, isn't it?
Yes, it simply detaches the element from the tree.
However, you could detach the child you want. This
would keep the parent intact;-)
OM is based on the DOM co
Hi Alek,
have a look at
https://svn.apache.org/repos/asf/webservices/axis/trunk/archive/java/scratch/dasarath/om/$1/summary.html
Sorry for the messup with the tabs!
--Dasarath
--- Aleksander Slominski <[EMAIL PROTECTED]> wrote:
> Dasarath Weeratunge wrote:
>
> >If you are
Hi,
Im interested in finding out what people are
expecting from axis2 when it comes to data binding.
Until yesterday I was thinking (this may sound naive)
that we would select a particular data-binding tool at
the time we generate code and then thats it
the
generated code would be tightly coupl
legacy system at this point with
time/cost/performance trade offs. Instead, we simply
want to select the best possible organization for OM.
--Dasarath
> Dasarath Weeratunge wrote:
>
> >Hi Alek,
> >
> >have a look at
>
>https://svn.apache.org/repos/asf/webservices/axis/tr
At the axis2 summit, the messaging based core
discussion ultimately boiled down to renaming several
entities.
People agreed to have a MessageSender with
send(MessageContext mc) method and a MessageReceiver
with a receive(MessageContext mc) method. One
important difference between the MessageSender
Further, even thought we are using StAX at the moment
the goal of axis2 team is to move to tStAX as soon as
possible. tStAX is a typed-StAX API which allows us to
directly convert contents of the underlying byte
stream into relevant types without having to first
convert into strings.
--dasarath
--- Aleksander Slominski <[EMAIL PROTECTED]> wrote:
> Venkat Reddy wrote:
>
> >However, the case of round-trip performance
> includes time spent by the
> >service provider in preparing response, which might
> need to parse the
> >body content.
> >
> but it may not need it for example if it is
>
this is a mistake...
--dasarath
--- Venkat Reddy <[EMAIL PROTECTED]> wrote:
> >
>
http://ws.apache.org/axis2/api/org/apache/axis/om/impl/llom/OMTextImpl.html
>
> btw, it looks like OMTextImpl already has
> setFirstChild and
> getFirstChild methods!! may be the remains of last
> refactoring?
>
Hi jayachandra,
we are looking for some test cases to test one of our
pull parsers at LSF. What does your test cases contain
in terms of different encoding types? Our parser is
targeted for axis-c.
--dasarath
--- jayachandra <[EMAIL PROTECTED]> wrote:
> Sorry!
> Just now found a solution on the
Two things:
1. Data binding needs to be layered on top of OM
and not incorporated into it.
2. External data-binding tools should be pluggable
into our data binding framework.
So I propose that we go for the following:
package org.apache.axis.om.xmlbinding.*
interface OMXBContext {
O
required while being visible
to the required scope, everything should be OK.
thanks
--dasarath
> Thank you
> Jayachandra
>
> On 5/12/05, Dasarath Weeratunge
> <[EMAIL PROTECTED]> wrote:
> > Two things:
> > 1. Data binding needs to be layered on top of OM
>
as <[EMAIL PROTECTED]>
> wrote:
> > Dasarath,
> >
> > don't worry about the size right now...get it
> working and then we can
> > ask xmlbeans folks to get us a jar of what we
> want.
> >
> > -- dims
> >
> > On 5/12/05, Dasarath
--- Ruchith Fernando <[EMAIL PROTECTED]>
wrote:
> Hi All,
>
> In implementing WS-Security capabilities on Axis 2.0
> we will have to
> convert the OM to DOM and provide the complete
> SOAPEnvelope as a DOM
> implementation.
> The following changes and additions are proposed to
> the OM
> implemen
do we really need this method? I'd rather keep a
simple API. +1 for changing the name if we are going
to keep it.
--dasarath
--- jayachandra <[EMAIL PROTECTED]> wrote:
> Hi Eran!
> I predicted this reply :-)
> Then, at least the names should be changed.
> Otherwise
> readability&usability of cod
Since most likely OM will be built through generated
code, I'm wondering why this method is required.
--dasarath
--- Eran Chinthaka <[EMAIL PROTECTED]> wrote:
> Hi Jaya and all,
>
> I still find difficult to give you a method to
> remove namespaces.
>
> Namespaces, once defined in an element,
I recall having a discussion on this very matter with
Chanthaka.
Using arrays definitely provides an edge over linked
lists when it comes to random access but the question
does handler's or the provider ever need to query OM
by requesting "give me the 5th header..." "give me the
6th header like..
Ppl pls have a look at the performance test results
under:
https://svn.apache.org/repos/asf/webservices/axis/trunk/java/dev/scratch/dasarath/om/$1/
--Dasarath
--- Aleksander Slominski <[EMAIL PROTECTED]> wrote:
> Eran Chinthaka wrote:
>
> >>>start with no collection and allocate collection
+1 release
IMO there won't be
http://ws.apache.org/axis/2.1 OR
http://ws.apache.org/axis/2.2 ... etc.
so
0- for option 2
and
+1 for option 3
http://ws.apache.org/axis/2
--Dasarath
--- Srinath Perera <[EMAIL PROTECTED]> wrote:
> Hi All.
>
>
> The source for Axis2 is now stable enough to be
>
Dear Shawn Dahlen,
Thanks a lot for your input. Since your concerns are
at a very fundamental level why not put them into a
diagram? That way it would be a lot easier to
understand and discuss. Just try to explain with
arrows and boxes how the engine should work IYO. A
small engine toy would be ni
Hi Ananth
> this info anywhere - I am aware that Axis 2 has MTOM
> as one of the
> requirements and I presume it isn't still
> implemented. '
Yes its in progress. Thilina is doing that.
> Does it still
> support Swa with MIME though ?
Axis 2 will only support MTOM.
> Also, does the
> current
--- Aleksander Slominski <[EMAIL PROTECTED]> wrote:
hi,
> as i was asked to send it during irc chat but before
> Attachments Technologies (Canyang Kevin Liu and
> Sanjay Patil)
>
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/documents/a1-8-4/Evolution%20of%20Web%20Serv
--- Eran Chinthaka <[EMAIL PROTECTED]> wrote:
>
> Hi Alek, Dasarath,
>
>
> +1. But I know about HTTP case. How about other
> transports like SMTP, TCP,
> etc., ?? Can we identify this in other transports as
> well.
> >
SMTP is clearly out for optimized content since it is
text only. U cannot
FYI:
The way XMLStreamReader is implemented in OM and
XMLBeans is different. When you call
newXMLStreamReader on an XMLBeans generated class, the
returned reader is positioned on the element: if u
call next u get the local name. However, when you call
getPullParser on an OMElement you must call ne
Shall we refactor getPullParser method as
newXMLStreamReader?
--Dasarath
__
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
--- Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
> Defer until F2F discussion on the right arch for
> MTOM support?
> The last time we had the discussion on the list IIRC
> there were
> multiple proposals .. but now we have at least one
> concrete
> realization.
>
> In any case, seems to me we
ook into this. Also mention
about the state of interop testing.
--Dasarath
> the wiki. Then If at least few feel we are well
> placed with MTOM let
> us try a VOTE.
>
> Thanks
> Srinath
>
>
>
> On Tue, 15 Mar 2005 19:27:25 -0800 (PST), Dasarath
> Weeratunge
> &l
--- Eran Chinthaka <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> See my comments below.
>
> >
> > Hi all,
> > I am definitley +1 for having Thilina as a
> commiter. He has done good
> > code and I have no doubt that he is the guy to
> MTOMize OM.
> > However I am still 0- on integrating the code t
> detail and then do it. Since MTOM is a major turn,
> my guess is we
Why do u say that MTOM is a major turn? We are not
turning anything around? Its yet another simple add on
and will not affect other aspects of OM.
--Dasarath
> should do this patiently, rather than in a hurry.
>
>
>
> On W
+1
--Dasarath
--- Aleksander Slominski <[EMAIL PROTECTED]> wrote:
> Chathura Herath wrote:
>
> >Here is my +1 for Thilina's committership proposal.
> >
> >
> +1
>
> alek
>
> >I am with the idea that we should go ahead and
> MTOMize the OM if we have the
> >right impl. Thilina's Architecture
--- Eran Chinthaka <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> This will some relate to the thread "Doubt on Detail
> Element in SOAPFault".
>
> AXIOM was not meant to check the compliance with
> SOAP spec or anything else.
> It will just hold the infoset. The reason behind me
> putting a SAAJ lik
If you are in doubt about how much recent
architectural changes may have affected (or killed) OM
performance please look at the following test results:
https://svn.apache.org/repos/asf/webservices/axis/trunk/archive/java/scratch/dasarath/om/$1/
--Dasarath
--- Eran Chinthaka <[EMAIL PROTECTED]> w
--- Ajith Ranabahu <[EMAIL PROTECTED]> wrote:
> Hi there,
> Just as Chinthaka was saying OMAttribute was a child
> of the OMNode
> (OMNamedNode to be exact). However this was changed
> later with the
> immutable attribute concept (Samething that happened
> to OMNamespace).
> Since the removal of t
32 matches
Mail list logo
