Ok I'll do that today. Thanks, Andrew
Andrew Eberbach Autonomic Computing (919) 254-2645 T/L: 444-2645 [EMAIL PROTECTED] Daniel Jemiolo/Durham/[EMAIL PROTECTED] 02/01/2007 11:31 AM Please respond to [email protected] To [email protected] cc 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]
