• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

client-resource.xmi defeats the purpose

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic