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
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