Hi Jiandong,
The assertion is back. Now that the other pieces of the test harness are
working, I again see that same assertion because the trust code calls
[getAppliationScopedProperties()]. I have integrated my harness changes
into the main WSIT workspace. So, now the wsit-e2e-test-local job
results show the error output. [1] Seems to be getting onto a codepath
that must not be invoked when using http transports or this would have
surfaced. I'd be glad to help in debugging this further.
thanks,
Ken
[1]
http://kohsuke.sfbay/hudson/job/wsit-e2e-test-local/209/testReport/wstrust.scenario5/client%20test_bsh/wstrust_scenario5_client_test_bsh/
Ken Hofsass wrote:
> Hi Jiandong,
>
> With the newer wsit & jaxws 2.1 code that particular problem doesn't
> happen. The test still fails but the current problem is a bug in the
> test harness itself... there is a bug in 'patching' the location of
> the STS endpoint for use with local transport. I'm working on
> correcting that and should have it fixed today. I'll let you know
> whether the test is successful or not as soon as I can. I'm excited
> to see it work finally.
>
> Thanks a lot for following up!
> Ken
>
> Jiandong Guo wrote:
>
>> Hi Ken,
>>
>> How is going with this?
>>
>> Jiandong
>>
>> Ken Hofsass wrote:
>>
>>> Jiandong,
>>>
>>> I know you're probably swamped with the jaxws 2.1 migration right
>>> now, but when you have a chance I would appreciate your help on the
>>> following issue...
>>>
>>> The wstrust test (scenario5) we've automated with the harness
>>> fails. The failure is caused by SecurityServerPipe.process()
>>> calling into Packet.getApplicationScopedProperties() with
>>> Constants.SUN_TRUST_SERVER_SECURITY_POLICY_NS.
>>> In the last pre-jaxws2.1 version of SecurityServerPipe.java (1.13)
>>> it's at line 215 or line 187 in the latest version (1.14). I'm
>>> using the WSIT tree from Monday afternoon, a few hours before Arun
>>> checked in the JAXWS 2.1 jars.
>>>
>>> Kohsuke changed getApplicationScopedProperties to 'assert false'
>>> immediately a while back. This seems to indicate that the test
>>> harness run is getting in a block of code in
>>> SecurityServerPipe.process() that is not normally executed...
>>>
>>> This failure code path might occur because the harness is using
>>> local transport. (I'll try it with http and see if happens too). Or
>>> it could be a bug or config error with the e2e harness. If you
>>> could take a look and let me know if you see anything obvious, that
>>> would be great.
>>>
>>> thanks,
>>> Ken
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_ws-test-harness.dev.java.net
> For additional commands, e-mail: dev-help_at_ws-test-harness.dev.java.net
>