I'm fully prepared to believe that my understanding of how this works is
wrong, but if so it raises quite a few questions for me.
Connection, Statement, ResultSet, etc are just interfaces; something
must implement them. Normally they are implemented by the JDBC driver,
thus allowing the client to communicate with the database using whatever
the database uses asa native wire protocol.
We have an application client which we want to communicate with the
database using JDBC. If we want to use the database's native wire
protocol to communicate from the client box to the database box, the
JDBC drivers *must* be loaded into the client's VM and used.
Alternatively, the app server could act as an intermediary, providing a
proxy JDBC interface to the application client and making JDBC calls
into the real JDBC driver within the application server. This would
obviate the need for the database's JDBC driver on the client, but it
would also require inventing a whole new wire protocol for this middle
link... sending partial result sets in chunks, maybe caching query
results in the client, etc.
So now I'm thinking, that sounds painful, but it's possible. It's not
like writing an app server is supposed to be *easy* or anything :-) No,
Karl and Magnus are supposed to suffer so that it's easy for *us* to
write applications :-)
But a casual purusal of the decompiled Orion source code (that can be
made out through the obfuscation, which is quite a bit) turns up no
evidence of such a proxy. In fact, it looks very much like this is not
the case.
Getting more curious, I checked the JBoss source tree, and while I can't
be sure in such a quick study, it doesn't look like there is any sort of
intelligent JDBC proxy in that server either.
Am I just missing it, and all app servers implement such a proxy? Or is
it just WebLogic - allowing the behavior described in the original post?
Or is WebLogic doing http-type classloading to get the JDBC driver into
the client (a prospect I am considering less likely the more I think
about it)?
Ever curious,
Jeff
>-----Original Message-----
>From: Allen Fogleson [mailto:[EMAIL PROTECTED]]
>Sent: Sunday, February 04, 2001 10:46 AM
>To: Orion-Interest
>Subject: RE: Re[2]: R: R: frustrated - jdbc: No suitable driver
>
>
>Uhmmm, I agree, I was confused because someone said they still
>needed the
>JDBC drivers on the client, and assuming you use the portable method of
>DataSources, there should be no reason that they would need to
>have the JDBC
>drivers, it is all handled container side with the datasource.
>
>Al
>
>-----Original Message-----
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]On Behalf Of
>Rafael Alvarez
>Sent: Sunday, February 04, 2001 10:24 AM
>To: Orion-Interest
>Subject: Re[2]: R: R: frustrated - jdbc: No suitable driver
>
>
>Hello Allen,
>DataSources gives you one advantage on the client side: Security.
>
>If you use a direct JDBC connection to a Database, your username,
>password and URL have to be placed in your class. A Datasource hides
>all those details, so if some one decompile your class (even JAXed
>classes are not totally safe) only the JNDI Datasource name will be
>found. It's up to you to set a security schema for the connection with
>the app server, but at least is one problem less to solve.
>
>--
>Best regards,
> Rafael mailto:[EMAIL PROTECTED]
>
>
>
>
>
