Jason Dillon wrote:
> I spent some time (long ago...) fixing this very problem, but I have not
> really had time to integrate it into the latest codeline. I can put some
> more effort into fixing this soon.
I really would appreciate that.
> Does anyone happen to know what the EJB spec says about handles and if they
> should return bean refs to the *exact* server which they came from? I can
> not recall any real detail about handles except that they are used to allow
> clients to restore a reference to a given bean.
I don't think so. In a clustering environment, that cannot be guaranteed anyway. The
spec (1.1) talks about handles in section 8.7 and 8.8.
> Any ways, I do not think that this will take that long to fix. I can
> probably make this optional too (via a property that will enable the new
> behavior). The only problem that I remember running into was when the proxy
> is generated there isn't an easy way to find out what the provider url is for
> the current machine (in a non-jboss specific fashion). Perhaps that has
> changed.
>
> What I might do is force users who are interested in this, to provide some
> extra properties (or another jndi properties file) that specifies the exact
> environment properties required to restore a bean from a handle.
I think, that is the best way, because you cannot determine the host name of a server.
-alf
> --jason
>
>
> On Thu, 26 Apr 2001, Alf Werder wrote:
>
>
>> Hi,
>>
>> The last two months I made my first experiences with jboss as a bean
>> developer. I am really surprised and impressed by the work, that is
>> done. But now, the first serious problem arised.
>>
>> In an EJB client a tried to obtain the home interface of a bean from its
>> remote interface. But a call to EJBObject.getEJBHome() throws an
>> exception. That was the first sign. Later, I tried to use a HomeHandle
>> to reobtain a home interface after a server restart.
>> HomeHandel.getEJBHome() throws an exception.
>>
>> I had a deeper look and found the problem: My code was
>>
>> Hashtable env = new Hashtable();
>> env.put("java.naming.factory.initial",
>> "org.jnp.interfaces.NamingContextFactory");
>> env.put("java.naming.provider.url", "localhost:1099");
>> env.put("java.naming.factory.url.pkgs", "org.jboss.naming");
>>
>> MyHome home = (MyHome) new InitialContext(env).lookup("MyHome");
>> MyHome h = (MyHome) home.getHomeHandle().getEJBHome();
>>
>> The last line throws the exception. It works, when I change the code to:
>>
>> Hashtable env = new Hashtable();
>> System.setProperty("java.naming.factory.initial",
>> "org.jnp.interfaces.NamingContextFactory");
>> System.setProperty("java.naming.provider.url", "localhost:1099");
>> System.setProperty("java.naming.factory.url.pkgs", "org.jboss.naming");
>>
>> MyHome home = (MyHome) new InitialContext().lookup("MyHome");
>> MyHome h = (MyHome) home.getHomeHandle().getEJBHome();
>>
>> So had a look into the jboss source code. The HomeHandle implementation
>> simply does not know the server, is came from. It just creates a new
>> inital context without any Arguments. So it gets the local root context,
>> which is not the context its home interface is bound to.
>>
>> -alf
>>
>>
>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
--
Alf Werder | System Engineering | TOMORROW Technologies GmbH
Oberstra�e 14b | D-20144 Hamburg
Mail: [EMAIL PROTECTED]
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
