commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John McNally <jmcna...@collab.net>
Subject [dbcp] NPE in JNDI lookup [was Re: [dbcp] Do we need Referenceable?]
Date Tue, 08 Jul 2003 16:28:53 GMT
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" <atagunov@mail.cnt.ru>
> To: <commons-dev@jakarta.apache.org>
> 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: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message