Re[2]: [dbcp] Do we need Referenceable?

[Anton Tagunov <at...@mail.cnt.ru>]

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.

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.

But what use for our product to implement Referenceable then?
It will never have Context.bind() called on it.

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.

-Anton


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

Re[4]: [dbcp] Do we need Referenceable?

[Anton Tagunov <at...@mail.cnt.ru>]

Hello John,


AT> With Tomcat we're in a different position.

JM> What happens if tomcat changes its process to use the standard jndi
JM> pattern described above?  What about a developer wishing to use dbcp
JM> with another servlet container or app server?  Why are you advocating
JM> that dbcp tie itself exclusively to implementation details of tomcat? 
JM> (btw, i do use tomcat almost exclusively myself).
 
AT> But what use for our product to implement Referenceable then?
AT> It will never have Context.bind() called on it.

JM> How can you presume that?

Well, I'm changing my argumentation now, but not the outcome :)

While the Referenceable and Serializable capabilities are generally
useful for JNDI boun objects I think that with Pool objects this
is not the case.

In fact the Pool should be a sort of a singletone.
Strictly one instance per the Context it has been bound to.
(Yes I know there may be multiple JNDI paths leading to the
same location, but lets assume that there is only one "home"
context it is being bound to. And there should be strictly
one pool per each binding to a "home" context.)

Then the only meaningful reference that can exist to this
object is the object itself.

Or, we can have some static HashMap that maps id -> instance,
and then the id will be a good reference too, but essentially
this is not different from a real object reference is it?

The pool reference won't make sense out of JVM (or even maybe
a classloader it came from).

So I state: though in general it is advisable for JNDI
bound objects to be Serializable/Referenceable with Pools
this is not the case. A pool should be bound into JNDI
directly, not a reference to it. Same with any
"quasi-singletone" object (in the sense defined above).

If someone will search for a way to use DBCP out of
Tomcat with JNDI his best bet will be to
a) initialize an instance of the Pool (not the factory even)
   with appropriate settings
b) bind it to JNDI directly

Any references would be meaningless.

BTW I feel that Tomcat way of doing things with JNDI is also
bad for us. It would be highly preferable to bind the Pool
not the factory to the Cotext. (Since if more then one
pool is configured in Tomcat, it may well happen that only
a single factory will be instantiated, so I'm probably going
to talk that over on Tomcat user or dev list, when I have time,
ha-ha! :)

- Anton


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

Re: Re[2]: [dbcp] Do we need Referenceable?

[John McNally <jm...@collab.net>]

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org