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]
Re: Re[2]: R: R: frustrated - jdbc: No suitable driver
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]
RE: Re[2]: R: R: frustrated - jdbc: No suitable driver
Have anyone else seen the problem where the getConnection() returns a com.evermind.sql.ak type, but ANY operation on that connection such as getMetaData etc. raises a NullPointerException ? I am desperate to connect to a JDBC datasource _cleanly_ from the client side. Is it possible ? Thanks! Daniel -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Envoy : 5 fvrier, 2001 08:06 : Orion-Interest Objet : SV: Re[2]: R: R: frustrated - jdbc: No suitable driver You shouls check out the getConnection implementation on the datasource. It gets a reference it pass on to the client, so the client need to have the jdbc interfaces to do this, but it dont need the database drivers. It works much like the same way as an entitybean works (datasources)... Have fun. Klaus -Opprinnelig melding- Fra: Jeff Schnitzer [mailto:[EMAIL PROTECTED]] Sendt: 5. februar 2001 12:17 Til: Orion-Interest Emne: 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]
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]
