Return-Path: Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 53241 invoked by uid 500); 25 Mar 2003 13:29:42 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 53232 invoked from network); 25 Mar 2003 13:29:41 -0000 Message-ID: From: "Olejarz, Greg" To: "'axis-dev@ws.apache.org'" Subject: RE: SAAJ and implementation Date: Tue, 25 Mar 2003 08:28:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F2D2.7211D360" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2F2D2.7211D360 Content-Type: text/plain; charset="iso-8859-1" Check out http://jcp.org/aboutJava/communityprocess/maintenance/jsr067/ which describes the maintenance update to jaxm and saaj. The update includes dom stuff, I did not however check if the axis signatures match the new saaj ones. Greg -----Original Message----- From: Nick Laqua [mailto:Nick.Laqua@newtron.net] Sent: Tuesday, March 25, 2003 5:46 AM To: axis-user@xml.apache.org; axis-dev@xml.apache.org Subject: SAAJ and implementation Hi all, we are implementing our own integration tool which also contains a SOAP layer for packaging arbitrary messages (no rpc style). The SOAP shall be encapsulated and knows nothing about the payload within SOAP Body. During our search we came across SAAJ and the reference implementation by SUN which seems to address exactly this topic. Unfortunately, we found no way to add whole xml parts to the SOAP body (for instance by supplying a org.w3c.dom.Element or an InputStream). It seems that the reference implementation by SUN and the SAAJ api requires one to construct the payload element by element. When looking at the axis examples and the axis source code, we found out that you have your own SOAPBodyElement implementation (org.apache.axis.message.SOAPBodyElement) which implements the standard interface (javax.xml.soap.SOAPBodyElement) but additionally it contains exactly those methods we desperately need (construction using InputStream or org.w3c.dom.Element). So probably we will use Axis for this part, referencing your implementation directly. But in the long run, this undermines the whole idea of standard interfaces doesn't it ? I would be interested to hear what were your opinions and reasons for extending the "standard" and if you expect SAAJ to be extended in this way one day. Cheers, Nick "Bringing people together to advance their lives." NOTICE: The information contained in this electronic mail transmission is intended by TMP Interactive Inc. d/b/a Monster or one of its subsidiaries for the use of the named individual or entity to which it is addressed and may contain information that is privileged or otherwise confidential. It is not intended for transmission to, or receipt by, any individual or entity other than the named addressee (or a person authorized to deliver it to the named addressee) except as otherwise expressly permitted in this electronic mail transmission. If you have received this electronic transmission in error, please delete it without copying or forwarding it, and notify the sender of the error by reply email or by calling Monster at 1-800-MONSTER. ------_=_NextPart_001_01C2F2D2.7211D360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: SAAJ and implementation

Check out

http://jcp.org/aboutJava/communityprocess/maintenance/= jsr067/

which describes the maintenance update to jaxm and = saaj. The
update includes dom stuff, I did not however check = if the
axis signatures match the new saaj ones.

Greg

-----Original Message-----
From: Nick Laqua [mailto:Nick.Laqua@newtron.net= ]
Sent: Tuesday, March 25, 2003 5:46 AM
To: axis-user@xml.apache.org; = axis-dev@xml.apache.org
Subject: SAAJ and implementation


Hi all,

we are implementing our own integration tool which = also contains a SOAP layer for packaging arbitrary messages (no rpc = style). The SOAP shall be encapsulated and knows nothing about the = payload within SOAP Body.

During our search we came across SAAJ and the = reference implementation by SUN which seems to address exactly this = topic. Unfortunately, we found no way to add whole xml parts to the = SOAP body (for instance by supplying a org.w3c.dom.Element or an = InputStream). It seems that the reference implementation by SUN and the = SAAJ api requires one to construct the payload element by = element.

When looking at the axis examples and the axis source = code, we found out that you have your own SOAPBodyElement = implementation (org.apache.axis.message.SOAPBodyElement) which = implements the standard interface (javax.xml.soap.SOAPBodyElement) but = additionally it contains exactly those methods we desperately need = (construction using InputStream or org.w3c.dom.Element).

So probably we will use Axis for this part, = referencing your implementation directly. But in the long run, this = undermines the whole idea of standard interfaces doesn't it = ?

I would be interested to hear what were your opinions = and reasons for extending the "standard" and if you expect = SAAJ to be extended in this way one day.

Cheers,

Nick


"Bringing people together to advance their = lives."=20

NOTICE: The information contained in this electronic = mail transmission is intended by TMP Interactive Inc. d/b/a Monster or = one of its subsidiaries for the use of the named individual or entity = to which it is addressed and may contain information that is privileged = or otherwise confidential.  It is not intended for transmission = to, or receipt by, any individual or entity other than the named = addressee (or a person authorized to deliver it to the named addressee) = except as otherwise expressly permitted in this electronic mail = transmission. If you have received this electronic transmission in = error, please delete it without copying or forwarding it, and notify = the sender of the error by reply email or by calling Monster at = 1-800-MONSTER.

------_=_NextPart_001_01C2F2D2.7211D360--