JAX-RPC Handlers and Axis Handlers are different beasties, which is a bit of a shame, but makes some sense too. There is no mechanism in JAX-RPC by which you actually connect Handlers to your system on the server side, for one thing - the only thing it specifies is how to programatically register client-side Handlers via the HandlerRegistry.
JSR-109 is coming out with a deployment descriptor syntax for registering (JAX-RPC) Handlers on the server side, and that will be the way you get those into the system. There are also some very limiting rules right now in the JSR-109 spec about what Handlers can do and when they run. So what we on the Axis team will likely do is provide a JSR-109-style hook for deploying JAX-RPC Handlers when that goes final, and that's how you'll use JAX-RPC Handlers. If you want the functionality/configurability of Axis Handlers, you should use the org.apache.axis.Handler interface. --Glen > -----Original Message----- > From: John Gregg [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 21, 2002 11:15 AM > To: [EMAIL PROTECTED] > Subject: ClassCastException and handlers > > > Hi all. > > Perhaps you saw my note to axis-user about a handler I was > trying to write. > I created a handler that was a subclass of > javax.xml.rpc.handler.GenericHandler but WSDDDeployableItem > expects it to be > org.apache.axis.Handler. Consequently I was getting a > ClassCastException on > line 355 of version 1.35. The Axis implementation is free to > use its own > implementations internally, but all points of contact with > application code > should stick to the interfaces. That's the point of the > interface and the > main reason I like Axis so much better than Apache SOAP. > Anyway, it doesn't > appear to be a trivial matter to just change the cast, > unfortunately. I'd > appreciate it if someone can suggest a way around this. I'm > even willing to > tie myself to the Axis implemetation classes in the short run > if I know I > can remove those dependencies later. > > thanks > > john >
