• 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

Moving JSF apps gracefully through environments

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Environment info upfront:
IDE: Rational Application Developer 7
Server: WAS on z/OS
Database: DB2
JSF knowledge: minimal

Currently my company is taking a look at JSF as an option for a sort of rapid application development need we have. I am looking at how to go about gracefully moving a JSF app through environments (dev, beta, prod) without making any direct source code changes. I'm not a great DB mind, so don't come down too hard on me...

We are using DB2, so to connect to a data source we will provide a server name, database name and a port. This can all be defined in the Application Deployment Descriptor. Just in playtime though - in reality we'll want the data sources defined on a server level.

---Part 1 - Data source (RE: database) selection---

What we do for our Java apps right now is define data sources at a server level. The naming of these data sources happens to be coupled to the database we're hitting. In any case, having our own framework we're able to allow selection of the data source through a properties file. In this way, the application can have a properties file specifiying the dev datasource in dev environments and the prod data source in prod environments. Data source selection is decoupled from application code.

An alternative structure could be to make the data sources application aware. So on a dev server we'd have a datasource defined for each application. It would point to the dev database. In production we'd have an identically named data source pointing to the prod database. In this case, the application would no longer require the ability to specify a named datasource through a properties file. The application code could always reference the same datasource name directly knowing that the datasource definition is outside of the application and it defines the target for only that application.

So in the first scenario we'd need to have a way to dynamically direct the application toward the selected datasource, likely drawn from a properties file. In the second scenario we'd simply need to attach the application to the correct data source defined on the server - whose name will carry through to all environments. The latter seems like the best choice...I'm assuming it is possible?

---Part 2 - Data creator selection---

In our environment an application in dev or beta is actually hitting the same database (datasource). The difference is that these applications are going through different creators. I'm not sure if the idea of a "creator" is typical to all database platforms. Basically, dev applications may hit the dev database through creator "devd" and beta applications may hit the dev database through the creator "devb".

Near as I can tell the only place these creators are specified is through the wizarding provided when data controls are dropped onto a JSP page. What is the best way to make these creator values dynamic through a properties file?

For our current Java applications we have built this process into our framework. So in the code all creator references are replaced by, say, "xxxxxx". So when referencing a table in SQL you'd code "xxxxxx.table", but the framework would replace the "xxxxxx" with the creator you selected in your properties file.

Is there a low-maintenance (i.e. not writing our own framework or updating source code per environment) way of accomplishing graceful staging in the JSF world?
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic