Konstatin, I think that this is not related with ResourceLink elements. When you define global resource link in your Context.xml, Tomcat creates ResourceLinkRef for this entry. Then same scenario exists, it creates object using ResourceLinkFactory and caches it. It is not desirable. Changing (removing caching statements) this does not break anything.
I will open an issue. Regards; --Gurkan ----- Original Message ---- From: Konstantin Kolinko <knst.koli...@gmail.com> To: Tomcat Developers List <dev@tomcat.apache.org> Sent: Fri, September 24, 2010 2:36:46 AM Subject: Re: NamingContext Possible Bug 2010/9/21 Gurkan Erdogdu <gurkanerdo...@yahoo.com>: > Hello folks, > > In NamingContext implementation, if "lookup()" is a Reference, current > implementation caches the result of the NamingManager # getObjectInstance via > following statements and changes the type of the entry. In the following > lookups, same object is returned. I would like to write ObjectFactory that > returns new instance for each time lookup is called on its reference. But with > the current implementation, it is not possible to write such an object factory > because of aferomentioned sitaution. I think that entry must be stay as > Reference instead of changing entry type. > > WDYT? > There was some discussion previously, proposed and vetoed patch and some issue in bugzilla. [1] From some later code review I think that that code is used to handle <ResourceLink> elements. That is, when you have a global resource in server.xml and a ResourceLink in your context.xml. [2] It would be undesirable to break that. [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=47512 [2] http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html#context.xml_configuration Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
