Hi!
marc fleury wrote:
> > > 2- whether you call or not, why the BeanClassLoader for root
> > naming only...
> >
> > What else do you want there?
>
> well my point is remove it since...
>
> > > 3- Isnt' the "bean" in Container a better class to put all
> > metaData instead
> > > of passing information implicitely.
> >
> > What "bean" are you referring to? The "metaData" attribute? Well, that
> > *is* where the metadata is..
>
> all your information should be there.
But then we'd have to introduce a threadlocal to hold it. The point was
that since we associate the thread with a classloader, why not reuse it
for the java: namespace. But sure, we could "go back" to synchronized
threadlocals ;-)
> > > 4- Since your interceptors are "newed" for container
> > interceptors at this
> > > point you should use the set, and then 3 applies
>
> Well setting the container on all those interceptor mean that they are not
> shared just belong to one... that is something we might "reverse". It makes
> sense... bean should be the only place unless you can justify the
> "necessity" for BeanCLassLoader JNDI root as opposed to just using the bean
> metadata... if you ask me it is because you use your EJX stuff and you don't
> have a "storeRoot" ;-) never mind.
I don't understand. The reason for the BeanClassLoader is to have
something associated with the executing thread from which we can get the
JNDI root. The metadata isn't associated with a thread, so we can't use
that.
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
