There seems to be a bug in 
org.jboss.invocation.InvokerInterceptor.isLocal(Invocation). Or at least I am 
unable to figure out how naming lookups from one JBoss instance to another are 
supposed to work with this code in InvokerInterceptor:

   public boolean isLocal(Invocation invocation)
   {
      return localInvoker != null && 
Registry.lookup(invocation.getObjectName()) != null;
   }

When NamingServer is bound in Registry in all instances with the same id:

14:17:59,704 DEBUG [HttpProxyFactory] Created HttpInvokerProxy for 
invoker=jboss:service=Naming, nameHash=349114835

And when cluster B tries to look up cluster A's naming server in order to find 
the session bean for which it works as a delegate, Registry always finds the 
naming server which exists in cluster B with the same id.

Working code from 3.2.5 InvokerInterceptor:

   public boolean isLocal()
   {
      return invokerID.equals(Invoker.ID);
   }

I'll write my own implementation of InvokerInterceptor for use in delegate bean 
lookups, and a LocalInvoker which sets local invoker instance in this custom 
InvokerInterceptor instance. What I would like to know is am I right, whether 
what I found is a bug, should I report it, and is there possible problems with 
reverting to 3.2.5 behaviour for InvokerInterceptor.isLocal().


View the original post : 
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883064#3883064

Reply to the post : 
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883064


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
JBoss-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jboss-user

Reply via email to