Bug 6141 – Getting the service hosts in DelegatedCredentialDestroyHelper is ambiguous

Bug 6141 - Getting the service hosts in DelegatedCredentialDestroyHelper is ambiguous

Summary:

Getting the service hosts in DelegatedCredentialDestroyHelper is ambiguous

Status:	RESOLVED FIXED

Product:	GRAM
Component:	wsrf managed execution job service
Version:	alpha
Platform:	Macintosh All

Importance:	P3 normal
Target Milestone:	4.2
Assigned To:	Martin Feller

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2008-06-09 12:06 by Martin Feller
Modified:	2008-06-09 12:16 (History)

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note

You need to log in before you can comment on or make changes to this bug.

Description From Martin Feller 2008-06-09 12:06:07

To identify whether a credential resource can be destroyed locally or via a
WS call, ServiceHost.getHost() and ServiceHost.getPort() is compared to the
host and port of the address of the EPR of the delegated credential.
However, ServiceHost.getHost() returns an IP or a hostname, depending on
whether a MessageContext is associated with the executing thread.
So in some situations a WS call is done to destroy a transfer credential, even
if RFT (and the credential) is located in the same container.

Solution:
ServiceHost.getDefaultHost() does a better job.