client-resource.xmi defeats the purpose

[Jennifer Jones]

We originally developed a stand alone Java application that used things like javax.mail.Session.getInstance(sysprops, null) and DriverManager.getConnection(url, user, password) but since we wanted to prevent having things like mail host and database name hardcoded within our EAR file, we decided to try to use launchclient so we could use resource references and/or JNDI names.

However, the only way we can get launchclient to work successfully on WebSphere is to have a client-resource.xmi that basically defines everything that is set up in WebSphere's Application Server, including the hard coded mail host and database name. This makes it extremely difficult for us to give our client an ear file because every time they want to change these values, they have to change them in more than one place and changing client-resource.xmi is not that easy to do.

We were able to get launchclient to work without client-resource.xmi locally using WSAD. Is there any way to not use client-resource.xmi with WebSphere and not have these values hardcoded in our ear file?

Thanks,
Jennifer

[Kyle Brown]

The problem is that these things (in particular database drivers and Javamail providers) are not really well defined as to how they should work in standalone Java applications. The spec is basically silent on this, thus we have to do the client-resources.xmi file in WAS.

Have you considered moving to a true 3-tier system and moving your database access and Javamail access behind EJB Session facades and then just calling the session facades from your standalone Java application? It would make things simpler all around...

Kyle

[Jennifer Jones]

We were actually able to get the app client jar to pick up the real app servers jndi objects. We took out the client-resource.xmi and the bnd file. Then, in our script that calls launchclient.sh, we added:
. /clocal/udb/db2inst1/sqllib/db2profile
to setup some db2 environment variables.
Not sure why this works but it fixed our problem. Adding calling this script to our WebSphere startup script also solved some datasource connection issues.