ahhh vinnie i feel your pain!
i've been looking for a solution to this for so long as well. and the solutions offered are always along the same lines.
i can't believ an 'ENTERPRISE' component platform as JEE is supposed to be is so crumby. i guess they've only had six chances over what? ten years to get this right.
the fact that runtime configuration is embedded INSIDE the actual deployables and there is no way to override them is the biggest JEE spec joke.
even worse, when using EAR files, the database is hard coded inside a deployable of the deployable. so in the case above for an ear you'd have to unzip the ear file, possibly unzip every jar file, change one line in a descriptor, rezip everything and then redeploy for every seperate deployment. i have spent countless hours reading the specs trying to find the fix for this - as i simple could not BELIEVE there would be none for such an obvious situation.
and this is how its supposed to be? this is the best we can do? even for third party components supplied by someone else? still? in 2010? really? you're serious?
hows this for a consumer product brochure - in order to change the channel on your tv, get a phillips head screwdriver and take the back off your remote control, pull apart the board and xxxxx....
i know you can change the global database def from the appserver, but that's a hack (why not just change your DNS settings in the hosts file to point to a different database machine?) and doesn't help for multiple installs of the same component.
hows this for a consumer product brochure - 'your tv remote contains one channel select key - '7'. in order to change to an alternate channel, reconfigure the channel memory allocations so that your desired viewing channel aligns with memory allocation '7'. then press the '7' key on your remote.
are we to understand that a whole appserver should really only ever be used for one deployment? you know - all that complex classloader stuff means nothing if you (OH MY ^&*#$% GOD) try to use the SAME unaltered jar in another unrelated deployment! thats just a concept too far-out for the JEE expert group - who'd ever think to do that?
we were trying to use ejb jar files as deployable components accross a company. this fact made it a total nightmare. you cant just store the jar in maven like everything else and share it around without restrictions - guess what the problem was? YES! people wanted to use these great jars in seperate apps pointing at different databases, in the same app server. the maven ear plugin allows you to replace the WHOLE descriptor of an ejb-jar file during deployment - but guess what happened when we released a bugfix of the component into maven? YES! you've figured it out haven't you? they OVERWROTE the new descriptor with their old one! just because they wanted to tweak the database pointer!
the only point i can come up with in regard to all this is that: NOBODY IS ACTUALLY USING JEE FOR COMPONENT DEVELOPMENT. the solution offered seem to indicate its assumed YOU control ALL the code and ALL the code is inside your unit of work. in which case you can use maven profiles and so forth to do substitutions.
now i'm sure we could write endless plugins in maven or ant to come up with some great system that opens up zips and makes xpath based changes to existing files, but really? doesn't the need point out the fact theres something fundamentally ^&*(ed up with the system as it is?
i'm currently trying to see if theres some way to programatically create the entitymanager factory so you can set the database at runtime from some external config, then use that to inject to the dao's. a nice little side project in order to try and finish the actual project. goody.
to be fair particularly with 6 JEE's generally pretty good, but no matter how close to ok it gets there is always something left out which makes my life a misery.
case in point.