Added a bugzilla entry and included a sample which can be made into a
testcase once the bug is fixed.
-Dug
Davanum Srinivas <[EMAIL PROTECTED]> on 09/23/2002 11:27:46 AM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: RE: Only one operation if Msg style?
Rick,
IF you really, really want existing functionality to persist, THEN you need
to add a test case for
it....Sometimes, it is an unintentional change that breaks a use case.
Thanks,
dims
--- Rick Rineholt <[EMAIL PROTECTED]> wrote:
>
>
> So Axis lost existing functionality and pushed the burden of to obtain it
> on the end user so "ServiceDesc-based introspection code easier to deal
> with" ???
> And when will we have figured out "what kind of support we really want to
> do" and do that"??? Release 2? , Release 3, or will be later than that
so
> I can once again re-adjust all of my Axis based infrastructure. Or will
it
> be when I can grep through Axis and not see any more "FIXME" , "whaddya
> think" and
> TODO's ??? Or more than likely with every release!!!!
>
> Yes I can write my own dispatching but then why not just open a socket
> parse and generate my own XML and just skip just the burden that
someone
> trying to develope something on top of Axis has to deal with...
>
> This was an known change to the end user interface and if not done out
> proper protocol SHOULD have been something commiters voted on and at the
> very least out of courtesy to the end user commutiy a note on the
mailing
> list with a subject line that indicate that it might break existing
code.
>
>
> Release 1, or Alpha 1?
> *************************
> org\apache\axis\MessageContext.java: * Whaddya think? - todo by Jacek)
> org\apache\axis\transport\http\HTTPConstants.java: * whaddya think?
-
> todo by Jacek)
> org\apache\axis\attachments\AttachmentPart.java: * TODO: Am not sure
> about the logic.
> org\apache\axis\attachments\ManagedMemoryDataSource.java: * TODO TODO
TODO
> need to delete cached out data sources after a service ends.
> org\apache\axis\attachments\MimeUtils.java: // TODO (dims):
Commons
> HttpClient croaks if we don't do this.
> org\apache\axis\description\ServiceDesc.java: * TODO: Make this more
> efficient
> org\apache\axis\encoding\DeserializationContextImpl.java: * TODO:
> This code doesn't yet work, but we aren't looking up the right
> org\apache\axis\encoding\ser\SimpleSerializer.java:
> // TODO the attribute name needs to be preserved from the XML
> org\apache\axis\FaultableHandler.java: * !!! TODO: This needs
> to be able to handle searching by faultcode
> org\apache\axis\handlers\JWSHandler.java: // !!! TODO: add a
> switch to control this.
> org\apache\axis\handlers\SimpleSessionHandler.java: * !!! TODO:
Should
> be able to set this via options on the Handler
> org\apache\axis\handlers\soap\SOAPService.java: // TODO: a
> SOAPService should always be associated with an engine,
> org\apache\axis\handlers\soap\SOAPService.java: // TODO : Handle
> SOAP 1.2 ultimateDestination actor as well
> org\apache\axis\message\MessageElement.java: /** !!! TODO : Make sure
> this handles multiple targets
> org\apache\axis\MessageContext.java: * Whaddya think? - todo by Jacek)
> org\apache\axis\MessageContext.java: * tool do this by default? -
> todo by Jacek)
> org\apache\axis\MessageContext.java: //TODO: Flesh this out.
> org\apache\axis\SOAPPart.java: * TODO: For now, since we aren't
> actually doing MIME yet,
> org\apache\axis\SOAPPart.java: * TODO: rename this for clarity;
should
> be more like getContents.
> org\apache\axis\SOAPPart.java: * TODO: rename this for clarity to
> something more like setContents???
> org\apache\axis\transport\http\AxisServlet.java: * @todo for secure
> installations, dont stack trace on faults
> org\apache\axis\transport\http\AxisServlet.java: //TODO: what
> error code should we send back for no method?
> org\apache\axis\transport\http\AxisServlet.java: //TODO: error
> code
> org\apache\axis\transport\http\AxisServlet.java: //
TODO:
> less generic realm choice?
> org\apache\axis\transport\http\AxisServlet.java: // TODO: Should
> really be doing this with explicit AxisFault
> org\apache\axis\transport\http\AxisServletBase.java: * @todo Fixme
for
> multiple servlets.
> org\apache\axis\transport\http\AxisServletBase.java: * @todo add
catch
> for not being able to cast the context attr to an
> org\apache\axis\transport\http\HTTPConstants.java: * whaddya think?
-
> todo by Jacek)
> org\apache\axis\transport\http\HTTPSender.java: //Need
> todo a little msgContext house keeping....
> org\apache\axis\transport\http\HTTPSender.java: //Need
> todo a little msgContext house keeping....
> org\apache\axis\types\Duration.java: * @todo make this more flexible
> org\apache\axis\types\HexBinary.java: //TODO: How do we hash this?
> org\apache\axis\types\HexBinary.java: //TODO: Is this good enough?
> org\apache\axis\types\NormalizedString.java: //TODO: How do we
hash
> this?
> org\apache\axis\wsdl\symbolTable\SymbolTable.java: // TODO -
If
> we are unable to represent any of the types in the
> org\apache\axis\components\compiler\Jikes.java: // FIXME: VG:
> This is not needed anymore?
> org\apache\axis\description\ServiceDesc.java: // FIXME : Throw
> an error?
> org\apache\axis\description\ServiceDesc.java: // FIXME : Check
> for existing ones and fault if found
> org\apache\axis\description\ServiceDesc.java: // FIXME
:
> Throw an error?
> org\apache\axis\encoding\ser\BeanSerializer.java:
//
> FIXME!
> org\apache\axis\encoding\ser\CalendarDeserializer.java: //
validate
> fixed portion of format
> org\apache\axis\encoding\ser\DateDeserializer.java: // validate
> fixed portion of format
> org\apache\axis\handlers\SimpleSessionHandler.java: //
FIXME
> : This cleanup should probably happen on another
> org\apache\axis\handlers\soap\SOAPService.java: // FIXME:
Throw
> NPE?
> org\apache\axis\message\RPCHandler.java: // FIXME : Do we need
> to be in EITHER named OR positional
> org\apache\axis\message\RPCHandler.java:
> xsiClass + " -> " + destClass + ")"); // FIXME!
> org\apache\axis\message\SOAPHeaderElement.java: // FIXME : This
> needs to come from someplace reasonable, perhaps
> org\apache\axis\message\SOAPHeaderElement.java: public
> SOAPHeaderElement(String namespace, String localPart, String prefix,
> org\apache\axis\message\SOAPHeaderElement.java: super(namespace,
> localPart, prefix, attributes, context);
> org\apache\axis\message\SOAPHeaderElement.java: // FIXME
> org\apache\axis\providers\java\JavaProvider.java: // FIXME
:
> Should we bomb in this case?
> org\apache\axis\providers\java\RPCProvider.java: // FIXME :
> There should be a cleaner way to do this...
> org\apache\axis\providers\java\RPCProvider.java: // that
> follow the parameters! FIXME?
> org\apache\axis\providers\java\RPCProvider.java: // FIXME (there
> should be a cleaner way to do this)
> org\apache\axis\providers\java\RPCProvider.java: // FIXME : Does
> this make sense here???
> org\apache\axis\wsdl\fromJava\Types.java: throw new
> AxisFault("Type was " + type.getName()); // FIXME!
> org\apache\axis\wsdl\toJava\JavaStubWriter.java: // FIXME: this
only
> checks for wrapped in a global way, which
>
> 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 07:33:17 AM
>
> Please respond to [EMAIL PROTECTED]
>
> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> cc:
> Subject: RE: Only one operation if Msg style?
>
>
>
>
> It was just changed to make the ServiceDesc-based introspection code
easier
> to deal with, and the intent was always to figure out what kind of
support
> we really wanted and then do that. It's been the current way for quite a
> while and this is the first time anyone's really mentioned it, so I doubt
> it broke too many people.
>
> I'm fine with a QName->operation map, and it would be nice if we could
> embed or import schemas into the WSDD for the various operations, too, so
> we could generate useful WSDL....
>
> --Glen
>
> > -----Original Message-----
> > From: Doug Davis [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, September 23, 2002 12:16 AM
> > To: [EMAIL PROTECTED]
> > Subject: RE: Only one operation if Msg style?
> >
> > I'm wondering though why we changed it. In the old version
> > of the code if
> > someone entered just a single method name in the
> > WSDD/allowedMethods field
> > then they got what your suggesting (current behavior). If
> > they entered in
> > multiple names then they get what Rick is looking for. It
> > seems to be the
> > old way was more flexible. So why did we change it? Seem like an
> > unnecessary restriction - not to mention I'm pretty sure
> > it'll break quite
> > a few people (I know of at least two groups that are counting
> > on the old
> > behavior).
> > -Dug
> >
> > ps. sigh - can't get on irc (if you're there)
> >
> >
> > Glen Daniels <[EMAIL PROTECTED]> on 09/22/2002 11:57:59 PM
> >
> > Please respond to [EMAIL PROTECTED]
> >
> > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> > cc:
> > Subject: RE: Only one operation if Msg style?
> >
> >
> >
> > It's not so much a reasonable limitation as an implementation
> > convenience,
> > which could certainly be changed. In Axis, "Message" style services
> > involve just handing the raw XML in some form to the back end
>
=== message truncated ===
=====
Davanum Srinivas - http://xml.apache.org/~dims/
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
