Hi Scott,

Thanks for reviewing the code. 

A method invocation on a local interface calls the standard 
container method invokeHome(MethodInvocation mi) or 
invoke(MethodInvocation mi). From this point on, there is no 
differentiation between a local call and a remote call in terms of the 
path through the architecture (although some methods--such as 
finder methods--behave differently depending on whether they are in 
a remote or local home interface). 

The container calls getInterceptor().invoke(MethodInvocation) or 
getInterceptor().invokeHome(MethodInvocation). The last interceptor 
in the chain is the container's own "interceptor." Again, this 
functionality isn't changed; what changed is the mapping of 
methods to beans that this last interceptor references. (So you use 
the same interceptors for local and remote interfaces.)

On the way back out, I need to swizzle some exceptions that 
inherit from RemoteException (to conform to the specification). 
This swizzling is done in the BaseLocalContainerInvoker.

Is this question just from code review, or did you notice incorrect 
runtime behavior?

-Dan

On 10 Jun 01, at 16:23, Scott M Stark wrote:

> I can't seem to find how the current interceptor architecture plugs into
> the local interfaces method invocation. Does this exist?
> 
> ----- Original Message ----- 
> From: "Dan OConnor" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, June 04, 2001 3:39 PM
> Subject: [JBoss-dev] Local interfaces prototype
> 
> 
> > Hi,
> > 
> > With (much appreciated) help from Jay Walters, I've added a 
> > prototype for support of local interfaces to CVS. There are many 
> > aspects of this I haven't tested (e.g. a bean with both local and 
> > remote interfaces, functionality of the EnterpriseContext, etc.), so I 
> > was hoping that some of you familiar with the EJB 2.0 spec could 
> > use them a little and post problems to this list or Sourceforge bug 
> > tracker... or, of course, fix problems yourself. :-)
> > 
> > I'm not posting this announcement to jboss-user because local 
> > interface support definitely needs a little time to cook before it 
> > enters general use. Please help me to cook it. Anyone who 
> > disagrees with this may go ahead and cross post without further 
> > discussion. :-) 
> > 
> > Just a quick design note for the code reviewers: I modeled local 
> > interface support on the JRMP container invoker whenever 
> > possible, so that someone familiar with that code base would 
> > instantly understand what I was doing. However, I thought it better 
> > not to add local interface support to the existing pluggable 
> > ContainerInvoker system. This is because the local interfaces 
> > implementation can remain constant as the distribution mechanism 
> > (e.g. RMI/JRMP, CORBA, whatever...) changes. So local interfaces 
> > are broken out.
> > 
> > Also, you'll notice that I do not publish the home interface in our 
> > JNDI system, except in a component name space when a bean 
> > uses an ejb-local-ref. There is no reason to make the home globally 
> > available, since local interfaces will only work for components 
> > within an application. So instead, I publish the interfaces to the 
> > application class.
> > 
> > Finally, I made a small change to the verifier so it doesn't throw an 
> > exception when a bean without remote interfaces is deployed. 
> > However, you should know the local interfaces are not verified. 
> > (Quick reminder: don't throw java.rmi.RemoteException.)
> > 
> > -Dan O'Connor
> > 
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> > 
> 
> 
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development



_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to