Aleksander Slominski wrote:
Dennis Sosnoski wrote:
Long term it's clear that real data binding support needs to be
integrated into the SOAP framework
do you know if anybody tried to add support for XmlBeans
(http://xml.apache.org/xmlbeans/) to AXIS?
we have XmlBeans integrated in
Dennis Sosnoski wrote:
This is great to hear about, but information on WS/XSUL looks scarce
(I found your slide set - or is that slajd set?).
woes of trying to do power point to html conversion ... (BTW slajd is
in Polish for slide :) )
Can you point me at anything that's usable?
WS/XSUL
Aleksander Slominski wrote:
Dennis Sosnoski wrote:
I've got my own lightweight SOAP framework built around JiBX. I'll try
to get something out about that, probably adding it as a subproject in
conjunction with the beta 3a release next week, so that people who are
interested in a decoupled
I favor the approach this suggests:
Make the SOAP stack an XML delivery and minimal SOAP processing engine
and leave XML-Java type translation to another layer. Chose Castor,
XmlBeans, JAXB 1.0, 2.0 whatever. The choice is dictated by how I want
to work witht he XML recognizing that the XML is
To: [EMAIL PROTECTED]
Subject: Re: XmlBeans and Axis? [Re: Doc/Literal support in axis
I favor the approach this suggests:
Make the SOAP stack an XML delivery and minimal SOAP processing engine
and leave XML-Java type translation to another layer. Chose Castor,
XmlBeans, JAXB 1.0, 2.0 whatever
is of secondary importance IMHO ...
best,
alek
-Original Message-
From: Jim Murphy [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 17, 2004 2:21 PM
To: [EMAIL PROTECTED]
Subject: Re: XmlBeans and Axis? [Re: Doc/Literal support in axis
I favor the approach this suggests:
Make the SOAP stack
Anderson Jonathan wrote:
The problems is that intermediary nodes can change the content of the SOAP
envelope, plain and simple. This really complicates that SOAP XML data
binding issue. Intermediary node implementations need access to the SOAP
header information at the very least... any type of
Jim Murphy wrote:
I don't get why this is a problem. Say I have a handler that wants to
transform a request in some way (decrypt, remove a Header whatever).
Isn't that just consuming one stream and producing another? If it wants
to consume one stream map that to Java using some
Anderson Jonathan wrote:
Jim Murphy wrote:
Why wouldn't a very thin Axis working with several Java
binding/marshaling layers be a compelling approach?
Problem is, I have yet to see a SOAP stack that works this way. Consuming
one stream and producing another implies that each intermediary
