On Tue, 2003-07-08 at 22:53, Anton Tagunov wrote: > Hello John! > > JM> I am confused (and it has been awhile since I last looked at what is > JM> required). A DataSource should implement at least one of Referencable > JM> and Serializable; the specification recommends both. Are you advocating > JM> that we implement neither? > > Yes. But probably I really do not understand something essential. > Disclaimer: yet have not read all JNDI spec though. > > Okay, imagine we have a separate Factory and Product. > Factory is ObjectFactory, it creates Product. > > You say it is recommended that Product implements Referenceable > or Serializable. But how can this be utilized? > > I believe there is only one way for it: > if we have an object of type Product > > Product product; > > and we have a writeable object of class javax.naming.Context > > Context context; > > then we may call > > context.bind( ..., product ); > > and instead of storing the product itself the context will > store either a reference to it, obtained via > > product.getReference(); > > or product's serialized form.
That sounds like a good description. > > With Tomcat we're in a different position. > Tomcat takes ResourceParams and unconditionally creates > a Reference object all by itself populating it with > the config data. This Reference also contains > the factory class we have configured. > What happens if tomcat changes its process to use the standard jndi pattern described above? What about a developer wishing to use dbcp with another servlet container or app server? Why are you advocating that dbcp tie itself exclusively to implementation details of tomcat? (btw, i do use tomcat almost exclusively myself). > But what use for our product to implement Referenceable then? > It will never have Context.bind() called on it. How can you presume that? > > So I'm for implementing neither Referenceable nor Serializable. > In fact BasicDataSourceFactory/BasicDataSource implement none > of this and work find with Tomcat. > > AT> As I understand Tomcat JNDI resource infrastructure, it is enough > AT> to have an object that implements javax.naming.spi.ObjectFactory > > JM> Are you saying that we can assume that if we meet tomcat's requirements > JM> for binding to its jndi implementation, that we will meet the > JM> requirements for a generic jndi implementation? Or that we should only > JM> worry about tomcat's version? > > Let's face it. Tomcat makes such a specialized use of the Reference > object that our factories this way or other fit only into Tomcat. > I don't understand the basis for that statement. You appear to be advocating changes to require only use in tomcat, but jdbc2pool is not currently written that way. john mcnally --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
