Thomas,
the prev email was directed to Ias :)
-- dims
On Sun, 6 Jun 2004 21:36:05 -0500, Thomas Diesler
<thomas.diesler@jboss.org> wrote:
>
>
> Its probably no use to you, because I work based on axis-1.1, layout the code, and refactored
all classes from SOAPWhatever to SOAPWhateverImpl
> so I can actually see when I'm using a saaj interface/class and when an axis implemenation.
>
> My current approach to invalidate the cache in MessagePart is to simply fall through
to string serialization,
> but I also need to make sure that the SAX event cache in SOAPElementImpl is not used
for playback.
>
> That gets me 3 failures and 5 errors in the unit tests which I will look at tomorrow.
Here in Munich its 4:22am
> and altough I don't expect much sleep this month, I should go to bed now.
>
> cheers
> -thomas
>
>
>
> > -----Original Message-----
> > From: Davanum Srinivas [mailto:davanum@gmail.com]
> > Sent: 07 June, 2004 03:45
> > To: axis-dev@ws.apache.org
> > Subject: Re: Using SAAJ-1.2 API to modify the soap header/body content
> >
> > Ias,
> >
> > I was thinking about this today....Can you please send me the
> > diff's (and the new files)? Let me take a look at them.
> >
> > thanks,
> > dims
> >
> > On Sun, 6 Jun 2004 14:46:51 +0900, Ias <iasandcb@tmax.co.kr> wrote:
> > >
> > > Hi Thomas,
> > >
> > > Thanks for your pointing the issues out. As a contributor
> > of the SAAJ
> > > 1.2 implementation in Axis (with Dr. Ahn), I have to admit
> > that he and
> > > I already made our own (refactored) Axis satisfy #1 and #2.
> > He created
> > > DOM recorder for #1 and I refactored the whole
> > org.apache.axis.message
> > > package for #2. As for #2, org.apache.axis.message.Node was created
> > > and org.apache.axis.message.MessageElement and
> > > org.apache.axis.message.Text extended it.
> > >
> > > However, those changes are quite big and wide, so we need to modify
> > > Axis a lot. Now we are in the middle of finalizing Axis
> > 1.2, I don't
> > > think such large changes will happen to this upcoming
> > version of Axis.
> > > Personally, I often have felt that contributing #1 and #2 to the
> > > current Axis base seems pretty difficult and consider
> > re-structuring
> > > the SAAJ part with Axis NG (Next Generation).
> > >
> > > What I'm designing regarding Axis NG is a complete
> > implementation of
> > > JAX-RPC 2.0 and Web Services Metadata for high performance
> > with StAX
> > > (streaming parser). I'm planning to open my thoughts on
> > that as soon
> > > as JAX-RPC 2.0 and JAXB 2.0 early drafts are unveiled
> > around JavaOne
> > > 2004. Briefly, I'd like Axis NG to use StAX when
> > > deserializing/serializing between SOAP messages and SAAJ
> > instances. In
> > > addition, Axis NG will use JAXB 2.0 to unmarshal/marshal
> > between XMLs
> > > and Java instances with StAX. JDK 1.5's metadata enables users to
> > > develope web services just like JSPs with WSM and generate portable
> > > artifacts for web services (both client and server) runtime
> > from an annotated seed class.
> > >
> > > I'd like to hear your opinions about Axis' future, in
> > particular, 1.3
> > > and NG even though it's a little early. :-)
> > >
> > > Regards,
> > >
> > > Ias
> > >
> > > ________________________________
> > >
> > > From: Thomas Diesler [mailto:thomas.diesler@jboss.org]
> > > Sent: Sunday, June 06, 2004 1:22 AM
> > > To: axis-dev@ws.apache.org
> > > Subject: Using SAAJ-1.2 API to modify the soap header/body
> > > content
> > >
> > >
> > >
> > >
> > > Hi Axis Dev,
> > >
> > > I am working on a J2EE-1.4 compliant implementation for web
> > > services
> > > (WS4EE) in JBoss based on Axis. As you might know, JBoss has been
> > > using Axis in its jboss.net module for quite some time. We are
> > > starting a new project called jboss-ws4ee that we would
> > like to use in
> > > our J2EE-1.4 certified release.
> > >
> > > I'm wondering if you could help me with these issues
> > >
> > > #1 SAX recorded events
> > >
> > > Axis uses a Serializer/Deserialiser based on
> > SAX events.
> > > The recorded events are stored with the SOAPElement.
> > > On serialization the SOAPElement will simply
> > playback the
> > > events if the element is not marked dirty.
> > >
> > > A JAXRPC handler is allowed to view and modify soap
> > > headers and body. For that it can use the saaj api or even
> > the dom api
> > > on javax.xml.soap.Node objects.
> > >
> > > When a client makes these modifications, they are not
> > > reflected in the axis internal representation of the soap message.
> > > This is especially true for RPCElement, which keeps an
> > > internal list of RPCParam objects, which are not linked to
> > SOAPElement.
> > >
> > > #2 General soap tree representation
> > >
> > > Axis is missing the notion of
> > javax.xml.soap.Node, instead
> > > it models javax.xml.soap.Text as javax.xml.soap.SOAPElement.
> > > I'm having a hard time trying to keep all the various
> > > SOAPElement representations in sync. For jboss-ws4ee I started a
> > > refactoring effort that would base SOAPElementImpl on
> > > NodeImpl which implements the org.w3c.dom.Node interface.
> > >
> > > All information about namespaces, attributes,
> > parent/child
> > > relationships should be taken from the dom tree.
> > > Serialization/Deserialization would be based on the dom
> > > tree as well.
> > >
> > > Any suggestions?
> > >
> > > cheers
> > > -thomas
> > >
> > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > > Thomas Diesler
> > > Senior Developer & Consultant
> > > JBoss Group (Europe) SàRL
> > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > >
> > >
> >
> >
>
|