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]
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
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[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]
RE: R: R: frustrated - jdbc: No suitable driver
I think I am becomming more confused now. If you use a DataSource, and then DataSource.getConnection() you should have no need of JDBC drivers on the client side. You would need the javax.sql.* package but not the database dependent drivers. Otherwise what was the sense in switching to a DataSource? If I have to change my client if my database changes then I may as well just get connections the old way. Admittedly I have very rarely had a database change once an app was deployed... The other thing is that when calling EJB's you are only dealing with the remote interface, so you are not actually instantiating a connection on your machine (assuming an application client) so again there would be no need of jdbc drivers on the client machine. With all that, I cannot think of any instance where a DataSource is used where you need them, could you perhaps elaborate the situation where you do? After all maybe I am being dense and missing something. :) Al -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer Sent: Wednesday, January 31, 2001 12:15 AM To: Orion-Interest Subject: RE: R: R: frustrated - jdbc: No suitable driver While I agree that the client code should have no knowledge of what driver it is using, somehow the JDBC driver classes do need to eventually find their way to the client machine. Since J2EE doesn't specify the process by which client files get to the client machine (and for good reason), there are a lot of ways to do it. From you description, it looks like the weblogic launcher will automatically download the JDBC driver. I stand corrected :-) I wonder how they deal with licensing issues... I doubt they let just anyone download their jDrivers :-) And why didn't they make a launcher that downloads *all* the necessary classes so you can have a zero install footprint on the client machine? Looking at their docs, it looks like ClientDeployer wants the whole ear file to be installed on the client. Yuck. But I'll agree, downloading some classes is probably better than no classes. Orion is not so friendly. You've got to package everything up in the client jar file, including the interface classes of the ejbs you want to use. The good news is that in this process it's simple to put the minimum subset of classes into the client package :-) And dynamically downloading the class files is slow anyways :-) :-) :-) Jeff
Re: R: R: frustrated - jdbc: No suitable driver
Hey Tom, Potentially silly question (somewhat new to Orion but I've used a few other app. servers). Are you basically saying that the use of a javax.sql.DataSource acquried via a call to InitialContext.lookup() means I don't need a JDBC Driver on a remote client machine (end-user's desktop)? I was unaware that this trick would work. I've always tried to push all database access to session beans, servlets or server-RMI objects. Thanks, Burr [EMAIL PROTECTED] - Original Message - From: Tom Mitchell [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Tuesday, January 30, 2001 9:28 PM Subject: Re: R: R: frustrated - jdbc: No suitable driver Jeff, I disagree. Part of the benefit of a DataSource is that it can abstract the actual driver or database being used. If I can ask a DataSource for a database connection and not have to care about which client-side driver to load, and (less practically), even what rdbms i am using. That way, the app server can change databases, drivers, even vendors without its clients being aware. I experienced this issue porting an app from WebLogic. I used the same schema and sql with SQL Server and Postgres on WebLogic. My client application (which both queried and populated the database) never changed. It just got a Context from the app server, gfot a DataSource by name, then got plain old JDBC Connections from there. No JDBC drivers at all. I think that is a useful layer. PS: I have unsubscribed from the list - if you would like to continue the discussion, please reply to my personal address. Thanks for your thoughts. I appreciate your point of view, I just disagree with it. Jeff Schnitzer wrote: If the client is going to use the JDBC driver, it must be able to load the class(es). This means you need to package the driver with the client application. I'm puzzled by your comments about clients not needing to care about drivers - are these classes just going to materialize out of thin air? I suppose in theory the server could do something with http classloading, but why bother with the extra complexity, security considerations, and licensing issues? You know you're going to need the classes anyways, package them with the client. Jeff -Original Message- From: Tom Mitchell [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 30, 2001 9:08 AM To: Orion-Interest Subject: Re: R: R: frustrated - jdbc: No suitable driver Again, thanks for your replies. What is curious to me is that the driver performs fine within a jsp. I look up loc with no problem. It only has a problem from a client application. And, it does not seem like a client to a DataSource should ever have to care about drivers - that is the container's job in my opinion. data-source class="com.evermind.sql.ConnectionDataSource" name="SomeDatasource" location="loc" xa-location="jdbc/xa/SomeXADS" ejb-location="ejb/weather" schema="database-schemas/postgresql.xml" connection-driver="org.postgresql.Driver" username="tom" password="tR16/4" url="jdbc:postgresql://192.168.1.5:5432/weather" inactivity-timeout="30" / Any more ideas? DeVincentiis Giustino wrote: Sorry, the message "No suitable driver" probably means a problem with jdbc driver. So if you have into the data-sources.xml the definition: data-source class="com.evermind.sql.DriverManagerDataSource" name="Hypersonic" location="jdbc/HypersonicCoreDS" xa-location="jdbc/xa/HypersonicXADS" ejb-location="jdbc/HypersonicDS" connection-driver="org.hsql.jdbcDriver" username="sa" password="" url="jdbc:HypersonicSQL:./database/defaultdb" inactivity-timeout="30" / you should lookup "jdbc/HypersonicDS", and you should have the driver classes in your /orion/lib directory. Giustino -Messaggio originale- Da: Tom Mitchell [mailto:[EMAIL PROTECTED]] Inviato: marted 30 gennaio 2001 12.24 A: Orion-Interest Oggetto: Re: R: frustrated - jdbc: No suitable driver Thanks for the reply. That is exactly how I am initializing the context in my client application: Hashtable ht = new Hashtable(); ht.put(Context.INITIAL_CONTEXT_FACTORY, "com.evermind.server.ApplicationClientInitialContextFactory"); ht.put(Context.PROVIDER_URL, "ormi://192.168.1.3"); ht.put(Context.SECURITY_PRINCIPAL, "someUser"); ht.put(Context.SECURITY_CREDENTIALS, "secret"); // Obtain con
SV: R: R: frustrated - jdbc: No suitable driver
You will have to define the jdbc connection in the datasource configuration
file on the appserver though.
The client should never use any jdbc directly :)
The Entity beans can be mapped using cmp or bmp and the lookup through the
JNDI context for the suitable connection instance is
done through the J2EE context classes as explained by Burr..
A normal method to do this is (inside an EJB in this example):
Connection conn = null;
try {
InitialContext ic = new InitialContext();
/* Here is the JNDI name...check orions data-sources.xml
* file in the config directory to see examples with hsql
*/And note that you should prolly choose to use the pooled-location
name
DataSource ds (DataSource)ic.lookup("jdbc/ProdObjectSpacePooledDS");
conn = ds.getConnection();
} catch (Exception ex) {
throw new EJBException(ex);
}
// .. do some JDBC stuff
conn.close();
Hope this helps you further :=)
Have fun!!
Klaus Myrseth
-Opprinnelig melding-
Fra: Burr Sutter [mailto:[EMAIL PROTECTED]]
Sendt: 31. januar 2001 15:21
Til: Orion-Interest
Emne: Re: R: R: frustrated - jdbc: No suitable driver
Hey Tom,
Potentially silly question (somewhat new to Orion but I've used a few other
app. servers). Are you basically saying that the use of a
javax.sql.DataSource acquried via a call to InitialContext.lookup() means I
don't need a JDBC Driver on a remote client machine (end-user's desktop)?
I was unaware that this trick would work. I've always tried to push all
database access to session beans, servlets or server-RMI objects.
Thanks,
Burr
[EMAIL PROTECTED]
- Original Message -
From: Tom Mitchell [EMAIL PROTECTED]
To: Orion-Interest [EMAIL PROTECTED]
Sent: Tuesday, January 30, 2001 9:28 PM
Subject: Re: R: R: frustrated - jdbc: No suitable driver
Jeff,
I disagree. Part of the benefit of a DataSource is that it can abstract
the actual driver or database being used. If I can ask a DataSource for
a database connection and not have to care about which client-side
driver to load, and (less practically), even what rdbms i am using.
That way, the app server can change databases, drivers, even vendors
without its clients being aware.
I experienced this issue porting an app from WebLogic. I used the same
schema and sql with SQL Server and Postgres on WebLogic. My client
application (which both queried and populated the database) never
changed. It just got a Context from the app server, gfot a DataSource
by name, then got plain old JDBC Connections from there. No JDBC
drivers at all.
I think that is a useful layer.
PS: I have unsubscribed from the list - if you would like to continue
the discussion, please reply to my personal address.
Thanks for your thoughts.
I appreciate your point of view, I just disagree with it.
Jeff Schnitzer wrote:
If the client is going to use the JDBC driver, it must be able to load
the class(es). This means you need to package the driver with the
client application. I'm puzzled by your comments about clients not
needing to care about drivers - are these classes just going to
materialize out of thin air? I suppose in theory the server could do
something with http classloading, but why bother with the extra
complexity, security considerations, and licensing issues? You know
you're going to need the classes anyways, package them with the client.
Jeff
-Original Message-
From: Tom Mitchell [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 30, 2001 9:08 AM
To: Orion-Interest
Subject: Re: R: R: frustrated - jdbc: No suitable driver
Again, thanks for your replies.
What is curious to me is that the driver performs fine within a jsp. I
look up loc with no problem.
It only has a problem from a client application. And, it does not seem
like a client to a DataSource should ever have to care about drivers -
that is the container's job in my opinion.
data-source
class="com.evermind.sql.ConnectionDataSource"
name="SomeDatasource"
location="loc"
xa-location="jdbc/xa/SomeXADS"
ejb-location="ejb/weather"
schema="database-schemas/postgresql.xml"
connection-driver="org.postgresql.Driver"
username="tom"
password="tR16/4"
url="jdbc:postgresql://192.168.1.5:5432/weather"
inactivity-timeout="30"
/
Any more ideas?
DeVincentiis Giustino wrote:
Sorry, the message "No suitable driver" probably means a
problem with jdbc
driver.
So if you have into the data-sources.xml the definition:
data-source
class="com.evermind.sql.DriverManagerDataSource"
name="Hypersonic"
location="jdbc/HypersonicCoreDS"
xa-location=&quo
SV: R: R: frustrated - jdbc: No suitable driver
Ofcourse if you use this in an Entity bean pls use the EJB connection :)
Sorry just aditional information - forgot this on the first letter :)
Klaus
-Opprinnelig melding-
Fra: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sendt: 31. januar 2001 16:19
Til: Orion-Interest
Emne: SV: R: R: frustrated - jdbc: No suitable driver
You will have to define the jdbc connection in the datasource configuration
file on the appserver though.
The client should never use any jdbc directly :)
The Entity beans can be mapped using cmp or bmp and the lookup through the
JNDI context for the suitable connection instance is
done through the J2EE context classes as explained by Burr..
A normal method to do this is (inside an EJB in this example):
Connection conn = null;
try {
InitialContext ic = new InitialContext();
/* Here is the JNDI name...check orions data-sources.xml
* file in the config directory to see examples with hsql
*/And note that you should prolly choose to use the pooled-location
name
DataSource ds (DataSource)ic.lookup("jdbc/ProdObjectSpacePooledDS");
conn = ds.getConnection();
} catch (Exception ex) {
throw new EJBException(ex);
}
// .. do some JDBC stuff
conn.close();
Hope this helps you further :=)
Have fun!!
Klaus Myrseth
-Opprinnelig melding-
Fra: Burr Sutter [mailto:[EMAIL PROTECTED]]
Sendt: 31. januar 2001 15:21
Til: Orion-Interest
Emne: Re: R: R: frustrated - jdbc: No suitable driver
Hey Tom,
Potentially silly question (somewhat new to Orion but I've used a few other
app. servers). Are you basically saying that the use of a
javax.sql.DataSource acquried via a call to InitialContext.lookup() means I
don't need a JDBC Driver on a remote client machine (end-user's desktop)?
I was unaware that this trick would work. I've always tried to push all
database access to session beans, servlets or server-RMI objects.
Thanks,
Burr
[EMAIL PROTECTED]
- Original Message -
From: Tom Mitchell [EMAIL PROTECTED]
To: Orion-Interest [EMAIL PROTECTED]
Sent: Tuesday, January 30, 2001 9:28 PM
Subject: Re: R: R: frustrated - jdbc: No suitable driver
Jeff,
I disagree. Part of the benefit of a DataSource is that it can abstract
the actual driver or database being used. If I can ask a DataSource for
a database connection and not have to care about which client-side
driver to load, and (less practically), even what rdbms i am using.
That way, the app server can change databases, drivers, even vendors
without its clients being aware.
I experienced this issue porting an app from WebLogic. I used the same
schema and sql with SQL Server and Postgres on WebLogic. My client
application (which both queried and populated the database) never
changed. It just got a Context from the app server, gfot a DataSource
by name, then got plain old JDBC Connections from there. No JDBC
drivers at all.
I think that is a useful layer.
PS: I have unsubscribed from the list - if you would like to continue
the discussion, please reply to my personal address.
Thanks for your thoughts.
I appreciate your point of view, I just disagree with it.
Jeff Schnitzer wrote:
If the client is going to use the JDBC driver, it must be able to load
the class(es). This means you need to package the driver with the
client application. I'm puzzled by your comments about clients not
needing to care about drivers - are these classes just going to
materialize out of thin air? I suppose in theory the server could do
something with http classloading, but why bother with the extra
complexity, security considerations, and licensing issues? You know
you're going to need the classes anyways, package them with the client.
Jeff
-Original Message-
From: Tom Mitchell [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 30, 2001 9:08 AM
To: Orion-Interest
Subject: Re: R: R: frustrated - jdbc: No suitable driver
Again, thanks for your replies.
What is curious to me is that the driver performs fine within a jsp. I
look up loc with no problem.
It only has a problem from a client application. And, it does not seem
like a client to a DataSource should ever have to care about drivers -
that is the container's job in my opinion.
data-source
class="com.evermind.sql.ConnectionDataSource"
name="SomeDatasource"
location="loc"
xa-location="jdbc/xa/SomeXADS"
ejb-location="ejb/weather"
schema="database-schemas/postgresql.xml"
connection-driver="org.postgresql.Driver"
username="tom"
password="tR16/4"
url="jdbc:postgresql://192.168.1.5:5432/weather"
inactivity-timeout="30"
/
Any more ideas?
DeVincentiis Giustino wrote:
Sorry, the message "No suitable driver" probably means a
prob
R: frustrated - jdbc: No suitable driver
Try initializing the context this way:
...
Properties props = new Properties();
props.setProperty("java.naming.factory.initial","com.evermind.server.Applica
tionClientInitialContextFactory");
props.setProperty("java.naming.provider.url", "ormi://localhost/app-name");
props.setProperty("java.naming.security.principal", "admin");
props.setProperty("java.naming.security.credentials", "123");
InitialContext ctx = new InitialContext(props);
...
Giustino De Vincentiis
-Messaggio originale-
Da: Tom Mitchell [mailto:[EMAIL PROTECTED]]
Inviato: marted 30 gennaio 2001 1.23
A: Orion-Interest
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Oggetto: frustrated - jdbc: No suitable driver
Hi All,
I am used to WebLogic, so please pardon my ignorance...
I am trying to get my WebLogic application to run on Orion.
I have a DataSource set up to PostgreSql. It seems OK because this
Orion JSP works fine:
InitialContext ctx = new InitialContext();
out.print("brContext: " + ctx);
DataSource ds = (DataSource) ctx.lookup("jdbc/DefaultDS");
Connection conn = ds.getConnection();
// Create query and get results
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select count(*) FROM
weathersnapshots");
// List results
while ( rs.next() ) {
out.println( "br" + rs.getObject(1) + "br");
}
// Close connection - important!
conn.close();
This runs fine and gives me the count of rows in the table.
When I try to get the standalone client to the same DataSource to run, I
get this:
Context: javax.naming.InitialContext@316e52
Exception in thread "main" java.sql.SQLException: No suitable driver
at java.sql.DriverManager.getConnection(Unknown Source)
at java.sql.DriverManager.getConnection(Unknown Source)
at com.evermind.sql.DriverManagerDataSource.getConnection(JAX)
at Test.main(Test.java:18)
No errors appear on the server's console. I can not imagine why I would
want to have a DB driver's jar in my client's classpath (ALTHOUGH I HAVE
TRIED THAT).
I have an application-client.xml:
application-client
/application-client
I have scoured the list archives and can not find the solution.
Remember, within the container, it runs fine. It is the standalone app
that does not work.
Using:
Orion 1.4.5
JDK 1.3
Win2K
Thanks in advance.
--
Tom Mitchell
[EMAIL PROTECTED]
Very Current Stoneham, MA Weather
http://www.tom.org
Re: R: frustrated - jdbc: No suitable driver
Thanks for the reply. That is exactly how I am initializing the context
in my client application:
Hashtable ht = new Hashtable();
ht.put(Context.INITIAL_CONTEXT_FACTORY,
"com.evermind.server.ApplicationClientInitialContextFactory");
ht.put(Context.PROVIDER_URL, "ormi://192.168.1.3");
ht.put(Context.SECURITY_PRINCIPAL, "someUser");
ht.put(Context.SECURITY_CREDENTIALS, "secret");
// Obtain connection
InitialContext ctx = new InitialContext(ht);
DeVincentiis Giustino wrote:
Try initializing the context this way:
...
Properties props = new Properties();
props.setProperty("java.naming.factory.initial","com.evermind.server.Applica
tionClientInitialContextFactory");
props.setProperty("java.naming.provider.url", "ormi://localhost/app-name");
props.setProperty("java.naming.security.principal", "admin");
props.setProperty("java.naming.security.credentials", "123");
InitialContext ctx = new InitialContext(props);
...
Giustino De Vincentiis
-Messaggio originale-
Da: Tom Mitchell [mailto:[EMAIL PROTECTED]]
Inviato: marted 30 gennaio 2001 1.23
A: Orion-Interest
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Oggetto: frustrated - jdbc: No suitable driver
Hi All,
I am used to WebLogic, so please pardon my ignorance...
I am trying to get my WebLogic application to run on Orion.
I have a DataSource set up to PostgreSql. It seems OK because this
Orion JSP works fine:
InitialContext ctx = new InitialContext();
out.print("brContext: " + ctx);
DataSource ds = (DataSource) ctx.lookup("jdbc/DefaultDS");
Connection conn = ds.getConnection();
// Create query and get results
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select count(*) FROM
weathersnapshots");
// List results
while ( rs.next() ) {
out.println( "br" + rs.getObject(1) + "br");
}
// Close connection - important!
conn.close();
This runs fine and gives me the count of rows in the table.
When I try to get the standalone client to the same DataSource to run, I
get this:
Context: javax.naming.InitialContext@316e52
Exception in thread "main" java.sql.SQLException: No suitable driver
at java.sql.DriverManager.getConnection(Unknown Source)
at java.sql.DriverManager.getConnection(Unknown Source)
at com.evermind.sql.DriverManagerDataSource.getConnection(JAX)
at Test.main(Test.java:18)
No errors appear on the server's console. I can not imagine why I would
want to have a DB driver's jar in my client's classpath (ALTHOUGH I HAVE
TRIED THAT).
I have an application-client.xml:
application-client
/application-client
I have scoured the list archives and can not find the solution.
Remember, within the container, it runs fine. It is the standalone app
that does not work.
Using:
Orion 1.4.5
JDK 1.3
Win2K
Thanks in advance.
--
Tom Mitchell
[EMAIL PROTECTED]
Very Current Stoneham, MA Weather
http://www.tom.org
--
Tom Mitchell
[EMAIL PROTECTED]
Very Current Stoneham, MA Weather
http://www.tom.org
R: R: frustrated - jdbc: No suitable driver
Sorry, the message "No suitable driver" probably means a problem with jdbc
driver.
So if you have into the data-sources.xml the definition:
data-source
class="com.evermind.sql.DriverManagerDataSource"
name="Hypersonic"
location="jdbc/HypersonicCoreDS"
xa-location="jdbc/xa/HypersonicXADS"
ejb-location="jdbc/HypersonicDS"
connection-driver="org.hsql.jdbcDriver"
username="sa"
password=""
url="jdbc:HypersonicSQL:./database/defaultdb"
inactivity-timeout="30"
/
you should lookup "jdbc/HypersonicDS", and you should have the driver
classes in your /orion/lib directory.
Giustino
-Messaggio originale-----
Da: Tom Mitchell [mailto:[EMAIL PROTECTED]]
Inviato: marted 30 gennaio 2001 12.24
A: Orion-Interest
Oggetto: Re: R: frustrated - jdbc: No suitable driver
Thanks for the reply. That is exactly how I am initializing the context
in my client application:
Hashtable ht = new Hashtable();
ht.put(Context.INITIAL_CONTEXT_FACTORY,
"com.evermind.server.ApplicationClientInitialContextFactory");
ht.put(Context.PROVIDER_URL, "ormi://192.168.1.3");
ht.put(Context.SECURITY_PRINCIPAL, "someUser");
ht.put(Context.SECURITY_CREDENTIALS, "secret");
// Obtain connection
InitialContext ctx = new InitialContext(ht);
DeVincentiis Giustino wrote:
Try initializing the context this way:
...
Properties props = new Properties();
props.setProperty("java.naming.factory.initial","com.evermind.server.Applica
tionClientInitialContextFactory");
props.setProperty("java.naming.provider.url",
"ormi://localhost/app-name");
props.setProperty("java.naming.security.principal", "admin");
props.setProperty("java.naming.security.credentials", "123");
InitialContext ctx = new InitialContext(props);
...
Giustino De Vincentiis
-Messaggio originale-
Da: Tom Mitchell [mailto:[EMAIL PROTECTED]]
Inviato: marted 30 gennaio 2001 1.23
A: Orion-Interest
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Oggetto: frustrated - jdbc: No suitable driver
Hi All,
I am used to WebLogic, so please pardon my ignorance...
I am trying to get my WebLogic application to run on Orion.
I have a DataSource set up to PostgreSql. It seems OK because this
Orion JSP works fine:
InitialContext ctx = new InitialContext();
out.print("brContext: " + ctx);
DataSource ds = (DataSource) ctx.lookup("jdbc/DefaultDS");
Connection conn = ds.getConnection();
// Create query and get results
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select count(*) FROM
weathersnapshots");
// List results
while ( rs.next() ) {
out.println( "br" + rs.getObject(1) + "br");
}
// Close connection - important!
conn.close();
This runs fine and gives me the count of rows in the table.
When I try to get the standalone client to the same DataSource to run, I
get this:
Context: javax.naming.InitialContext@316e52
Exception in thread "main" java.sql.SQLException: No suitable driver
at java.sql.DriverManager.getConnection(Unknown Source)
at java.sql.DriverManager.getConnection(Unknown Source)
at com.evermind.sql.DriverManagerDataSource.getConnection(JAX)
at Test.main(Test.java:18)
No errors appear on the server's console. I can not imagine why I would
want to have a DB driver's jar in my client's classpath (ALTHOUGH I HAVE
TRIED THAT).
I have an application-client.xml:
application-client
/application-client
I have scoured the list archives and can not find the solution.
Remember, within the container, it runs fine. It is the standalone app
that does not work.
Using:
Orion 1.4.5
JDK 1.3
Win2K
Thanks in advance.
--
Tom Mitchell
[EMAIL PROTECTED]
Very Current Stoneham, MA Weather
http://www.tom.org
--
Tom Mitchell
[EMAIL PROTECTED]
Very Current Stoneham, MA Weather
http://www.tom.org
Re: R: R: frustrated - jdbc: No suitable driver
Jeff,
I disagree. Part of the benefit of a DataSource is that it can abstract
the actual driver or database being used. If I can ask a DataSource for
a database connection and not have to care about which client-side
driver to load, and (less practically), even what rdbms i am using.
That way, the app server can change databases, drivers, even vendors
without its clients being aware.
I experienced this issue porting an app from WebLogic. I used the same
schema and sql with SQL Server and Postgres on WebLogic. My client
application (which both queried and populated the database) never
changed. It just got a Context from the app server, gfot a DataSource
by name, then got plain old JDBC Connections from there. No JDBC
drivers at all.
I think that is a useful layer.
PS: I have unsubscribed from the list - if you would like to continue
the discussion, please reply to my personal address.
Thanks for your thoughts.
I appreciate your point of view, I just disagree with it.
Jeff Schnitzer wrote:
If the client is going to use the JDBC driver, it must be able to load
the class(es). This means you need to package the driver with the
client application. I'm puzzled by your comments about clients not
needing to care about drivers - are these classes just going to
materialize out of thin air? I suppose in theory the server could do
something with http classloading, but why bother with the extra
complexity, security considerations, and licensing issues? You know
you're going to need the classes anyways, package them with the client.
Jeff
-Original Message-
From: Tom Mitchell [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 30, 2001 9:08 AM
To: Orion-Interest
Subject: Re: R: R: frustrated - jdbc: No suitable driver
Again, thanks for your replies.
What is curious to me is that the driver performs fine within a jsp. I
look up loc with no problem.
It only has a problem from a client application. And, it does not seem
like a client to a DataSource should ever have to care about drivers -
that is the container's job in my opinion.
data-source
class="com.evermind.sql.ConnectionDataSource"
name="SomeDatasource"
location="loc"
xa-location="jdbc/xa/SomeXADS"
ejb-location="ejb/weather"
schema="database-schemas/postgresql.xml"
connection-driver="org.postgresql.Driver"
username="tom"
password="tR16/4"
url="jdbc:postgresql://192.168.1.5:5432/weather"
inactivity-timeout="30"
/
Any more ideas?
DeVincentiis Giustino wrote:
Sorry, the message "No suitable driver" probably means a
problem with jdbc
driver.
So if you have into the data-sources.xml the definition:
data-source
class="com.evermind.sql.DriverManagerDataSource"
name="Hypersonic"
location="jdbc/HypersonicCoreDS"
xa-location="jdbc/xa/HypersonicXADS"
ejb-location="jdbc/HypersonicDS"
connection-driver="org.hsql.jdbcDriver"
username="sa"
password=""
url="jdbc:HypersonicSQL:./database/defaultdb"
inactivity-timeout="30"
/
you should lookup "jdbc/HypersonicDS", and you should have the driver
classes in your /orion/lib directory.
Giustino
-Messaggio originale-
Da: Tom Mitchell [mailto:[EMAIL PROTECTED]]
Inviato: marted 30 gennaio 2001 12.24
A: Orion-Interest
Oggetto: Re: R: frustrated - jdbc: No suitable driver
Thanks for the reply. That is exactly how I am initializing
the context
in my client application:
Hashtable ht = new Hashtable();
ht.put(Context.INITIAL_CONTEXT_FACTORY,
"com.evermind.server.ApplicationClientInitialContextFactory");
ht.put(Context.PROVIDER_URL, "ormi://192.168.1.3");
ht.put(Context.SECURITY_PRINCIPAL, "someUser");
ht.put(Context.SECURITY_CREDENTIALS, "secret");
// Obtain connection
InitialContext ctx = new InitialContext(ht);
DeVincentiis Giustino wrote:
Try initializing the context this way:
...
Properties props = new Properties();
props.setProperty("java.naming.factory.initial","com.evermind.s
erver.Applica
tionClientInitialContextFactory");
props.setProperty("java.naming.provider.url",
"ormi://localhost/app-name");
props.setProperty("java.naming.security.principal", "admin");
props.setProperty("java.naming.security.credentials", "123");
InitialContext ctx = new InitialContext(props);
...
RE: R: R: frustrated - jdbc: No suitable driver
While I agree that the client code should have no knowledge of what driver it is using, somehow the JDBC driver classes do need to eventually find their way to the client machine. Since J2EE doesn't specify the process by which client files get to the client machine (and for good reason), there are a lot of ways to do it. From you description, it looks like the weblogic launcher will automatically download the JDBC driver. I stand corrected :-) I wonder how they deal with licensing issues... I doubt they let just anyone download their jDrivers :-) And why didn't they make a launcher that downloads *all* the necessary classes so you can have a zero install footprint on the client machine? Looking at their docs, it looks like ClientDeployer wants the whole ear file to be installed on the client. Yuck. But I'll agree, downloading some classes is probably better than no classes. Orion is not so friendly. You've got to package everything up in the client jar file, including the interface classes of the ejbs you want to use. The good news is that in this process it's simple to put the minimum subset of classes into the client package :-) And dynamically downloading the class files is slow anyways :-) :-) :-) Jeff -Original Message- From: Tom Mitchell [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 30, 2001 6:29 PM To: Orion-Interest Subject: Re: R: R: frustrated - jdbc: No suitable driver Jeff, I disagree. Part of the benefit of a DataSource is that it can abstract the actual driver or database being used. If I can ask a DataSource for a database connection and not have to care about which client-side driver to load, and (less practically), even what rdbms i am using. That way, the app server can change databases, drivers, even vendors without its clients being aware. I experienced this issue porting an app from WebLogic. I used the same schema and sql with SQL Server and Postgres on WebLogic. My client application (which both queried and populated the database) never changed. It just got a Context from the app server, gfot a DataSource by name, then got plain old JDBC Connections from there. No JDBC drivers at all. I think that is a useful layer. PS: I have unsubscribed from the list - if you would like to continue the discussion, please reply to my personal address. Thanks for your thoughts. I appreciate your point of view, I just disagree with it. Jeff Schnitzer wrote: If the client is going to use the JDBC driver, it must be able to load the class(es). This means you need to package the driver with the client application. I'm puzzled by your comments about clients not needing to care about drivers - are these classes just going to materialize out of thin air? I suppose in theory the server could do something with http classloading, but why bother with the extra complexity, security considerations, and licensing issues? You know you're going to need the classes anyways, package them with the client. Jeff -Original Message- From: Tom Mitchell [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 30, 2001 9:08 AM To: Orion-Interest Subject: Re: R: R: frustrated - jdbc: No suitable driver Again, thanks for your replies. What is curious to me is that the driver performs fine within a jsp. I look up loc with no problem. It only has a problem from a client application. And, it does not seem like a client to a DataSource should ever have to care about drivers - that is the container's job in my opinion. data-source class="com.evermind.sql.ConnectionDataSource" name="SomeDatasource" location="loc" xa-location="jdbc/xa/SomeXADS" ejb-location="ejb/weather" schema="database-schemas/postgresql.xml" connection-driver="org.postgresql.Driver" username="tom" password="tR16/4" url="jdbc:postgresql://192.168.1.5:5432/weather" inactivity-timeout="30" / Any more ideas? DeVincentiis Giustino wrote: Sorry, the message "No suitable driver" probably means a problem with jdbc driver. So if you have into the data-sources.xml the definition: data-source class="com.evermind.sql.DriverManagerDataSource" name="Hypersonic" location="jdbc/HypersonicCoreDS" xa-location="jdbc/xa/HypersonicXADS" ejb-location="jdbc/HypersonicDS" connection-driver="org.hsql.jdbcDriver" username="sa" password="" url="jdbc:HypersonicSQL:./database/defaultdb" inactivity-timeout="30" / you should lookup "jdbc/HypersonicDS&q
frustrated - jdbc: No suitable driver
Hi All,
I am used to WebLogic, so please pardon my ignorance...
I am trying to get my WebLogic application to run on Orion.
I have a DataSource set up to PostgreSql. It seems OK because this
Orion JSP works fine:
InitialContext ctx = new InitialContext();
out.print("brContext: " + ctx);
DataSource ds = (DataSource) ctx.lookup("jdbc/DefaultDS");
Connection conn = ds.getConnection();
// Create query and get results
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select count(*) FROM
weathersnapshots");
// List results
while ( rs.next() ) {
out.println( "br" + rs.getObject(1) + "br");
}
// Close connection - important!
conn.close();
This runs fine and gives me the count of rows in the table.
When I try to get the standalone client to the same DataSource to run, I
get this:
Context: javax.naming.InitialContext@316e52
Exception in thread "main" java.sql.SQLException: No suitable driver
at java.sql.DriverManager.getConnection(Unknown Source)
at java.sql.DriverManager.getConnection(Unknown Source)
at com.evermind.sql.DriverManagerDataSource.getConnection(JAX)
at Test.main(Test.java:18)
No errors appear on the server's console. I can not imagine why I would
want to have a DB driver's jar in my client's classpath (ALTHOUGH I HAVE
TRIED THAT).
I have an application-client.xml:
application-client
/application-client
I have scoured the list archives and can not find the solution.
Remember, within the container, it runs fine. It is the standalone app
that does not work.
Using:
Orion 1.4.5
JDK 1.3
Win2K
Thanks in advance.
--
Tom Mitchell
[EMAIL PROTECTED]
Very Current Stoneham, MA Weather
http://www.tom.org
