> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Oleg Nitz
> Sent: Saturday, October 07, 2000 8:28 AM
> To: [EMAIL PROTECTED]
> Subject: [jBoss-Dev] BeanClassLoader for serving JNDI?
>
>
> Hi,
>
> I feel that this may be a known issue, which is already in somebody's
> todo list. Sorry if it is so, but I still hope to get some reply.
> Now jBoss creates one URLClassLoader per jar file (may I call it
> "container ClassLoader"?) and then creates one BeanClassLoader per
> bean, i.e. multiple BeanClassLoaders for each container ClassLoader.
> Comments in BeanClassLoader.java state:
> "This classloader is used to hold the java: JNDI-namespace root.
> Each container has its own BCL. When a "java:" lookup is made
> the JNDI-provider will use the root to lookup the values."
> The phrase "Each container has its own BCL" is not the full truth:
> each container has one or more own BCLs.
> I think it's a bit strange use of ClassLoaders: BeanClassLoader add
> nothing to the classpath, but instead serves for JNDI-provider.
> Isn't it possible to use ThreadLocal variable instead?
> Say, put to it a HashMap containing all JNDI entries for the given
> bean. Am I missing something?
>
well the use of the thread local variable is over-kill in our case since we
totally control the jndi visibility of the bean. It is a better design to
keep the 1-1 o(1) association with the visibility (by the place holder BCL)
than to rely on a O(log(n)) map that is thread local.
This is why we do it.
Now we need to rework somehow the cl hierarchy and rickard has yet another
idea there ;-)
mar
c
> Best regards,
> Oleg Nitz
>
>
>
>
