You are viewing a plain text version of this content. The canonical link for it is here.
Posted to muse-user@ws.apache.org by Andrew Eberbach <ae...@us.ibm.com> on 2007/02/01 00:00:50 UTC
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
aeberbac@us.ibm.com
"Vinh Nguyen \(vinguye2\)" <vi...@cisco.com>
01/31/2007 05:55 PM
Please respond to
muse-user@ws.apache.org
To
<mu...@ws.apache.org>
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:aeberbac@us.ibm.com]
Sent: Wednesday, January 31, 2007 2:46 PM
To: muse-user@ws.apache.org
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
aeberbac@us.ibm.com
"Vinh Nguyen \(vinguye2\)" <vi...@cisco.com>
01/31/2007 05:35 PM
Please respond to
muse-user@ws.apache.org
To
<mu...@ws.apache.org>
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: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
RE: custom header properties
Posted by "Vinh Nguyen (vinguye2)" <vi...@cisco.com>.
Thanks Dan and Andrew,
I finally was able to test the 2/5 daily build, and the updates work.
I'm not using the "-header" flag, so I currently override the
AbstractResourceClient.invoke(String,Element,Element[]) to pass some
custom header elements, and retrieve it on the server-side using the
MessageHeader object. So now, I'm going to try to retrieve the custom
headers using Axis2 until Muse 2.2 comes out. Keep up the good work!
-Vinh
-----Original Message-----
From: Andrew Eberbach [mailto:aeberbac@us.ibm.com]
Sent: Thursday, February 01, 2007 6:10 PM
To: muse-user@ws.apache.org
Subject: RE: custom header properties
Ok, headers stuff on the server side is out.
Thanks,
Andrew
Andrew Eberbach
Autonomic Computing
(919) 254-2645
T/L: 444-2645
aeberbac@us.ibm.com
Daniel Jemiolo/Durham/IBM@IBMUS
02/01/2007 07:02 PM
Please respond to
muse-user@ws.apache.org
To
muse-user@ws.apache.org
cc
Subject
RE: custom header properties
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\)" <vi...@cisco.com> 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:danjemiolo@us.ibm.com]
> Sent: Thursday, February 01, 2007 8:32 AM
> To: muse-user@ws.apache.org
> 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\)" <vi...@cisco.com> 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:aeberbac@us.ibm.com]
> > Sent: Wednesday, January 31, 2007 3:01 PM
> > To: muse-user@ws.apache.org
> > 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
> > aeberbac@us.ibm.com
> >
> >
> >
> > "Vinh Nguyen \(vinguye2\)" <vi...@cisco.com>
> > 01/31/2007 05:55 PM
> > Please respond to
> > muse-user@ws.apache.org
> >
> >
> > To
> > <mu...@ws.apache.org>
> > 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:aeberbac@us.ibm.com]
> > Sent: Wednesday, January 31, 2007 2:46 PM
> > To: muse-user@ws.apache.org
> > 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
> > aeberbac@us.ibm.com
> >
> >
> >
> > "Vinh Nguyen \(vinguye2\)" <vi...@cisco.com>
> > 01/31/2007 05:35 PM
> > Please respond to
> > muse-user@ws.apache.org
> >
> >
> > To
> > <mu...@ws.apache.org>
> > 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: muse-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: muse-user-help@ws.apache.org
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: muse-user-help@ws.apache.org
> >
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: muse-user-help@ws.apache.org
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: muse-user-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
RE: custom header properties
Posted by Andrew Eberbach <ae...@us.ibm.com>.
Ok, headers stuff on the server side is out.
Thanks,
Andrew
Andrew Eberbach
Autonomic Computing
(919) 254-2645
T/L: 444-2645
aeberbac@us.ibm.com
Daniel Jemiolo/Durham/IBM@IBMUS
02/01/2007 07:02 PM
Please respond to
muse-user@ws.apache.org
To
muse-user@ws.apache.org
cc
Subject
RE: custom header properties
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\)" <vi...@cisco.com> 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:danjemiolo@us.ibm.com]
> Sent: Thursday, February 01, 2007 8:32 AM
> To: muse-user@ws.apache.org
> 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\)" <vi...@cisco.com> 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:aeberbac@us.ibm.com]
> > Sent: Wednesday, January 31, 2007 3:01 PM
> > To: muse-user@ws.apache.org
> > 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
> > aeberbac@us.ibm.com
> >
> >
> >
> > "Vinh Nguyen \(vinguye2\)" <vi...@cisco.com>
> > 01/31/2007 05:55 PM
> > Please respond to
> > muse-user@ws.apache.org
> >
> >
> > To
> > <mu...@ws.apache.org>
> > 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:aeberbac@us.ibm.com]
> > Sent: Wednesday, January 31, 2007 2:46 PM
> > To: muse-user@ws.apache.org
> > 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
> > aeberbac@us.ibm.com
> >
> >
> >
> > "Vinh Nguyen \(vinguye2\)" <vi...@cisco.com>
> > 01/31/2007 05:35 PM
> > Please respond to
> > muse-user@ws.apache.org
> >
> >
> > To
> > <mu...@ws.apache.org>
> > 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: muse-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: muse-user-help@ws.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: muse-user-help@ws.apache.org
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: muse-user-help@ws.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: muse-user-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
RE: custom header properties
Posted by Daniel Jemiolo <da...@us.ibm.com>.
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\)" <vi...@cisco.com> 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:danjemiolo@us.ibm.com]
> Sent: Thursday, February 01, 2007 8:32 AM
> To: muse-user@ws.apache.org
> 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\)" <vi...@cisco.com> 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:aeberbac@us.ibm.com]
> > Sent: Wednesday, January 31, 2007 3:01 PM
> > To: muse-user@ws.apache.org
> > 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
> > aeberbac@us.ibm.com
> >
> >
> >
> > "Vinh Nguyen \(vinguye2\)" <vi...@cisco.com>
> > 01/31/2007 05:55 PM
> > Please respond to
> > muse-user@ws.apache.org
> >
> >
> > To
> > <mu...@ws.apache.org>
> > 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:aeberbac@us.ibm.com]
> > Sent: Wednesday, January 31, 2007 2:46 PM
> > To: muse-user@ws.apache.org
> > 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
> > aeberbac@us.ibm.com
> >
> >
> >
> > "Vinh Nguyen \(vinguye2\)" <vi...@cisco.com>
> > 01/31/2007 05:35 PM
> > Please respond to
> > muse-user@ws.apache.org
> >
> >
> > To
> > <mu...@ws.apache.org>
> > 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: muse-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: muse-user-help@ws.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: muse-user-help@ws.apache.org
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: muse-user-help@ws.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: muse-user-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
RE: custom header properties
Posted by "Vinh Nguyen (vinguye2)" <vi...@cisco.com>.
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:danjemiolo@us.ibm.com]
Sent: Thursday, February 01, 2007 8:32 AM
To: muse-user@ws.apache.org
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\)" <vi...@cisco.com> 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:aeberbac@us.ibm.com]
> Sent: Wednesday, January 31, 2007 3:01 PM
> To: muse-user@ws.apache.org
> 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
> aeberbac@us.ibm.com
>
>
>
> "Vinh Nguyen \(vinguye2\)" <vi...@cisco.com>
> 01/31/2007 05:55 PM
> Please respond to
> muse-user@ws.apache.org
>
>
> To
> <mu...@ws.apache.org>
> 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:aeberbac@us.ibm.com]
> Sent: Wednesday, January 31, 2007 2:46 PM
> To: muse-user@ws.apache.org
> 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
> aeberbac@us.ibm.com
>
>
>
> "Vinh Nguyen \(vinguye2\)" <vi...@cisco.com>
> 01/31/2007 05:35 PM
> Please respond to
> muse-user@ws.apache.org
>
>
> To
> <mu...@ws.apache.org>
> 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: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
RE: custom header properties
Posted by Andrew Eberbach <ae...@us.ibm.com>.
Ok I'll do that today.
Thanks,
Andrew
Andrew Eberbach
Autonomic Computing
(919) 254-2645
T/L: 444-2645
aeberbac@us.ibm.com
Daniel Jemiolo/Durham/IBM@IBMUS
02/01/2007 11:31 AM
Please respond to
muse-user@ws.apache.org
To
muse-user@ws.apache.org
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\)" <vi...@cisco.com> 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:aeberbac@us.ibm.com]
> Sent: Wednesday, January 31, 2007 3:01 PM
> To: muse-user@ws.apache.org
> 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
> aeberbac@us.ibm.com
>
>
>
> "Vinh Nguyen \(vinguye2\)" <vi...@cisco.com>
> 01/31/2007 05:55 PM
> Please respond to
> muse-user@ws.apache.org
>
>
> To
> <mu...@ws.apache.org>
> 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:aeberbac@us.ibm.com]
> Sent: Wednesday, January 31, 2007 2:46 PM
> To: muse-user@ws.apache.org
> 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
> aeberbac@us.ibm.com
>
>
>
> "Vinh Nguyen \(vinguye2\)" <vi...@cisco.com>
> 01/31/2007 05:35 PM
> Please respond to
> muse-user@ws.apache.org
>
>
> To
> <mu...@ws.apache.org>
> 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: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
RE: custom header properties
Posted by Daniel Jemiolo <da...@us.ibm.com>.
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\)" <vi...@cisco.com> 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:aeberbac@us.ibm.com]
> Sent: Wednesday, January 31, 2007 3:01 PM
> To: muse-user@ws.apache.org
> 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
> aeberbac@us.ibm.com
>
>
>
> "Vinh Nguyen \(vinguye2\)" <vi...@cisco.com>
> 01/31/2007 05:55 PM
> Please respond to
> muse-user@ws.apache.org
>
>
> To
> <mu...@ws.apache.org>
> 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:aeberbac@us.ibm.com]
> Sent: Wednesday, January 31, 2007 2:46 PM
> To: muse-user@ws.apache.org
> 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
> aeberbac@us.ibm.com
>
>
>
> "Vinh Nguyen \(vinguye2\)" <vi...@cisco.com>
> 01/31/2007 05:35 PM
> Please respond to
> muse-user@ws.apache.org
>
>
> To
> <mu...@ws.apache.org>
> 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: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
RE: custom header properties
Posted by "Vinh Nguyen (vinguye2)" <vi...@cisco.com>.
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:aeberbac@us.ibm.com]
Sent: Wednesday, January 31, 2007 3:01 PM
To: muse-user@ws.apache.org
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
aeberbac@us.ibm.com
"Vinh Nguyen \(vinguye2\)" <vi...@cisco.com>
01/31/2007 05:55 PM
Please respond to
muse-user@ws.apache.org
To
<mu...@ws.apache.org>
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:aeberbac@us.ibm.com]
Sent: Wednesday, January 31, 2007 2:46 PM
To: muse-user@ws.apache.org
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
aeberbac@us.ibm.com
"Vinh Nguyen \(vinguye2\)" <vi...@cisco.com>
01/31/2007 05:35 PM
Please respond to
muse-user@ws.apache.org
To
<mu...@ws.apache.org>
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: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org