Accessing Datasource from Outside A Web Container (through JNDI)?

JBoss DataSource config DataSource wrappers are not usable outside of the server VM.

Michael Well, java.sql. Connection is an Interface - it might technically be possible for the concrete implementation you're getting from JBoss to be Serializable - but I don't think you're really going to have any options you can use. If it was possible, it would probably be easy :) I think @toolkit might have said the right words with useable outside the VM - the JDBC drivers will be talking to native driver code running in the underlying OS I guess, so that might explain why you can't just pass a connection over the network elsewhere.My advice, (if you don't get any better advice!

) would be to find a different approach - if you have access to locate the resource on the JBoss directory, maybe implement a proxy object that you can locate and obtain from the directory that allows you to use the connection remotely from your fat client. That's a design pattern called data transfer object I think Wikipedia entry.

Toolkit: Well, not exactly. Since I can access the data source over JNDI, it is actually visible and thus usable. Or am I getting something totally wrong?

@Brabster: I think you're on the right track. Isn't there a way to make the connection serializable? Maybe it's just a configuration issue...

You'd get reuse benefits out of that too. Here's an example of something looks similar for Wicket.

JBoss wraps up all DataSources with it's own ones. That lets it play tricks with autocommit to get the specified J2EE behaviour out of a JDBC connection. They are mostly serailizable.

But you needn't trust them. I'd look carefully at it's wrappers. I've written a surrogate for JBoss's J2EE wrappers wrapper for JDBC that works with OOCJNDI to get my DAO code unit test-able standalone.

You just wrap java.sql. Driver, point OOCJNDI at your class, and run in JUnit. The Driver wrapper can just directly create a SQL Driver and delegate to it.

Return a java.sql. Connection wrapper of your own devising on Connect. A ConnectionWrapper can just wrap the Connection your Oracle driver gives you, and all it does special is set Autocommit true.

Don't forget Eclipse can wrt delgates for you. Add a member you need to delegate to , then select it and right click, source -=>add delgage methods. This is great when you get paid by the line ;-) Bada-bing, Bada-boom, JUnit out of the box J2EE testing.

Your problem is probably amenable to the same thing, with JUnit crossed out and FatCLient written in an crayon. My FatClient uses RMI generated with xdoclet to talk to the J2EE server, so I don't have your problem.

I think the exception indicates that the SQLConnection object you're trying to retrieve doesn't implement the Serializable interface, so it can't be passed to you the way you asked for it. From the limited work I've done with JDNI, if you're asking for an object via JNDI it must be serializable. As far as I know, there's no way round that - if I think of a better way I'll post it up... OK, one obvious option is to provide a serializable object local to the datasource that uses it but doesn't have the datasource as part of its serializable object graph.

The fat client could then look up that object and query it instead. Or create a (web? ) service through which to access the datasource is governed - again your fat client would hit the service - this would probably be better encapsulated and more reuseable approach if those are concerns for you.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.