Jan 10, 2010

Lack of JEE runtime configurability thoughts

What I still do not like in complete JEE stack is a lack of runtime configurability. Assume you created an EAR application and want to distribute it to your customers. Each customer has its own database. Yes, you do hardcode the JNDI name to your persistence units and may require customer to pre-create such JDBC resource in its appserver before deploying your EAR. But you CAN'T let your customer simply deploy your EAR, go to web app from it and let to choose the database, login and password in your own configuration web UI. And that's what most customers want, as they do not like (even tech guys) to dig with JDBC pools, etc.

At the moment I realized that the only solution is to merge the app server with your enterprise application installer as well. This way you could silently install the app server, run the series of DB (and other resources) configuration screens and finally tweak the app server xml files.

But what if your enterprise application uses JAP and needs to change, say, database at runtime ? The workaround paragraph above will not help in this case. And there could be a lot of similar use-cases collected.

Well, something needs to be enhanced in this area, I think...

No comments:

Post a Comment