Hi Scott,
Please find my answers below.
Regards,
Radostin
On 28.10.2010 г. 17:21, Scott Lewis wrote:
Hi Radostin,
Thanks for the description of your work.
A couple of comments below.
On 10/28/2010 1:50 AM, Radostin Surilov wrote:
Hi Scott,
Thank you for the comments.
I suppose this approach is quite specific to our use
case. The actual aspect is:
import
org.eclipse.ecf.provider.remoteservice.generic.RemoteCallImpl;
import
org.eclipse.ecf.provider.remoteservice.generic.Request;
import
org.eclipse.ecf.provider.remoteservice.generic.RemoteServiceRegistrationImpl;
public aspect ECFRequestExtAspect {
private ISecurityToken
RemoteCallImpl.mSecurityToken; //serializable
parameter to pass (security token in this case)
//advice executed after a new request object has
been created
after(Request request) returning :
initialization(Request+.new(..)) &&
this(request) {
//put the (local) security context in the
RemoteCallImpl instance of the request
request.getCall().mSecurityToken =
SecurityContextHolder.getContext().getToken();
}
//advice executed before the remote service method
invocation
before(RemoteCallImpl remoteCall) : execution(*
RemoteServiceRegistrationImpl.callService(RemoteCallImpl))
&& args(remoteCall) {
//get the security context from the
RemoteCallImpl instance and put it in a thread local
SecurityContextHolder.getContext().setToken(remoteCall.mSecurityToken);
}
}
Regards,
Radostin
Interesting. I take it from your description that you
are able to implement this by extending relevant classes
and by overriding methods in RegistrySharedObject (in
ECF 3.4)...is that correct?
Yes, although I do not have to explicitly modify or extend
ECF classes...All the work is done by the dynamic and static
crosscutting constructs of the aspect. I just have to put
this aspect in a bundle and start it in all platforms
(together with the equinox aspects bundles, etc). Not sure
to fully understand your question - would you need more
details?
Based upon this use case, do you have any desired API
additions/changes...that might accomodate this use case
and others more easily/gracefully (e.g. without having
to extend classes).
Definitely providing API support to accommodate this use
case would lead to a better solution than the fix with the
aspect.
Speaking about our use case we have two problems:
- (client) attaching serializable data to each Request.
- (server) retrieving the attached serializable data from
the Request before the (remote) method execution. This must
be in the thread that actually invokes the method.
Generally, the ECF framework could provide some special
events (e.g. on_request_creation,
before_remote_method_invocation) and allow users code to
attach listeners to these events. However I am not very
familiar with the ECF architecture so do not know if this
makes sense.
