Hi John: I shall report the NPE bug on bugzilla alongwith the jndi configuration.
I am totally newbie to JNDI. I have one question. For generic JNDI implementation, if we bind the pool (Jdbc2PoolDataSource ) on the server, should the client get a new pool on every lookup? Vanita ----- Original Message ----- From: "John McNally" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, July 08, 2003 10:28 AM Subject: [dbcp] NPE in JNDI lookup [was Re: [dbcp] Do we need Referenceable?] > It would better to enter this as a bug: > > http://nagoya.apache.org/bugzilla/enter_bug.cgi?product=Commons&version=Nigh tly+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&s hort_desc=&comment=&maketemplate=Remember+values+as+bookmarkable+template&fo rm_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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
