app client jndi

[David Jencks <dj...@gluecode.com>]

I'm not 100% sure I understand the current app client jndi handling, 
but my impression is that jndi lookup pulls the read only context back 
from the server.

Is there some reason the read-only-context is not packed into the app 
client configuration so that no lookup communication to the server is 
needed?  I would expect this to be simpler and faster.  It also would 
not have introduced bugs in the non-app client jndi.

Please explain.

thanks
david jencks

Re: app client jndi

[Dain Sundstrom <ds...@gluecode.com>]

On Sep 24, 2004, at 12:20 AM, David Jencks wrote:

> I'm not 100% sure I understand the current app client jndi handling, 
> but my impression is that jndi lookup pulls the read only context back 
> from the server.
>
> Is there some reason the read-only-context is not packed into the app 
> client configuration so that no lookup communication to the server is 
> needed?  I would expect this to be simpler and faster.

Actually this is way simpler.  In one fell swoop we connect to the 
server and pull down the JNDI context and all proxies in the tree write 
replaced in the object output stream to be connected to the current 
server.  This has a lot of nice side effects.  First is it is really 
fast as we only have a single communication with the server at startup 
for all JNDI lookups. Also, we don't have to have special code on the 
client side to have the initially disconnected proxy find the server.  
We can reuse all enc creation code in the deployment code without any 
change.  We can support lookup of objects that are not EJBs (the 
current JNDI code only supports EJBs).

Now I'm not 100% sure that we won't need special code on the client and 
special enc  creation code, but this solution is simple and should 
work.

> It also would not have introduced bugs in the non-app client jndi.

That is because I made David check it in before he was ready, so I 
could begin working with the app client side.  He is fixing the bug.

-dain