You are viewing a plain text version of this content. The canonical link for it is here.
Posted to muse-dev@ws.apache.org by José Antonio Sánchez <ge...@gmail.com> on 2006/12/12 18:16:24 UTC
Can I add custom header elements in a proxy request?
When I generate a client stub in Axis2 I can use the method
stub._getServiceClient().addHeader(OMElement element) to add a custom
element to the request's SOAP header but I cannot find something
similar in the Muse proxy. Is there a way to use a generated proxy and
to add a custom element to the header?
If there is no direct method to do this, is it safe to use a
ResourceParameter in the EndpointReference to send that custom
message?
--
Saludos.
José Antonio Sánchez
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
Re: Can I add custom header elements in a proxy request?
Posted by Daniel Jemiolo <da...@us.ibm.com>.
ok - I'll make a JIRA item and wait for Andrew to weigh in (since he'd be
implementing it).
> Sometimes I'd like Java to have default parameters like C has.
you and me both.
"José Antonio Sánchez" <ge...@gmail.com> wrote on 12/15/2006 09:51:05
AM:
> I think the #4 is the best solution. Normally when you need custom
> headers you need them in all operations withing a service so the
> generation time flag would be a solution. Also, if you don't need
> headers for an operation you could invoke the method using null.
> Sometimes I'd like Java to have default parameters like C has.
>
> On 12/15/06, Daniel Jemiolo <da...@us.ibm.com> wrote:
> > I agree that the design is easy to understand, but there are
consequences
> > from making the client stateful. Right now, multiple threads
> > (request-handling code) can share a single client object to send
messages
> > to another resource. By storing custom headers in the client object
prior
> > to method invocation, we create a number of issues around
synchronization;
> > since adding the headers and invoking the method are not part of an
atomic
> > operation, it's possible that two threads sharing a client object can
> > interrupt each other and cause messages to be sent out with the wrong
> > headers.
> >
> > The solutions to this are:
> >
> > 1. Document the fact that the client is not thread-safe and instruct
users
> > to wrap all uses of client objects in a synchronized() block.
> >
> > 2. Document the fact that the client is not thread-safe and instruct
users
> > to create a new client object for each new request (or session).
> >
> > 3. Keep the client stateless, but add better overloaded methods for
custom
> > headers in invoke().
> >
> > 4. Keep the client stateless, but provide a code generation
option/flag
> > that causes wsdl2java to create an extra Element[] parameter for
custom
> > headers. Something like:
> >
> > wsdl2java -wsdl MyResource.wsdl -headers
> >
> >
> > I think that #1 is problematic because it goes against the "principle
of
> > least surprise"; in other words, I don't think most people will read
the
> > muse-core JavaDoc prior to trying to use the code, nor should they
really
> > have to.
> >
> > #2 may be a performance problem for large-transaction enviroments. If
a
> > resource is sending out a lot of notifications, for example, that's a
lot
> > of object creation/throw away for the heap.
> >
> > #3 is the current solution, and is not easy to use. It was a quick
hack
> > that should be replaced/improved.
> >
> > I think that #4 would be fairly easy to implement, assuming it was a
> > resource-wide flag. The presence of the flag would just indicate to
> > wsdl2java that it should add an extra parameter named "Element[]
> > customHeaders" at the time of code generation. You could then use the
same
> > code you'd be using to build the header elements (for addHeaders())
and
> > supply them directly to the method being invoked. The next request
would
> > not be affected by the header usage.
> >
> > Thoughts? Or another idea?
> >
> >
> >
> > "José Antonio Sánchez" <ge...@gmail.com> wrote on 12/14/2006
10:31:48
> > AM:
> >
> > > What I did was to add a list of Element named "headers" to the proxy
> > > class and two new methods (addHeader(Element) and removeHeaders()),
> > > then I changed the invoke method to include that headers. That is
the
> > > code of a modified operation:
> > >
> > > private Vector<Element> headers = new Vector<Element>();
> > >
> > >
> > > public void addHeaderElement(Element header) {
> > > headers.add(header);
> > >
> > > }
> > >
> > > public void removeAllHeaders() {
> > > headers.removeAllElements();
> > > }
> > >
> > > public String install(URI packageLocation)
> > > throws SoapFault
> > > {
> > > Object[] params = new Object[1];
> > >
> > > params[0] = packageLocation;
> > >
> > > ProxyHandler handler = getHandler("install");
> > > Element body = handler.toXML(params);
> > > Element[] a = {};
> > > Element[] elementHeaders = headers.toArray(a);
> > > Element retElement =
> > invoke(handler.getAction(),body,elementHeaders);
> > > return (String)handler.fromXML(retElement);
> > > }
> > >
> > > I don't think adding that two operations to an upper level (say
> > > AbstractResourceClient) would be too much trouble.
> > >
> > > On 12/12/06, Daniel Jemiolo <da...@us.ibm.com> wrote:
> > > > We added some support for this in 2.1, although it may not be
perfect
> > > > (suggestions are welcome). Here's the JavaDoc on the method that
> > clients
> > > > can call down to in order to send custom headers with their
request:
> > > >
> > > >
> > > > http://ws.apache.org/muse/docs/2.1.
> > >
> >
0/javadoc/org/apache/muse/core/AbstractResourceClient.html#invoke(java.lang.
> > > String,%20org.w3c.dom.Element,%20org.w3c.dom.Element[])
> > > >
> > > >
> > > > You can change the generated client method implementation to use
this
> > > > invoke() instead of the normal one, giving you the opportunity to
> > provide
> > > > custom headers.
> > > >
> > > > One issue with providing the headers through some other means
> > > > (addHeader(), etc.) is that the clients are stateless. Any
alternative
> > > > would either need to handle this stateless-ness or suggest a
stateful
> > > > solution that isn't too hard to use.
> > > >
> > > > Dan
> > > >
> > > >
> > > >
> > > > "José Antonio Sánchez" <ge...@gmail.com> wrote on 12/12/2006
> > 12:16:24
> > > > PM:
> > > >
> > > > > When I generate a client stub in Axis2 I can use the method
> > > > > stub._getServiceClient().addHeader(OMElement element) to add a
> > custom
> > > > > element to the request's SOAP header but I cannot find something
> > > > > similar in the Muse proxy. Is there a way to use a generated
proxy
> > and
> > > > > to add a custom element to the header?
> > > > > If there is no direct method to do this, is it safe to use a
> > > > > ResourceParameter in the EndpointReference to send that custom
> > > > > message?
> > > > > --
> > > > > Saludos.
> > > > > José Antonio Sánchez
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > 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
> > > >
> > > >
> > >
> > >
> > > --
> > > Saludos.
> > > José Antonio Sánchez
> > >
> > >
---------------------------------------------------------------------
> > > 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-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: muse-dev-help@ws.apache.org
> >
> >
>
>
> --
> Saludos.
> José Antonio Sánchez
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
Re: Can I add custom header elements in a proxy request?
Posted by José Antonio Sánchez <ge...@gmail.com>.
I think the #4 is the best solution. Normally when you need custom
headers you need them in all operations withing a service so the
generation time flag would be a solution. Also, if you don't need
headers for an operation you could invoke the method using null.
Sometimes I'd like Java to have default parameters like C has.
On 12/15/06, Daniel Jemiolo <da...@us.ibm.com> wrote:
> I agree that the design is easy to understand, but there are consequences
> from making the client stateful. Right now, multiple threads
> (request-handling code) can share a single client object to send messages
> to another resource. By storing custom headers in the client object prior
> to method invocation, we create a number of issues around synchronization;
> since adding the headers and invoking the method are not part of an atomic
> operation, it's possible that two threads sharing a client object can
> interrupt each other and cause messages to be sent out with the wrong
> headers.
>
> The solutions to this are:
>
> 1. Document the fact that the client is not thread-safe and instruct users
> to wrap all uses of client objects in a synchronized() block.
>
> 2. Document the fact that the client is not thread-safe and instruct users
> to create a new client object for each new request (or session).
>
> 3. Keep the client stateless, but add better overloaded methods for custom
> headers in invoke().
>
> 4. Keep the client stateless, but provide a code generation option/flag
> that causes wsdl2java to create an extra Element[] parameter for custom
> headers. Something like:
>
> wsdl2java -wsdl MyResource.wsdl -headers
>
>
> I think that #1 is problematic because it goes against the "principle of
> least surprise"; in other words, I don't think most people will read the
> muse-core JavaDoc prior to trying to use the code, nor should they really
> have to.
>
> #2 may be a performance problem for large-transaction enviroments. If a
> resource is sending out a lot of notifications, for example, that's a lot
> of object creation/throw away for the heap.
>
> #3 is the current solution, and is not easy to use. It was a quick hack
> that should be replaced/improved.
>
> I think that #4 would be fairly easy to implement, assuming it was a
> resource-wide flag. The presence of the flag would just indicate to
> wsdl2java that it should add an extra parameter named "Element[]
> customHeaders" at the time of code generation. You could then use the same
> code you'd be using to build the header elements (for addHeaders()) and
> supply them directly to the method being invoked. The next request would
> not be affected by the header usage.
>
> Thoughts? Or another idea?
>
>
>
> "José Antonio Sánchez" <ge...@gmail.com> wrote on 12/14/2006 10:31:48
> AM:
>
> > What I did was to add a list of Element named "headers" to the proxy
> > class and two new methods (addHeader(Element) and removeHeaders()),
> > then I changed the invoke method to include that headers. That is the
> > code of a modified operation:
> >
> > private Vector<Element> headers = new Vector<Element>();
> >
> >
> > public void addHeaderElement(Element header) {
> > headers.add(header);
> >
> > }
> >
> > public void removeAllHeaders() {
> > headers.removeAllElements();
> > }
> >
> > public String install(URI packageLocation)
> > throws SoapFault
> > {
> > Object[] params = new Object[1];
> >
> > params[0] = packageLocation;
> >
> > ProxyHandler handler = getHandler("install");
> > Element body = handler.toXML(params);
> > Element[] a = {};
> > Element[] elementHeaders = headers.toArray(a);
> > Element retElement =
> invoke(handler.getAction(),body,elementHeaders);
> > return (String)handler.fromXML(retElement);
> > }
> >
> > I don't think adding that two operations to an upper level (say
> > AbstractResourceClient) would be too much trouble.
> >
> > On 12/12/06, Daniel Jemiolo <da...@us.ibm.com> wrote:
> > > We added some support for this in 2.1, although it may not be perfect
> > > (suggestions are welcome). Here's the JavaDoc on the method that
> clients
> > > can call down to in order to send custom headers with their request:
> > >
> > >
> > > http://ws.apache.org/muse/docs/2.1.
> >
> 0/javadoc/org/apache/muse/core/AbstractResourceClient.html#invoke(java.lang.
> > String,%20org.w3c.dom.Element,%20org.w3c.dom.Element[])
> > >
> > >
> > > You can change the generated client method implementation to use this
> > > invoke() instead of the normal one, giving you the opportunity to
> provide
> > > custom headers.
> > >
> > > One issue with providing the headers through some other means
> > > (addHeader(), etc.) is that the clients are stateless. Any alternative
> > > would either need to handle this stateless-ness or suggest a stateful
> > > solution that isn't too hard to use.
> > >
> > > Dan
> > >
> > >
> > >
> > > "José Antonio Sánchez" <ge...@gmail.com> wrote on 12/12/2006
> 12:16:24
> > > PM:
> > >
> > > > When I generate a client stub in Axis2 I can use the method
> > > > stub._getServiceClient().addHeader(OMElement element) to add a
> custom
> > > > element to the request's SOAP header but I cannot find something
> > > > similar in the Muse proxy. Is there a way to use a generated proxy
> and
> > > > to add a custom element to the header?
> > > > If there is no direct method to do this, is it safe to use a
> > > > ResourceParameter in the EndpointReference to send that custom
> > > > message?
> > > > --
> > > > Saludos.
> > > > José Antonio Sánchez
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > 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
> > >
> > >
> >
> >
> > --
> > Saludos.
> > José Antonio Sánchez
> >
> > ---------------------------------------------------------------------
> > 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-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-dev-help@ws.apache.org
>
>
--
Saludos.
José Antonio Sánchez
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
Re: Can I add custom header elements in a proxy request?
Posted by Daniel Jemiolo <da...@us.ibm.com>.
I agree that the design is easy to understand, but there are consequences
from making the client stateful. Right now, multiple threads
(request-handling code) can share a single client object to send messages
to another resource. By storing custom headers in the client object prior
to method invocation, we create a number of issues around synchronization;
since adding the headers and invoking the method are not part of an atomic
operation, it's possible that two threads sharing a client object can
interrupt each other and cause messages to be sent out with the wrong
headers.
The solutions to this are:
1. Document the fact that the client is not thread-safe and instruct users
to wrap all uses of client objects in a synchronized() block.
2. Document the fact that the client is not thread-safe and instruct users
to create a new client object for each new request (or session).
3. Keep the client stateless, but add better overloaded methods for custom
headers in invoke().
4. Keep the client stateless, but provide a code generation option/flag
that causes wsdl2java to create an extra Element[] parameter for custom
headers. Something like:
wsdl2java -wsdl MyResource.wsdl -headers
I think that #1 is problematic because it goes against the "principle of
least surprise"; in other words, I don't think most people will read the
muse-core JavaDoc prior to trying to use the code, nor should they really
have to.
#2 may be a performance problem for large-transaction enviroments. If a
resource is sending out a lot of notifications, for example, that's a lot
of object creation/throw away for the heap.
#3 is the current solution, and is not easy to use. It was a quick hack
that should be replaced/improved.
I think that #4 would be fairly easy to implement, assuming it was a
resource-wide flag. The presence of the flag would just indicate to
wsdl2java that it should add an extra parameter named "Element[]
customHeaders" at the time of code generation. You could then use the same
code you'd be using to build the header elements (for addHeaders()) and
supply them directly to the method being invoked. The next request would
not be affected by the header usage.
Thoughts? Or another idea?
"José Antonio Sánchez" <ge...@gmail.com> wrote on 12/14/2006 10:31:48
AM:
> What I did was to add a list of Element named "headers" to the proxy
> class and two new methods (addHeader(Element) and removeHeaders()),
> then I changed the invoke method to include that headers. That is the
> code of a modified operation:
>
> private Vector<Element> headers = new Vector<Element>();
>
>
> public void addHeaderElement(Element header) {
> headers.add(header);
>
> }
>
> public void removeAllHeaders() {
> headers.removeAllElements();
> }
>
> public String install(URI packageLocation)
> throws SoapFault
> {
> Object[] params = new Object[1];
>
> params[0] = packageLocation;
>
> ProxyHandler handler = getHandler("install");
> Element body = handler.toXML(params);
> Element[] a = {};
> Element[] elementHeaders = headers.toArray(a);
> Element retElement =
invoke(handler.getAction(),body,elementHeaders);
> return (String)handler.fromXML(retElement);
> }
>
> I don't think adding that two operations to an upper level (say
> AbstractResourceClient) would be too much trouble.
>
> On 12/12/06, Daniel Jemiolo <da...@us.ibm.com> wrote:
> > We added some support for this in 2.1, although it may not be perfect
> > (suggestions are welcome). Here's the JavaDoc on the method that
clients
> > can call down to in order to send custom headers with their request:
> >
> >
> > http://ws.apache.org/muse/docs/2.1.
>
0/javadoc/org/apache/muse/core/AbstractResourceClient.html#invoke(java.lang.
> String,%20org.w3c.dom.Element,%20org.w3c.dom.Element[])
> >
> >
> > You can change the generated client method implementation to use this
> > invoke() instead of the normal one, giving you the opportunity to
provide
> > custom headers.
> >
> > One issue with providing the headers through some other means
> > (addHeader(), etc.) is that the clients are stateless. Any alternative
> > would either need to handle this stateless-ness or suggest a stateful
> > solution that isn't too hard to use.
> >
> > Dan
> >
> >
> >
> > "José Antonio Sánchez" <ge...@gmail.com> wrote on 12/12/2006
12:16:24
> > PM:
> >
> > > When I generate a client stub in Axis2 I can use the method
> > > stub._getServiceClient().addHeader(OMElement element) to add a
custom
> > > element to the request's SOAP header but I cannot find something
> > > similar in the Muse proxy. Is there a way to use a generated proxy
and
> > > to add a custom element to the header?
> > > If there is no direct method to do this, is it safe to use a
> > > ResourceParameter in the EndpointReference to send that custom
> > > message?
> > > --
> > > Saludos.
> > > José Antonio Sánchez
> > >
> > >
---------------------------------------------------------------------
> > > 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
> >
> >
>
>
> --
> Saludos.
> José Antonio Sánchez
>
> ---------------------------------------------------------------------
> 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-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
Re: Can I add custom header elements in a proxy request?
Posted by Daniel Jemiolo <da...@us.ibm.com>.
I agree that the design is easy to understand, but there are consequences
from making the client stateful. Right now, multiple threads
(request-handling code) can share a single client object to send messages
to another resource. By storing custom headers in the client object prior
to method invocation, we create a number of issues around synchronization;
since adding the headers and invoking the method are not part of an atomic
operation, it's possible that two threads sharing a client object can
interrupt each other and cause messages to be sent out with the wrong
headers.
The solutions to this are:
1. Document the fact that the client is not thread-safe and instruct users
to wrap all uses of client objects in a synchronized() block.
2. Document the fact that the client is not thread-safe and instruct users
to create a new client object for each new request (or session).
3. Keep the client stateless, but add better overloaded methods for custom
headers in invoke().
4. Keep the client stateless, but provide a code generation option/flag
that causes wsdl2java to create an extra Element[] parameter for custom
headers. Something like:
wsdl2java -wsdl MyResource.wsdl -headers
I think that #1 is problematic because it goes against the "principle of
least surprise"; in other words, I don't think most people will read the
muse-core JavaDoc prior to trying to use the code, nor should they really
have to.
#2 may be a performance problem for large-transaction enviroments. If a
resource is sending out a lot of notifications, for example, that's a lot
of object creation/throw away for the heap.
#3 is the current solution, and is not easy to use. It was a quick hack
that should be replaced/improved.
I think that #4 would be fairly easy to implement, assuming it was a
resource-wide flag. The presence of the flag would just indicate to
wsdl2java that it should add an extra parameter named "Element[]
customHeaders" at the time of code generation. You could then use the same
code you'd be using to build the header elements (for addHeaders()) and
supply them directly to the method being invoked. The next request would
not be affected by the header usage.
Thoughts? Or another idea?
"José Antonio Sánchez" <ge...@gmail.com> wrote on 12/14/2006 10:31:48
AM:
> What I did was to add a list of Element named "headers" to the proxy
> class and two new methods (addHeader(Element) and removeHeaders()),
> then I changed the invoke method to include that headers. That is the
> code of a modified operation:
>
> private Vector<Element> headers = new Vector<Element>();
>
>
> public void addHeaderElement(Element header) {
> headers.add(header);
>
> }
>
> public void removeAllHeaders() {
> headers.removeAllElements();
> }
>
> public String install(URI packageLocation)
> throws SoapFault
> {
> Object[] params = new Object[1];
>
> params[0] = packageLocation;
>
> ProxyHandler handler = getHandler("install");
> Element body = handler.toXML(params);
> Element[] a = {};
> Element[] elementHeaders = headers.toArray(a);
> Element retElement =
invoke(handler.getAction(),body,elementHeaders);
> return (String)handler.fromXML(retElement);
> }
>
> I don't think adding that two operations to an upper level (say
> AbstractResourceClient) would be too much trouble.
>
> On 12/12/06, Daniel Jemiolo <da...@us.ibm.com> wrote:
> > We added some support for this in 2.1, although it may not be perfect
> > (suggestions are welcome). Here's the JavaDoc on the method that
clients
> > can call down to in order to send custom headers with their request:
> >
> >
> > http://ws.apache.org/muse/docs/2.1.
>
0/javadoc/org/apache/muse/core/AbstractResourceClient.html#invoke(java.lang.
> String,%20org.w3c.dom.Element,%20org.w3c.dom.Element[])
> >
> >
> > You can change the generated client method implementation to use this
> > invoke() instead of the normal one, giving you the opportunity to
provide
> > custom headers.
> >
> > One issue with providing the headers through some other means
> > (addHeader(), etc.) is that the clients are stateless. Any alternative
> > would either need to handle this stateless-ness or suggest a stateful
> > solution that isn't too hard to use.
> >
> > Dan
> >
> >
> >
> > "José Antonio Sánchez" <ge...@gmail.com> wrote on 12/12/2006
12:16:24
> > PM:
> >
> > > When I generate a client stub in Axis2 I can use the method
> > > stub._getServiceClient().addHeader(OMElement element) to add a
custom
> > > element to the request's SOAP header but I cannot find something
> > > similar in the Muse proxy. Is there a way to use a generated proxy
and
> > > to add a custom element to the header?
> > > If there is no direct method to do this, is it safe to use a
> > > ResourceParameter in the EndpointReference to send that custom
> > > message?
> > > --
> > > Saludos.
> > > José Antonio Sánchez
> > >
> > >
---------------------------------------------------------------------
> > > 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
> >
> >
>
>
> --
> Saludos.
> José Antonio Sánchez
>
> ---------------------------------------------------------------------
> 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: Can I add custom header elements in a proxy request?
Posted by José Antonio Sánchez <ge...@gmail.com>.
What I did was to add a list of Element named "headers" to the proxy
class and two new methods (addHeader(Element) and removeHeaders()),
then I changed the invoke method to include that headers. That is the
code of a modified operation:
private Vector<Element> headers = new Vector<Element>();
public void addHeaderElement(Element header) {
headers.add(header);
}
public void removeAllHeaders() {
headers.removeAllElements();
}
public String install(URI packageLocation)
throws SoapFault
{
Object[] params = new Object[1];
params[0] = packageLocation;
ProxyHandler handler = getHandler("install");
Element body = handler.toXML(params);
Element[] a = {};
Element[] elementHeaders = headers.toArray(a);
Element retElement = invoke(handler.getAction(),body,elementHeaders);
return (String)handler.fromXML(retElement);
}
I don't think adding that two operations to an upper level (say
AbstractResourceClient) would be too much trouble.
On 12/12/06, Daniel Jemiolo <da...@us.ibm.com> wrote:
> We added some support for this in 2.1, although it may not be perfect
> (suggestions are welcome). Here's the JavaDoc on the method that clients
> can call down to in order to send custom headers with their request:
>
>
> http://ws.apache.org/muse/docs/2.1.0/javadoc/org/apache/muse/core/AbstractResourceClient.html#invoke(java.lang.String,%20org.w3c.dom.Element,%20org.w3c.dom.Element[])
>
>
> You can change the generated client method implementation to use this
> invoke() instead of the normal one, giving you the opportunity to provide
> custom headers.
>
> One issue with providing the headers through some other means
> (addHeader(), etc.) is that the clients are stateless. Any alternative
> would either need to handle this stateless-ness or suggest a stateful
> solution that isn't too hard to use.
>
> Dan
>
>
>
> "José Antonio Sánchez" <ge...@gmail.com> wrote on 12/12/2006 12:16:24
> PM:
>
> > When I generate a client stub in Axis2 I can use the method
> > stub._getServiceClient().addHeader(OMElement element) to add a custom
> > element to the request's SOAP header but I cannot find something
> > similar in the Muse proxy. Is there a way to use a generated proxy and
> > to add a custom element to the header?
> > If there is no direct method to do this, is it safe to use a
> > ResourceParameter in the EndpointReference to send that custom
> > message?
> > --
> > Saludos.
> > José Antonio Sánchez
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
Saludos.
José Antonio Sánchez
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
Re: Can I add custom header elements in a proxy request?
Posted by Daniel Jemiolo <da...@us.ibm.com>.
We added some support for this in 2.1, although it may not be perfect
(suggestions are welcome). Here's the JavaDoc on the method that clients
can call down to in order to send custom headers with their request:
http://ws.apache.org/muse/docs/2.1.0/javadoc/org/apache/muse/core/AbstractResourceClient.html#invoke(java.lang.String,%20org.w3c.dom.Element,%20org.w3c.dom.Element[])
You can change the generated client method implementation to use this
invoke() instead of the normal one, giving you the opportunity to provide
custom headers.
One issue with providing the headers through some other means
(addHeader(), etc.) is that the clients are stateless. Any alternative
would either need to handle this stateless-ness or suggest a stateful
solution that isn't too hard to use.
Dan
"José Antonio Sánchez" <ge...@gmail.com> wrote on 12/12/2006 12:16:24
PM:
> When I generate a client stub in Axis2 I can use the method
> stub._getServiceClient().addHeader(OMElement element) to add a custom
> element to the request's SOAP header but I cannot find something
> similar in the Muse proxy. Is there a way to use a generated proxy and
> to add a custom element to the header?
> If there is no direct method to do this, is it safe to use a
> ResourceParameter in the EndpointReference to send that custom
> message?
> --
> Saludos.
> José Antonio Sánchez
>
> ---------------------------------------------------------------------
> 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