Jeff,
>Are you sure that the JDBC driver isn't finding its way into the
>classpath? Did you try the console remotely from a machine that you
>know doesn't have the JDBC driver?
Honestly, I haven't. But I still fail to see why it would be needed.
If the data access was done using the "real" JDBC driver on the client,
the connection to the database would have to be opened there...
It's not the case. Running tests at home allowed me to prove that the
Connection must be proxied through Orion because my client could not
see the SQL server. The only conclusion is that Orion opens a connection
locally, pools it, and on demand gives a proxy to it allowing all
database access to go through the App Server...
>You may already know this, but just in case: Almost all of the orion
>tools (including orionconsole.jar) are simply empty jar files with a
>manifest that sets the Class-Path to include orion.jar and defines the
>appropriate Main-Class. You're still loading the orion.jar classes,
>potentially activating whatever classloader loads jars (especially the
>JDBC driver) out of the lib directory. Did you take this into account
>in your tests?
I know about the way orionconsole works, thanks :) I've actually spent
quite
some time analysing com.evermind.gui.server and com.evermind.server to
figure
out exactly what's going on. So far, I believe DataSource access goes
through
another JNDI bound object the ApplicationAdministrator. I still have to
test that avenue fully.
>We now have four different theories about how application-client JDBC
>works in app servers:
>1) Database-specific JDBC driver gets packaged with the application
>client and loaded into the client VM.
>2) Database-specific JDBC driver gets http-classloaded into the client
>VM.
>
>3) Serialized classes come from JNDI. Actually, I think this is just
>another way of saying #2, because java RMI uses http classloading to
get
>the class definitions to a new client.
>4) App server provides a JDBC proxy which implements a proprietary
wire
>protocol (or at least RMI "object protocol") to communicate with the
>server. Note that this is not just simply a matter of remoting the
>implementation of the Connection interface; you would have to remote
the
>implementations of ResultSet, Statement, and any other interfaces
>associated with JDBC. And you have to be pretty smart about how you do
>it, otherwise it's going to perform a lot worse than EJB methods.
I tend so far to go for 4, just because it is impossible that my client
running
from home had access to the server. No direct TCP/IP route from my
subnet to the company's 192.168.1.111/24 No way around that limitation
:)
My understanding... please all feel free to add to this, especially
Orion's
developpers !!!
A DataSource is a mechanism used encapsulate access to JDBC connections.
Orion
manages Connections with the ConnectionDataSource objects. In "theory",
a client
uses JNDI to lookup the DataSource object, gets an RMI proxy, and
retrieves a
Connection object. the way I see it, the DataSource implementation on
the server
side HAS to return a proxy to the Connection, which only resides on the
server.
I don't see any other way around that explains why I could use the
console from
home and still get to the data.
Now, I think that the current DataSource lookup does not work as I
understand it
should. Maybe I'm not proceeding properly. But now that I have seen it
work in the
console, I will not stop until it works in my client application! :)
>Does anyone out there *know* what Orion does?
Anyone? :)
Daniel
>-----Original Message-----
>From: Daniel Cardin [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, February 06, 2001 1:17 PM
>To: Orion-Interest
>Subject: Orion-console in 1.4.7 supports DataSource properly... now
>what!!!
>
>
>Hi everyone!
>
>I'm progressing... Orion 1.4.7 has support for DataSources in the
>orion-console application.
>If you select a DataSource, you will see a new panel allowing you to
>enter SQL commands that will
>be sent directly to the database through the DataSource + connection.
>
>it WORKS in the console. So this implies that :
>
>1. the concept is valid : you don't need to use a driver
>instance on the
>client side, contrary to what
> some of you stated. No JDBC download, nothing... just a proxy
>instance implementing the Connection interface
>2. the client doesn't need to see the database server on the same
>network
>3. my datasources are configured PROPERLY on the server side... (I was
>always doubting that
> but normal DS, pooled DS, EJB DS etc. all work from my client
>(actually only XA won't work now))
>
>SO: since I get perfect access through the console, either
>
>a) I can't do a JNDI lookup! (I doubt that)
>b) the DataSource lookup is not working (yet) in 1.4.7
>c) OrionConsole uses another method than a simple lookup to get the
>DataSource object.
>
>Please everyone, realize this is important for performance issues and
>let's try to make it work!
>
>Thanks for your help
>
>Daniel
>
>
>
>
