commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vanita Shroff" <vani...@xentel.com>
Subject Re: [dbcp] NPE in JNDI lookup [was Re: [dbcp] Do we need Referenceable?]
Date Tue, 08 Jul 2003 17:52:41 GMT
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" <jmcnally@collab.net>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
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" <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


---------------------------------------------------------------------
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