-
1. Re: Determine whether an invocation is local or remote
bdecoste Mar 27, 2008 12:14 PM (in response to anil.saldhana)That should be fine - IsLocalInterceptor sticks the IS_LOCAL, IS_LOCAL metadata flag into the invocation if the client is local to the bean instance. The is local vs remote, not Local vs Remote.
-
2. Re: Determine whether an invocation is local or remote
alrubinger Mar 27, 2008 3:45 PM (in response to anil.saldhana)Is it OK to introduce this dependency from security interceptors to IsLocalInterceptor?
Isn't the nature of interceptors to be cross-cutting and configurable such that any can be added/removed to change functionality?
S,
ALR -
3. Re: Determine whether an invocation is local or remote
anil.saldhana Mar 27, 2008 3:49 PM (in response to anil.saldhana)"ALRubinger" wrote:
Is it OK to introduce this dependency from security interceptors to IsLocalInterceptor?
Isn't the nature of interceptors to be cross-cutting and configurable such that any can be added/removed to change functionality?
S,
ALR
Good point. In my opinion there should just be a flag on the invocation whether the call was intra-vm or intervm. -
4. Re: Determine whether an invocation is local or remote
bdecoste Mar 27, 2008 3:53 PM (in response to anil.saldhana)Generally. The containers already have a dependency on the IS_LOCAL settings that IsLocalInterceptor sets in order to know whether to marshall the response.
If a user removed IsLocalInterceptor, we behave as if it's always a remote call and go through rmi and marshall everything. The question is, if the user removed it, what would security do? It would treat it as a remote call? -
5. Re: Determine whether an invocation is local or remote
bdecoste Mar 27, 2008 3:55 PM (in response to anil.saldhana)Setting a local vs remote flag in the invocation is exactly what IsLocalInterceptor does.
-
6. Re: Determine whether an invocation is local or remote
alrubinger Mar 27, 2008 4:03 PM (in response to anil.saldhana)"bdecoste" wrote:
Generally. The containers already have a dependency on the IS_LOCAL settings that IsLocalInterceptor sets in order to know whether to marshall the response.
If a user removed IsLocalInterceptor, we behave as if it's always a remote call and go through rmi and marshall everything. The question is, if the user removed it, what would security do? It would treat it as a remote call?
So the containers don't really have a dependency then? Just take advantage of optimization if a flag's available in invocation metadata?
We should be able to fall back gracefully. :)
S,
ALR -
7. Re: Determine whether an invocation is local or remote
alrubinger Mar 27, 2008 4:06 PM (in response to anil.saldhana)"anil.saldhana@jboss.com" wrote:
Good point. In my opinion there should just be a flag on the invocation whether the call was intra-vm or intervm.
Why not put a VMID in the Invocation at the container/core level, along with a method "boolean isLocalInvocation()" in EJBContainer, and then the security interceptor can call upon that? Then the interceptors would depend on the containers, not each other.
S,
ALR -
8. Re: Determine whether an invocation is local or remote
anil.saldhana Mar 27, 2008 4:16 PM (in response to anil.saldhana)The EJB2 proxy interceptors that deal with transport (InvokerInterceptor) use GUID (which is UUID actually and underneath uses the RMI vmid). I bank on this one to set the invocation to be intervm. Maybe we need this thing moved over to ejb3 world.
-
9. Re: Determine whether an invocation is local or remote
bdecoste Mar 27, 2008 4:25 PM (in response to anil.saldhana)We pretty much do the same thing just in IsLocalInterceptor. If you wanted to remove the potential problem if a user removing the interceptor, the GUID/VMID would need to go into the proxy impl. There is already a containerGuid in the proxies which contains the VMID where the proxy was created as well as the ObjectName of the container.
-
10. Re: Determine whether an invocation is local or remote
wolfc Mar 27, 2008 5:23 PM (in response to anil.saldhana)Remove the logic from IsLocalInterceptor. This also eliminates the dependency of the proxies on IsLocalInterceptor. The proxy itself already has (almost) all the knowledge to make the decision, so it can set the flag itself.
Make sure this flag is accessed via a strong typed api where we control the key name for that piece of invocation metadata.
As an interim I don't mind having a static method isLocalVMInvocation in IsLocalInterceptor. That at least centralizes the logic. -
11. Re: Determine whether an invocation is local or remote
alrubinger Mar 27, 2008 5:28 PM (in response to anil.saldhana)"wolfc" wrote:
As an interim I don't mind having a static method isLocalVMInvocation in IsLocalInterceptor. That at least centralizes the logic.
Unless this saves us significant time, I'd mind. :)
We've got enough TODOs sprinkled about, we'll never have dedicated time to refactor for cleanliness, so "do it right, do it once".
S,
ALR -
12. Re: Determine whether an invocation is local or remote
bdecoste Mar 27, 2008 5:33 PM (in response to anil.saldhana)"Do it right, do it once" is why we are constantly late. At some point you just need to "Get it to work, ship it".
My 2 cents is to just move the same flag from ILI to the proxy and leave the container alone. Then ILI just has the marshalling logic for local @Remote calls. -
13. Re: Determine whether an invocation is local or remote
bdecoste Mar 27, 2008 5:37 PM (in response to anil.saldhana)That way Anil just grabs the flag from the metadata like he is doing now and you can remove ILI without any impact.
-
14. Re: Determine whether an invocation is local or remote
anil.saldhana Mar 27, 2008 5:47 PM (in response to anil.saldhana)The logic to determine remote/local call is at many places in the ejb3 codebase such as:
http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/core/src/main/java/org/jboss/ejb3/asynchronous/AsynchronousInterceptor.java
Eventually this needs to be cleaned up (as Carlo said).