Why not support for public Element [] bodyAsDOMMethod(Element [] bodies)
also:
signatures:
org.w3c.dom.Document bodyAsDOMMethod(org.w3c.dom.Document
bodyElmementsInDocument) //root element namesp:name match SOAPBody
org.w3c.dom.Element bodyAsDOMMethod(org.w3c.dom.Element
rootElementContainingBodyElements) //ditto
IMO these are closer to handling messages as document oriented.
Rick Rineholt
"The truth is out there... All you need is a better search engine!"
[EMAIL PROTECTED]
Glen Daniels <[EMAIL PROTECTED]> on 09/23/2002 03:14:47 PM
Please respond to [EMAIL PROTECTED]
To: "'Axis-Dev (E-mail)'" <[EMAIL PROTECTED]>
cc: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
Subject: Message style services - ATTN ANY java:MSG USERS
OK, I have dispatch to multiple methods in message-style services working
in my sandbox. This has the added bonus of speeding up message-based
services because we now avoid introspection on every call - the initial
introspection in ServiceDesc now understands what type of message method
(Vector, Document, etc) we have so the MsgProvider can use that cached
info.
While we're in there, I'd suggest rationalizing the APIs for message based
backends, as discussed in
http://marc.theaimsgroup.com/?l=axis-dev&m=101853538321442&w=2.
(incidentally I think it's funny that I was set to do exactly this work
back in April - the dispatch stuff now works pretty much exactly as in that
message)
I'd like to make THESE THREE the accepted APIs for message-style service
methods:
public class MessageService {
public SOAPBodyElement [] bodyMethod(SOAPBodyElement [] bodies)
public SOAPEnvelope envelopeMethod(SOAPEnvelope envelope)
public Element [] bodyAsDOMMethod(Element [] bodies)
}
I think these make a lot more sense than what we've got now.
IF THIS WILL AFFECT YOU IN A NEGATIVE WAY, or IF YOU DISAGREE WITH THESE
CHANGES, please send mail to axis-dev in reply to this message.
Thanks!
--Glen
