On Tuesday 25 January 2011 8:06:43 pm barakka wrote: > Hello, > > I've just noticed that using the IssuedTokenInterceptorProvider along with > WS-RM breaks support for RM. > > In particular, the problem is the following: the IssuedTokenOutInterceptor > in the client stores the TOKEN and TOKEN_ID in the endpoint > (message.getExchange().get(Endpoint.class).put(SecurityConstants.TOKEN_ID, > tok.getId()), line 147 in CXF 2.3.1). On the other hand, the RMManager > keeps a map between the endpoints the reliable endpoints created. The key > of the map is the Endpoint itself. Adding the token to the EndPoint > changes is hashcode (as the endpoint is a map itself and its hashcode > depends on its entries). As such, when the modified EndPoint is looked up > in the > EndPoint-RME map, it is not found, and new RME is created and the sequence > gets out of synch. > > I was not able to understand why the token is stored in the endpoint, as it > seems it never gets read from it (and, moreover, it is already stored in > the token store). I've tried a modified version of the interceptor that > does not store the token (nor the token id) and everything seems to work > correctly, including the RMManager which is not able to complete the > sequence. > > Would it be safe to remove those lines? Should I create a JIRA issue for > this and provide a patch?
Well, there definitely is a bug, but I'm not sure which is the bug that should be logged and fixed. :-) Options: 1) Endpoint should have a .hashCode() that makes more sense. Likely just the hashCode of the endpoint name. Other things like the PolicyIn/OutInterceptors store things on the endpoints and such and thus may cause issues as well. 2) RMMananger - should the Map be some sort of identity map so the hash code is irrelevant? 3) IssuedToken stuff... does it need to stick the token on the endpoint? I'd need to look at this more. I don't really remember why. In anycase, all three might need to be logged and fixed. -- Daniel Kulp [email protected] http://dankulp.com/blog
