Menu
▾
▴
[Springframework-developer] RE: [Springframework-user] JaxRpcPortProxyFactoryBean with Axis local transport?
|
From: Juergen H. <ju...@in...> - 2005-01-04 22:45:27
|
Actually, Axis does *not* require the server-side service endpoint to implement an RMI port interface! (As far as I remember, GLUE doesn't either.) This means that you can avoid an RMI port interface completely: just specify a non-RMI service interface at the client side, and let your service endpoint class implement that non-RMI service interface on the server side. On the client side, our new mechanism that uses JAX-RPC dynamic calls should work with any JAX-RPC implementation, despite the lack of an RMI port interface. On the server side, this will just work with JAX-RPC implementations that accept plain service endpoint classes. I've adapted JPetStore accordingly, dropping the RemoteOrderService interface completely. Much nicer, avoiding the double service interface. On second thought, I recommend this strategy: Don't bother with an RMI port interface unless you need to. I've tested all of this against Axis 1.1. I tried Axis 1.2 RC2 too, but it fails with some mysterious "character found in array data" (or similar) message. Doesn't have to do anything with the above, though: It fails with the Spring 1.1.3 JPetStore too. BTW, I've also noticed that Axis doesn't work with JDK 1.5's default XML parser, despite the latter being derived from Xerces! You need to drop in Xerces 2.6 into jre/lib/ext to make Axis work. I do this on JDK 1.4.2 anyway, but I would have thought that this wasn't necessary anymore on JDK 1.5... Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Juergen Hoeller Sent: Tuesday, January 04, 2005 5:55 PM To: spr...@li... Subject: RE: [Springframework-user] JaxRpcPortProxyFactoryBean with Axis local transport? Michael, Indeed, the Call interface is used underneath Axis' port stub implementation. However, we can't access it there, as it is hidden behind the JAX-RPC stub API. On this occasion, I've implemented an option that I've had in mind for a while: JaxRpcPortProxyFactoryBean working with JAX-RPC dynamic calls rather than with JAX-RPC port stubs. My main intent was to avoid the need to specify an RMI interface as "portInterface" when working with a non-RMI "serviceInterface". This new option kicks in when you don't specify a "portInterface" and the "serviceInterface" does not extend [java.rmi.Remote]. JaxRpcPortProxyFactoryBean will automatically use the JAX-RPC Call API then, instead of a port stub. When using the Call API, new corresponding hooks are available, in particular the "postProcessJaxRpcCall" method. The current Call object gets passed in there; you can set properties etc or cast to the Axis implementation class and call a method there. This should give you the option to call "setTransport" now. Using the JAX-RPC Call API gives a lot of flexibility, as it allows for more customization than the JAX-RPC stub mechanism. And of course, it avoids the need for an RMI port interface on the client side. (You still need an RMI interface for JAX-RPC compliant server-side export.) The JAX-RPC stub mechanism might involve some optimizations that your JAX-RPC implementation applies, though, which you might lose when using the Call API. Therefore, I still recommend to specify the RMI "portInterface" when available (which will usually be the case when doing export via JAX-RPC too), unless you want to customize at the Call API level. I'll commit this tonight, so it should be available in the current snapshot tomorrow (http://www.springframework.org/downloads/nightly). Please give it a try! Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Michael Schuerig Sent: Tuesday, January 04, 2005 1:26 PM To: spr...@li... Subject: Re: [Springframework-user] JaxRpcPortProxyFactoryBean with Axis local transport? On Tuesday 04 January 2005 12:09, Juergen Hoeller wrote: > The Call object is only used for dynamic invocations (via the JAX-RPC > DII), not for invocations via static proxy interfaces. So with a > proxy provided by JaxRpcPortProxyFactoryBean, there are no Call > objects involved at all. Actually they are created somewhere deep down Service.createCall() line: 547 Service.createCall(QName) line: 463 Service.getPort(String, QName, Class) line: 436 Service.getPort(QName, Class) line: 312 JaxRpcPortClientInterceptor.afterPropertiesSet() line: 269 > Is there a way to specify the transport for static invocations on > Stub objects too? Or to specify the transport at the Service level, > for all Stubs and/or Calls created by the given Service? Apparently not. Relevant is the transport that's set on the Call object created as shown above. This Call object is hidden within an AxisClientProxy which is in turn used as the InvocationHandler of a dynamic Proxy. Some way to access/configure that Call object would really help me as I'm stuck with a related problem where I need to set the style of the call to WRAPPED. Michael -- Michael Schuerig Most people would rather die than think. mailto:mi...@sc... In fact, they do. http://www.schuerig.de/michael/ --Bertrand Russell ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Springframework-user mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-user ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Springframework-user mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-user |
