I'm using WAS 5.1 and want to deploy a standalone app. client to the server, to run some batch processes. I want to run the app in the server to re-use the datasource, logging etc. However, the app. client can not access the datasource directly. If I do a JNDI lookup I get a NameNotFound exception. After doing some investigation, I found that the recommended approach is to access the datasource via an EJB. My issue is that currently the app client uses Spring to access the datasource and I'm not sure how that will interact with the EJB. Has anyone had any success with this? Is my best bet to build an EJB that also implements the SQL Datasource interface and let Spring treat it as a Datasource?
Hello, 1)You might need to check the JNDI name you are referring to. It may be the case that DataSource you are trying to refer is not created successfully and hence the JNDI name is not bound to it. AFAIK any Java class running in the server process can access the DataSource just by instantiating the InitialContext. Context ctx = new InitialContext(); DataSource ds = (DataSource)ctx.lookup("datasourcejndiname"); If your app client is running outside server process then you need to instantiate the InitialContext with the ProviderURL and InitialContextFactory(You need check this with websphere documentation)
2)Regarding Recommanded Approach using Datasource via EJB - I am not able to understand this because as I mentioned before the DataSource is a server resource and can be accessed by any java class. While doing session beans if you need the the database connection then you would access the datasource from an EJB and use it to get the connection. But this does not mean your stand-alone app need to go through EJB to use the datasource.
3) If you are using a Spring configuration to inject the datasource in application then you can consider deploying your application as a webapplication. And load the spring context using ContextLoaderLister or ContextLoaderServlet. There must be other ways as well to load the spring configuration and get it used by your application client. But I think using webapp would be the most easiest of them all.
Here's my two cents: Just create a stateless session bean with a single high level method that performs your task by instantiating and calling methods on your existing classes. This requires very little effort on your part, and it provides an easy way for a client to run an application within the container. All your existing code that uses the Spring framework will work just fine within the session bean, indluding references to JNDI data sources.
If you don't want to use the EJB container-managed transaction service, just disable it by specifying "not supported" as the transaction attribute in the deployment descriptor.
Thanks very much for the responses. They've given me new directions to look into. The datasource is up and running already and is used by a web-app on the server. What I want to do is make some of the web-apps business logic available in a 'batch' environement. I planned to use Quartz, but I've been blocked for none technical reasons. Hence, the app client approach. I will give Merrills suggestion of using the EJB as a wrapper around the application, rather than the datasource, a go and let you know how I get on.