Hello John,
AT> With Tomcat we're in a different position. JM> What happens if tomcat changes its process to use the standard jndi JM> pattern described above? What about a developer wishing to use dbcp JM> with another servlet container or app server? Why are you advocating JM> that dbcp tie itself exclusively to implementation details of tomcat? JM> (btw, i do use tomcat almost exclusively myself). AT> But what use for our product to implement Referenceable then? AT> It will never have Context.bind() called on it. JM> How can you presume that? Well, I'm changing my argumentation now, but not the outcome :) While the Referenceable and Serializable capabilities are generally useful for JNDI boun objects I think that with Pool objects this is not the case. In fact the Pool should be a sort of a singletone. Strictly one instance per the Context it has been bound to. (Yes I know there may be multiple JNDI paths leading to the same location, but lets assume that there is only one "home" context it is being bound to. And there should be strictly one pool per each binding to a "home" context.) Then the only meaningful reference that can exist to this object is the object itself. Or, we can have some static HashMap that maps id -> instance, and then the id will be a good reference too, but essentially this is not different from a real object reference is it? The pool reference won't make sense out of JVM (or even maybe a classloader it came from). So I state: though in general it is advisable for JNDI bound objects to be Serializable/Referenceable with Pools this is not the case. A pool should be bound into JNDI directly, not a reference to it. Same with any "quasi-singletone" object (in the sense defined above). If someone will search for a way to use DBCP out of Tomcat with JNDI his best bet will be to a) initialize an instance of the Pool (not the factory even) with appropriate settings b) bind it to JNDI directly Any references would be meaningless. BTW I feel that Tomcat way of doing things with JNDI is also bad for us. It would be highly preferable to bind the Pool not the factory to the Cotext. (Since if more then one pool is configured in Tomcat, it may well happen that only a single factory will be instantiated, so I'm probably going to talk that over on Tomcat user or dev list, when I have time, ha-ha! :) - Anton --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
