Alex, are you confusing a particular deployments' JNDI ENC (e.g. for an
ejb ear or war) from JNDI in general? They're very different things.
On Friday, August 29, 2003, at 12:22 pm, Alex Blewitt wrote:
On Friday, Aug 29, 2003, at 12:25 Europe/London, Richard Monson-Haefel
wrote:
On 8/29/03 12:36 AM, in article
[EMAIL PROTECTED], "Alex Blewitt"
<[EMAIL PROTECTED]> wrote:
On Friday, Aug 29, 2003, at 08:55 Europe/London, Richard
Monson-Haefel
wrote:
All this sounds great, Alex, but I’m a little concerned that its
overkill for the JNDI ENC. The JNDI ENC is totally static at
runtime
(per deployment) and therefore a very simple, and fast, in-memeory
caching strategy works best.
Is this necessarily the case? It has to be able to start up EJBs and
write into the JNDI ENC during runtime; if it is going to support
on-the-fly deployment of other EJBs, I'd say that it must be able to
handle additional extras inserted in at runtime.
Well, not really. Each deployment's ENC is static, so if you deploy
a bean,
the container simply creates its ENC at that moment, but once its
created
its static. It cannot be changed by the bean nor can any values be
modified,
bound or unbound.
Actually, that is not the case ...
I also don't see why code cannot necessarily register additional
things
in the JNDI ENC, such as other databases populated by an
initialisation
code. I know that it's not likely that this will be the case, but
assuming that it is totally static seems a wrong decision.
That's just the way it is. J2EE specifies that the JNDI ENC is
read-only. If
you want to access a non-static JNDI resource, you must connect to it
explicitly.
Not directly true ...
Of course caching is always likely to provide better performance in
any
case, but it still does not have to be static.
If you want it to be conformant it does.
What the J2EE spec says (J2EE 5.2.4):
"The container must ensure that the application component instances
have only
read access to their environment variables. The container must throw
the
javax.naming.OperationNotSupportedException from all the methods of the
javax.naming.Context interface that modify the environment naming
context
and its subcontexts."
What this means is the /client's/ view is unmodifiable -- it does not
say that the JNDI namespace/back-end is unmodifiable. Indeed, the
AppServer /needs/ to be able to write into the JNDI spec during
startup (or indeed, during subsequent deployments.
In essence, the JNDI /must/ be read-write, but the client view /must/
be read-only.
Don't get me wrong. I think we need LDAP functionality and I would
like
nothing better than to see LDAPd used in Geronimo, I just don't think
its a
proper fit for the JNDI ENC unless it provides the kind of caching
that I
discussed earlier.
No reason why the client proxy can't do caching on the fly as well. I
imgaine the client view would be similar to a
Collections.unmodifiableCollection() wrapper, and as well as doing
caching:
public class ClientContext extends Context {
private Map cache = new HashMap();
public ClientContext(Context context) {
}
public Object lookup(String name) {
Object result = cache.get(name);
if (result == null) {
result = context.lookup(name);
map.put(name,result);
}
return result;
}
public void bind(Object o, String name) {
throw new OperationNotSupportedException();
}
// etc
}
[With extra methods/exceptions/etc :-)]
Alex.
James
-------
http://radio.weblogs.com/0112098/
