Hi Radostin,
On 10/27/2010 10:19 AM, Radostin Surilov wrote:
Hi Franky, hi Scott,
Franky, thanks for letting me know about the previous discussion -
it is indeed quite similar to what I'm doing.
More about our use case - when a request to a remote service is
executed, the security context has to be passed together with the
request. The remote platform should receive the request and put
the context in a thread local (before the actual method
execution), so the security details are available for the current
call stack.
Scott, I understand that something similar should be provider
specific, so I am using ecf generic provider.
One thing to make clear: although there is no problem with using
the ecf generic provider, the code in
org.eclipse.ecf.provider.remoteservice bundle does *not* depend upon
the ECF generic provider (yes, I know the package name
org.eclipse.ecf.provider.remoteservice.generic makes it sound like
that, but that's an unfortunate package name that I now cannot
change without breaking existing API).
Rather, the org.eclipse.ecf.provider.remoteservice depends upon the
shared object API...and this API is currently implemented by several
providers: xmpp, jms, javagroups providers. This allows *all* of
these to reuse the RegistrySharedObject (and the Request/Response
classes).
The solution I found so far is based on aspects. We are weaiving
org.eclipse.ecf.provider.remoteservice so:
- When a new
org.eclipse.ecf.provider.remoteservice.generic.Request is created
the security context is put in the RemoteCallImpl instance of the
Request.
- Before each execution of the
org.eclipse.ecf.provider.remoteservice.generic.RemoteServiceRegistrationImpl.callService(RemoteCallImpl)
the security context is get from the RemoteCallImpl parameter and
put in a thread local.
Do you see any problems with this approach or maybe suggest a more
elegant solution?
I don't see any problems with this. I think the discussion about
more elegant solution can be had around whether or not some new API
should be added to either ECF remoteservices...or the
RegistrySharedObject...but I think given your use case what you've
done makes sense. And I assume it's working for you.
If you are willing, maybe you could share the Request/Response
subclasses and the RegistrySharedObect subclasses, and that would
allow Franky and all of us to see if there are things that could be
generalized to meet several authentication use cases with future API
additions/changes.
Thanks,
Scott
|