It would better to enter this as a bug: http://nagoya.apache.org/bugzilla/enter_bug.cgi?product=Commons&version=Nightly+Builds&component=Dbcp&rep_platform=Other&op_sys=other&priority=Other&bug_severity=Major&bug_status=NEW&assigned_to=&cc=&bug_file_loc=http%3A%2F%2F&short_desc=&comment=&maketemplate=Remember+values+as+bookmarkable+template&form_name=enter_bug
Details on the stacktrace and possibly the jndi configuration would be helpful when trying to reproduce. john mcnally On Tue, 2003-07-08 at 07:44, Vanita Shroff wrote: > Hello Anton: > > I am trying to use DBCP for a standalone client-server application that does > not have any middle layer like Tomcat. And I am trying to use JNDI to bind > the object. As per my experience, Jdbc2Pool and DriverAdapterCPDS need to be > referenceable in order to bind for standalone applications. The problem I am > running into is I am successful in binding the object, but when I do a > lookup on the Jdbc2Pool object from client it gives me nullpointerexception. > It cannot find the dsInstanceMap that stores the instance value. Any > suggestions? > > Hope this helps in the decision. > > Vanita > > > ----- Original Message ----- > From: "Anton Tagunov" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, July 08, 2003 12:01 AM > Subject: [dbcp] Do we need Referenceable? > > > > Hello, All develpers interested in DBCP! > > > > I was reviewing code of Jdbc2PoolDataSource when I hit this question. > > I even have done a good deal of reading on JNDI yesterday to educate > > myself on the subject, although I did not master it _all_ though. > > > > Now I have a question: do we really need > > > > DriverAdapterCPDS and Jdbc2PoolDataSource(Factory) > > to implement javax.naming.Referenceable? > > > > As I understand Tomcat JNDI resource infrastructure, it is enough > > to have an object that implements javax.naming.spi.ObjectFactory > > > > As I understand Referencealbe interface on an object is needed > > if we want to > > * first create an object manually > > * then do .getReference() on it > > * then bind this reference to a JNDI context > > > > It looks like the Tomcat usage scenario is different. > > As I understand > > http://jakarta.apache.org/tomcat/tomcat-4.0-doc/jndi-resources-howto.html > > it is > > * we configure ResourceParameters section in server.xml (or whatever) > > * at runtime Tomcat creates an object of the class named > > as 'factory' in those parameters and casts it to the > > ObjectFactoryInterface > > * when an instance is needed > > getObjectInstance() is invoked on those, the first > > parameter containing the set of properties configured > > under ResrouceParameters > > > > I would have nothing against implementing Referenceable by > > if it was coming for free to us. > > > > But this is not the case. > > Jdbc2DataSource had to go into greatest quirks and tricks > > because of this. I would even say that this has determined > > its design and that it has made this design overcomplicated. > > > > The trouble is this: > > > > with a DataSource factory we need the client to receive > > always the same object from the lookup() method. > > > > So this is a trivial factory, it always creates the same > > object. > > > > We could bind the object directly into JNDI, but Tomcat > > does allow us only the factory approach, > > > > Okay, so good so far. > > > > But, if this only object that is created with the factory > > is Referenceable, it has to implement .getReference() > > such that factory.getObjectInstance( reference, ... ) > > would return the same instance. > > > > It would be trivial - as the factory always returns one > > object, but the trouble is that the code in Jdbc2PoolDataSource > > for some reason fears that two factory instances will be > > created at runtime. > > > > If this really happens we need to embed the object itself > > into the reference... ufff... > > > > > > Well, it's got messy. > > But so is the code in Jdbc2DataSource. > > > > So, can we enlighten our burden and just nuke Referenceable > > from Jdbc2DataSource? > > > > The usage scenario it supports seems not be used in practice. > > > > I have not studied DriverAdapterCPDS to see how it handles > > the Referenceable interface. Probably it just records all > > the config data there to reconstruct the original Reference > > with which it has been created and thus allows its own clone > > to be created. As DriverAdapterCPDS does not pool connections > > itself, having two identically configured DriverAdapterCPDS > > does not cause the troubles that having two identically > > configured Jdbc2PoolDataSource would. But while it does > > not seem to create dramatical trouble it does not give > > any advantage in my view either. > > > > Maybe nuke Referenceable from it altogether? > > BTW it looks like DriverAdapterCPDS was created first > > and the Referenceable implementing code was just copied > > from it to the Jdbc2PoolDataSource. So probably it is > > a code that does the right thing (tm :) in Jdbc2PoolDataSource > > anyway. > > > > Thoughts? > > > > -Anton > > > > (And sorry for the message being quite messy itself -- really > > have got to run right now) > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
