Your WSDL should not be affected by the -headers stuff in wsdl2java. You are right, the generated methods should match the WSDL operations parameter-for-parameter, regardless of whether the -headers flag is used; that's being fixed by Andrew. So, starting with tonight's build, all you need to do is run wsdl2java as normal (no -headers flag, except for the client generation). The code I checked in today makes it possible to get the non-WSA headers from MessageHeaders using the getCustomHeader*() methods (there are three of them) in a platform-independent way.
I did not update the toXML() method with the custom headers, but I will do that now. The content of MessageHeaders objects is per-request - when you call getEnvironment().getAddressingContext(), you're getting the headers/info for the current request, and if a new request is created while your code is executing, a new MessageHeaders object is created to store that request's headers. There is no over-writing of MessageHeaders contents because of threading issues. Dan "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 02/01/2007 02:06:46 PM: > Thanks Dan, > Is there a sample wsdl so that I can test the new "-header" wsdl2java > flag, to see what it is currently outputting? Based on your description > below, I assume it is adding an extra parameter to the capability method > for the operation. If this is true, I agree that it does cause > confusion. We understand that the method signature should match the > operation signature defined in the wsdl. If the method has other > parameters, it will be very hard to trace/debug. > > MessageHeaders is actually the place that I'm expecting the update to be > in:) It currently has methods to directly get addressing items, but no > methods to get anything else in the headers. The update makes it very > simple to get custom properties from within a capability. Also, please > make sure that MessageHeaders.toXML() also outputs the custom > properties, so that we can verify all that the object is storing. > > This does bring up a question though: does MessageHeaders now make the > capability stateful? Or, is should we still expect stateless because > the next time the capability is called, the contents of MessageHeaders > will be overwritten with the latest request? > > I am currently assuming the stateless approach where the contents are on > a request basis. For example, using WS-Security, authentication will be > done per request, so I am checking the username/password properties in > MessageHeaders each time the capability is called. > -Vinh > > > -----Original Message----- > From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 01, 2007 8:32 AM > To: [email protected] > Subject: RE: custom header properties > > Looking at the routing code, I think it would be pretty hack-ish to try > and guess when a custom headers parameter (Element[]) was being used on > the server side, and change the parameter list for the method > invocation. > The basic case would be pretty easy, but I fear that it would lead to > weird edge cases and unexpected behavior. > > Instead, I would like to add a getCustomHeaders() method (or something - > name suggestions welcome) to the WSA MessageHeaders class. this way, WSA > headers and other SOAP headers would be retrieved from the same place. > This will involve removing the code around _generateHeaders in > muse-tool's ServerSynthesizer. The client generation for custom headers > would remain as it is. This will allow us to send custom headers and > receive them without modifying the core routing logic. > > Dan > > > > "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 01/31/2007 > 07:30:42 PM: > > > Hi Andrew, > > Yep, we're talking about the same thing. The JIRA description only > > identifies what was changed on the client side. I'd like to know what > > > classes were affected on the server side so I can look at the code > > more closely. I'm still trying to figure out how to get the > > properties from within a capability, or if there's a way to see the > > entire SOAP request from the capability. > > -Vinh > > > > > > -----Original Message----- > > From: Andrew Eberbach [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, January 31, 2007 3:01 PM > > To: [email protected] > > Subject: RE: custom header properties > > > > http://issues.apache.org/jira/browse/MUSE-166 > > > > We're talking about that right? > > > > Thanks, > > Andrew > > > > Andrew Eberbach > > Autonomic Computing > > (919) 254-2645 > > T/L: 444-2645 > > [EMAIL PROTECTED] > > > > > > > > "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> > > 01/31/2007 05:55 PM > > Please respond to > > [email protected] > > > > > > To > > <[email protected]> > > cc > > > > Subject > > RE: custom header properties > > > > > > > > > > > > > > Hi Andrew, > > This is actually on the server side, not the client. The server > > capability needs to get the header properties specified in the client > > request. This is to support other standards, like WS-Security. > > -Vinh > > > > > > -----Original Message----- > > From: Andrew Eberbach [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, January 31, 2007 2:46 PM > > To: [email protected] > > Subject: Re: custom header properties > > > > Hi, > > > > This was changed in the code generation. Same flag as for the proxy. > > > > Thanks, > > Andrew > > > > Andrew Eberbach > > Autonomic Computing > > (919) 254-2645 > > T/L: 444-2645 > > [EMAIL PROTECTED] > > > > > > > > "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> > > 01/31/2007 05:35 PM > > Please respond to > > [email protected] > > > > > > To > > <[email protected]> > > cc > > > > Subject > > custom header properties > > > > > > > > > > > > > > I remember that recently there was a discussion on how to send custom > > properties in the request header. The resolution was a new > > AbstractResourceClient.invoke(String,Element,Element[]) method. But, > > I haven't seen a corresponding update on the server side on how to get > > > those custom properties, particularly in a capability class. > > > > Is there a way to get the custom header properties from within a > > capability class? I tried > > Capability.getEnvironment.getAddressingContext().toXML(), but it only > > returns the properties it explicitly knows about (i.e. has methods > for). > > > > Any help is appreciated, thanks! > > -Vinh > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
