Doesn't JNDI handle this for you? A serialized version of the class is
stored in the LDAP tree and when you look it up it is deserialized and made
available? Isn't this kind of how Jini/RMI/etc...work? Even if you've never
seen the class before, it doesn't matter since it implements the JDBC
interfaces. The actual implemented classes are serialized and returned to
the client automagically by the JVM?
- Original Message -
From: "Jeff Schnitzer" <[EMAIL PROTECTED]>
To: "Orion-Interest" <[EMAIL PROTECTED]>
Sent: Monday, February 05, 2001 6:16 AM
Subject: RE: Re[2]: R: R: frustrated - jdbc: No suitable driver
> 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,
> > Rafaelmailto:[EMAIL PROTECTED]
> >
> >
> >
> >
> >
