EndPoints/Interceptors - thread Safe

[kkelleher]

Hi,

I have an endpoint class & a number of interceptors, one of which is a security interceptor.
This security interceptor set a static value in the endpoint class.

Is this setup thread safe? I'm unsure!

Is there a better way for interceptors to set values that the endpoint class needs?

thanks in advance,
Kevin

[Marten Deinum]

No it isn't... First the endpoint is a singleton so setting variables is always a no-go next you are setting a static variable which is class loader wide as it is attached to the class and not the instance, so basically even worse.

[kkelleher]

No it isn't... First the endpoint is a singleton so setting variables is always a no-go next you are setting a static variable which is class loader wide as it is attached to the class and not the instance, so basically even worse.

Thank Marten, I only wrote this awful code as right now I see no other "solution" to a problem.

My endpoint needs access to security info in the soap header - namely the username.

The only place where I know I can get access to security info is in my security interceptor. (Unfortunately spring SoapHeader does not give access to this info). In the interceptor I set the static "userName" in the endpoint. The framework passes control to the endpoint once the interceptor is finished doing its work - therefore the endpoint point has access to username.

Is there a proper way of doing what I'm attempting?

[Marten Deinum]

If you can get access to it in the interceptor you can get access to it in the endpoint.

A work around could be instead of setting it in the endpoint to store it in a thread local (like Spring Security does) and use that to retrieve the current credentials, that way it is thread safe.

[kkelleher]

If you can get access to it in the interceptor you can get access to it in the endpoint.

A work around could be instead of setting it in the endpoint to store it in a thread local (like Spring Security does) and use that to retrieve the current credentials, that way it is thread safe.

Thanks Marten, I'll do that. As you say its a workaround.
In the meantime I'll keep looking to solve the "real" problem - why I haven't access to the authorized user name in the endpoint.