HI! 1) We extend RPCProvider and override some methods of it. I have attached 2 code fragments of our server. I think, you're right. If we would get untyped XML, we would have a problem. If we could set the class and method earlier (right before AxisServer.invoke()), so that Axis would ignore the deployed service, then it should work. Otherwise we would have to deploy dynamically every time a class is used for the first time. :-( Also, if you clean up RPCProvider: We still need to do our own method invocation, because we have our own method cache, security and error logging.
2) I am here for another hour or so. So, if you want to chat now, please tell me which server and channel. Otherwise we could arrange for some time tomorrow (starting from 10:00 AM german time). Regards, Thomas > -----Original Message----- > From: Glen Daniels [mailto:[EMAIL PROTECTED]] > Sent: Montag, 25. März 2002 17:31 > To: '[EMAIL PROTECTED]' > Subject: RE: Proposed change for RPCProvider.java for Beta 1 > > > > Hi Thomas: > > I have a couple of questions relating to the dynamic stuff > you're doing with Axis. > > 1) For Axis to successfully deserialize XML into parameters > suitable for passing to a method invocation, we need to know > the schema types of the XML elements. We can either get that > information from the xsi:type attribute, or via metadata > (i.e. introspecting the Java class, deployment info, etc). > Do you rely on xsi:type being set for your stuff to work? It > seems like the introspection we do (used to be in RPCElement, > now in ServiceDesc) wouldn't pick up your "real" class and > instead would get metadata for whichever class you specified > in the deployment for the service... so how would you know > how to deserialize untyped XML otherwise? > > 2) I'd like to clean up the code in RPCProvider which ends up > trying different things to get the RPCElement to correctly > resolve into a method call. My idea is to implement "early > binding" as much as possible by hooking the mechanism by > which we figure out how to deserialize into the > method-dispatch. In other words, by the time we've > succesfully deserialized a message, we should already be able > to unambiguously determine which back-end method we're going > to call. I want to do this in a way which still allows > patterns like yours, but to understand just how to do that > I'd like to talk about your usage patterns. Any chance you > might be able to hop onto IRC for a real-time chat sometime today? > > Thanks, > --Glen > > > -----Original Message----- > > From: Thomas Börkel [mailto:[EMAIL PROTECTED]] > > Sent: Friday, March 08, 2002 10:01 AM > > To: [EMAIL PROTECTED] > > Subject: RE: Proposed change for RPCProvider.java for Beta 1 > > > > > > HI! > > > > I can describe how I did it: > > > > I have ONE service deployed (I can provide the deployment > > wsdd, if you want, I deploy at runtime with a string) with a > > dummy class and method and my own transport always tells Axis > > to use that one service. Also, the transport sets the real > > class name as property in the MessageContext. > > > > For the service, I have defined my own provider. This > > provider ignores the class and object that Axis gives to the > > provider in processMessage() and instead reads the class name > > from the MessageContext. > > > > It is required to have your own transport if you want to do > > it that way, AFAIK. > > > > An alternative to my method, would be for the transport to > > deploy the services/classes dynamically at the first call to > > this class. This way, Axis would get the real class and > > object and give it to my provider. This is a change I *may* > > make sometime. > > > > With the proposed change, I can derive from RPCProvider, > > override some methods and implement my own method search, > > invocation and security with little effort. Before, I derived > > from JavaProvider and copied the SOAP request analyze and > > SOAP answer compose code from RPCProvider. > > > > The reason, we needed invocation without deployment is the > > fact, that we expose around 200 java classes as web services. > > To keep the Java classes always in sync with the deployment > > WSDDs during development (the client comes also from us) > > would be a real pain. > > > > Requests for WSDL are satisfied on the fly. > > > > If you need further information, feel free to ask. > > > > Regards, > > Thomas > > > > > -----Original Message----- > > > From: William Lee [mailto:[EMAIL PROTECTED]] > > > Sent: Freitag, 8. März 2002 12:30 > > > To: [EMAIL PROTECTED] > > > Subject: Re: Proposed change for RPCProvider.java for Beta 1 > > > > > > > > > Changes posted by Thomas Börkel seems to be related to my > > proposal on > > > implementing the dynamic RPCProvider, is there any more > > > information on > > > how to perform your "invocation without deployment" in the > > > Axis framework? > > > > > > William Lee > > > > > > Thomas Börkel wrote: > > > > > > > HI! > > > > > > > > I have made a few minor changes (only extract code from > > > processMessage() to seperate methods) in RPCProvider.java > > > (please find attached) that allow us much more easily to do > > > our own invocation without deployment (one service deployed > > > for all our classes). > > > > > > > > These are the changes: > > > > - added MessageContext parameter to getMethod() > > > > - added method invokeMethod() > > > > - added method checkMethodName() > > > > > > > > It would be EXTREMELY helpful, if you could commit these > > > changes into Beta 1. > > > > > > > > Thanks! > > > > > > > > Regards, > > > > Thomas > > > > > > > > > > > > > > > > > > > > -- > > > > > > William Lee > > > > > > Imperial College of Science Technology and Medicine > > > Room 354, Department of Computing, > > > 180 Queen's Gate > > > London SW7 2BZ, U.K. > > > > > > email:[EMAIL PROTECTED] > > > web:www.image-union.com > > > > > > > > > > > >
Provider.java
Description: Provider.java
Transport.java
Description: Transport.java
