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
> method. As
> such, we currently assume that there is only one of those,
> and it will deal
> with any further dispatch (on QName, for instance) by itself.
> This allows
> us to resolve the OperationDesc ASAP.
>
> A "document" style service, however, has N operations,
> dispatched by QName.
> "Document" style services also do data binding, and will
> deserialize XML
> into Java objects.
>
> WSDL doesn't have a concept of "message" style, that's just
> an Axis thing.
> If your WSDL defines several doc/lit operations, that's fine,
> since either
> a) you use WSDL2Java to build your classes and it makes a
> "document" style
> service for you (1 method per operation w/data binding), or
> b) you have a
> "message" style service in which case it's up to your "xml
> handling" method
> to figure out what to do.
>
> We could easily add a QName-based dispatch so that you could
> direct the XML
> at several different methods in a message-style service,
> though. Is this
> what you're interested in?
>
> --Glen
>
> > -----Original Message-----
> > From: Rick Rineholt [mailto:[EMAIL PROTECTED]]
> > Sent: Sunday, September 22, 2002 3:59 PM
> > To: [EMAIL PROTECTED]
> > Subject: Only one operation if Msg style?
> >
> >
> > There seems to have been a limitation put in since B3 that
> > message style
> > services can support only
> > one operation. MessageContext.java 634 to 644. May I ask
> > why was this
> > done? Is this a reasonable
> > limitation? I don't believe SOAP or WSDL make any such
> > restrictions. If I
> > want to use URL mapping to
> > target my service class and my WSDL defines several message style
> > operations in that service it
> > appears this is not possible unless there some other means
> > I'm not aware of
> > to get this done.
> >
> > Rick Rineholt
> > "The truth is out there... All you need is a better search engine!"
> >
> > [EMAIL PROTECTED]
> >
> >
> >
>
>
>
