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]
