Hi Sylvain!
First off, I'm psyched that you're moving in this direction, because we clearly need to support headers in some way. The following is my take on things, both in terms of where I'd like to be able to go wrt extensions in general and also how to deal with the particular "fine-grained" approach you're taking. Headers have completely arbitrary semantics, and what happens as a result of a header being sent/received is really completely up to the specification wherein that header was defined. In fact, such a specification might well define *multiple* headers and how they relate to each other, message exchange patterns, challenge/response rules, etc.... This can get hairy and you don't really want your clients having to deal with it directly. What you really want (IMO) for the interesting cases is some well-defined chunk of code that plugs in and implements the entire specification for the module, including generating/reading all the appropriate headers. We already have Handlers for precisely this purpose, except that they're even a little too fine-grained. What's needed, I think, is a "Module" concept which contains Handlers, rules/code for automatically deploying them (on either the client or the server side), and some kind of optional API for getting any interesting values into or out of them. (This is post-1.0 Axis we're talking about here, btw) I can give you some examples later if you're interested. Now, that said, there are certainly more simple cases where you just want to "send the 7 as the ID header" or something like that, this is why we have the addHeader() API on Call, and this is the kind of thing you're trying to support with your code. In looking at the code you submitted, I'm not sure I see a real need for so much mechanism (i.e. all the Headers/HeaderKey/etc... classes) if we're going for the "simple" approach. It feels to me like we either want to: 1) Put the headers in parameters on the generated method signatures (I think this is what .NET does? It's also one style recommended in JAX-RPC). Add parameters named for the header parts to the list, and Holders for any out headers: public void doSomething(String realArg, String headerArg, IntHolder outputHeaderArg) or 2) Just let people add headers by QName via an _addHeader() call on the Stub. I'm OK with your "DISCARD"/"PERSIST" options, so perhaps those should be allowed, but I don't think we need much more than an ArrayList of HeaderDescriptor objects (where HeaderDescriptor == [SOAPHeaderElement, DISCARD/PERSIST flag]) in the Stub to make this happen. Thoughts? A few more specific comments re: your message inline below. Thanks, --Glen > -----Original Message----- > From: St-Germain, Sylvain [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 02, 2002 10:44 AM > To: Axis Dev (E-mail) > Subject: soap:header new implementation > > > Read on - design issue at the end. > > I have modified the original soap:header support > implementation to allow > full flexibility around the header management. The way I > have achieve this > is by allowing the user to specify the header object > lifecycle. The current > three lifecycles are: > > HeaderLifeCycle.REPLACE: the response's header object will > overwrite the > request's one This seems like kind of a bad idea to me, since it implies semantic knowledge of what the header is supposed to do, and I don't know of a lot of cases where this style is used (do you?). If you want to get at a header in the response message, you should have an API for that, but I don't think that we want to get into replacing headers like this (what happens if there are multiple returned headers with the same QName, for instance?). Leave that up to the user, or up to the Module if/when we get there. > HeaderLifeCycle.DISCARD: the request's header object is > removed from the > list after the call. > HeaderLifeCycle.PERSIST: the request's header stays as is. These seem like OK options. > A user then do: > binding.setHeader("CAM", cam, HeaderLifeCycle.REPLACE ); > binding.setHeader("hdrSession", hdrs, HeaderLifeCycle.DISCARD ); > > To allow the setHeader() and getHeader() method to work off > the binding > (PortType) class I had to add a new extension to the PortType > interface > (currently org.apache.axis.client.HeaderSupport) this is all > fine for client > side since the HeaderSupport interface is implemented by the > abstract Stub, > but doing so, I broke the Impl class since it also implements > the PortType. Why not just stick these methods on Stub, like _getProperty/_setProperty? In fact it looks like you already did that, so I don't get why this should change the PortType interface at all.... > This being said we will ultimately want access to those two > methods on the > server-side but in the mean time (since I am not implementing > server support > now) I need a spot to put those two methods. Any idea? I don't understand this - these are client-side methods, not server-side ones....? On the server, you can get access to the headers via the SOAPEnvelope. > Would bringing back the skeleton be the answer to my problem? Skeletons never disappeared, they're just not the default anymore. Regardless, I don't think they're the answer. :) > I am attaching the patch and the new files so you can > experiment the problem > with the Impl class. > > Note: I did not yet rename the Header and Headers classes as > was suggested > when I submitted the first implementation of the feature. > > All feedback much appreciated. > > -- > Sylvain > > This message may contain privileged and/or confidential > information. If you > have received this e-mail in error or are not the intended > recipient, you > may not use, copy, disseminate or distribute it; do not open any > attachments, delete it immediately from your system and > notify the sender > promptly by e-mail that you have done so. Thank you. > > >
