atom feed5 messages in net.java.dev.wiseman.devRE: RE: RE: Wiseman incompatible wit...
FromSent OnAttachments
Ting ZhouDec 12, 2007 12:18 pm 
Rachal, DenisDec 13, 2007 12:14 am 
Jean-Francois DeniseDec 13, 2007 12:19 am 
Ting ZhouDec 13, 2007 7:04 pm 
Rachal, DenisDec 17, 2007 12:06 am 
Subject:RE: RE: RE: Wiseman incompatible with WinRM client?
From:Rachal, Denis (deni@hp.com)
Date:Dec 17, 2007 12:06:05 am
List:net.java.dev.wiseman.dev

Hello Ting,

The RequestDispatcher does not know what "Actions" are supported by the handler
and should therefore not set the action in the Response message. Also, there can
be custom actions supported by the handler. In this case there is no way for the
RequestDispatcher to know what to set the response action to. This is also the
case for the DefaultHandler. It only handles the "known" WS Management actions.
The custom actions must still be handled by the handler itself.

Denis Rachal deni@hp.com

Hewlett-Packard GmbH Herrenberger Strasse 140, 71034 Böblingen Geschäftsführer: Hans Ulrich Holdenried (Vorsitzender), Edgar Aschenbrenner,
Heiko Meyer, Ernst Reichart, Matthias Schmidt, Regine Stachelhaus Vorsitzender des Aufsichtsrates: Jörg Menno Harms Sitz der Gesellschaft: Böblingen, Amtsgericht Stuttgart HRB 244081,
WEEE-Reg.-Nr. DE 30409072

________________________________ From: Ting Zhou [mailto:Ting@teneros.com] Sent: Friday, December 14, 2007 4:05 AM To: de@wiseman.dev.java.net Subject: RE: RE: Wiseman incompatible with WinRM client?

Thanks, Denis, Jean-Francois. You are spot-on. Yes, this was my mistake. What
happen was that I didn’t particularly like how handlers are structured in
“traffic_server” sample code. There are generated factory_Handler, list_Handler
and resource_Handler that extends DefaultHandler and are invoked via reflection.
And each of them invokes application-level handlers such as ListHandler and
ResourceHandler. Too complicated for me (I’m not keen on generated code btw). So
what I did was implementing my own Servlet/RequestDispatcher/Handler. Eventually
I just used one hand-crafted Handler class to do all the work. But I missed out
the “magic” in generated *_Handler classes. J

I added response.setAction() to my handler class, and now it works perfectly for
WinRM.

BTW, in the latest binary distribution (I wasn’t using the latest), I noticed
the generated handler classes were condensed to just one
(lightresource_Handler). But still all that class does is setting the response
action, which seems like waste. I’m wondering why “setting response action” part
cannot be moved up, to say RequestDispatcher…

Again, thanks a lot for the insight and help.

Ting

From: Rachal, Denis [mailto:deni@hp.com] Sent: Thursday, December 13, 2007 12:14 AM To: de@wiseman.dev.java.net Subject: RE: Wiseman incompatible with WinRM client?

Helli Ting,

What does your handler look like? Does it extend "DelegatingHandler" or
"DefaultHandler". If not, then you will have to set the action yourself. This is
done for you in the DefaultHandler.handle() method.

Denis Rachal deni@hp.com

Hewlett-Packard GmbH Herrenberger Strasse 140, 71034 Böblingen Geschäftsführer: Hans Ulrich Holdenried (Vorsitzender), Edgar Aschenbrenner,
Heiko Meyer, Ernst Reichart, Matthias Schmidt, Regine Stachelhaus Vorsitzender des Aufsichtsrates: Jörg Menno Harms Sitz der Gesellschaft: Böblingen, Amtsgericht Stuttgart HRB 244081,
WEEE-Reg.-Nr. DE 30409072

________________________________ From: Ting Zhou [mailto:Ting@teneros.com] Sent: Wednesday, December 12, 2007 9:19 PM To: de@wiseman.dev.java.net Subject: Wiseman incompatible with WinRM client? I implemented a WSMAN server using Wiseman API for one of my projects. It worked
great for Linux clients such as Openwsman. But when I tried to do the same from
Windows client, specifically the new WinRM, I noticed some incompatibility
issue. Wiseman apparently understands the request sent from WinRM, and seemingly
returns the right data. But WinRM chocked on the response. Here is what it
complains:

WSManFault Message = WS-Management cannot process the request. The element a:Action is missing from the response sent by the destination computer.

Error number: -2144108301 0x803380F3 The WinRM client cannot process the request. The response from the destination computer contains one or more invalid SOAP headers.

Apparently WinRM is looking for something like this in the response header:

<wsa:Action
s:mustUnderstand="true">http://schemas.xmlsoap.org/ws/2004/09/enumeration/EnumerateResponse</wsa:Action<http://schemas.xmlsoap.org/ws/2004/09/enumeration/EnumerateResponse%3c/wsa:Action>>

Which is not present. FYI, Here is entire header in the Wiseman response:

<env:Header> <wsman:TotalItemsCountEstimate xmlns="">1</wsman:TotalItemsCountEstimate> <wsa:MessageID xmlns=""
env:mustUnderstand="true">uuid:91249b56-ebb4-4683-b806-ff77a4c800db</wsa:MessageID> <wsa:RelatesTo
xmlns="">uuid:581fdc21-411c-111c-8002-f20a2a290c00</wsa:RelatesTo> <wsa:To xmlns=""
env:mustUnderstand="true">http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To> </env:Header> <env:Body>

I went back to WS-Management spec by DMTF. The spec does mention “wsa:Action” in
required as part of WS-Addressing header (R2.2-1). So this seems to be a bug on
Wiseman-side and WinRM is doing the right thing by rejecting the response…

The marshalling of WS-Addressing header part is done entirely by Wiseman
protocol handling layer. I’m not sure if I can do anything on the application
layer to fix this.

Any thoughts? Has anyone actually made Wiseman work for WinRM?

-Ting

Ting Zhou Project Lead, NOC Engineering Teneros Inc.