https://issues.apache.org/bugzilla/show_bug.cgi?id=47512
--- Comment #7 from MartÃn Schonaker <mrr...@gmail.com> 2009-11-05 19:01:45 UTC --- (In reply to comment #4) > So, Martin wants to have a global JNDI entry, that behaves differently > depending on the caller. > > I think that relying on ObjectFactory to do the trick is wrong. Factories, as > the name implies, are supposed to be called to create an object. Creation is > something that is done once. It would be wrong to do it on every access. The > Javadoc for NamingManager#getObjectInstance() clearly states that it "Creates > an instance of an object". > > Thus caching the result, as NamingContext#lookup(Name,boolean) does, is valid. > > > I think that implementing a custom javax.naming.Context would be one of > possible proper ways to implement what you do want. Though I have not tried so > myself, so I do not really know. Konstantin, when you say "So, Martin wants to have a global JNDI entry, that behaves differently depending on the caller." I think you might be forgetting that ObjectFactories classes are solved in the invoking classloader. Thus, the behavior will depend on the local ObjectFactory implementation. For Tomcat programming purposes, it would seem to be enough to put the ObjectFactory class in the common classloader. Nevertheless, nothing prohibits someone to fill the classname field (see javax.naming.Rerefence constructor and #getClassName() method) with name of classes that don't exist in the common classloader. So for instance, suppose that I fill classname with "xyz.MyClass" in a Reference published in the global Tomcat JNDI directory. Suppose that in the the web context "A" (with its own classloader as you surely already know) that class exists. When performing a lookup, the class will be successfully resolved, and an instance returned (depending on object class implementation). In the same scenario, another lookup but in web context "B" (also containing xyz.MyClass) happens. org.apache.naming.NamingContext will return the cached object from context A. Which in turn, cannot be cast to the local xyz.MyClass, since its class belongs to a different classloader, producing a ClassCastException. I reported the issue for java.lang.reflect.Proxy because I was working with proxies, but this might happen with any Object. Why I'm trying to implement? to share objects among contexts whose classes are not know until JNDI-name-resolving time, although present in invoking classloaders. The link to customer resource factories won't help. Those factories are always local to the context they're declared. I would love to customize naming context implementation, but it's deeply hardcoded into Tomcat's codebase. Besides, I think the implementation of Context is just flawed, not wrong. So, please guys, proof wrong the concept of ObjectFactories are resolved/ran in the invoking classloader/thread before withdrawing this issue. Best regards. Martin. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
