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