The standard Axis developer hangout is on DALNet (irc.dal.net), channel #ApacheAxis. If you have time now, I'd love to talk about this stuff - I should also be on tomorrow morning from about 9AM eastern US time (which is, I think, 7 hours back from Germany?).
--Glen > -----Original Message----- > From: Thomas Börkel [mailto:[EMAIL PROTECTED]] > Sent: Monday, March 25, 2002 12:19 PM > To: [EMAIL PROTECTED] > Subject: RE: Proposed change for RPCProvider.java for Beta 1 > > > 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 > > > > > > > > > > > > > > > > > >
