| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| read propertyfile |
« View previous topic :: View next topic » |
| Author |
Message
|
| WMBSAM |
 Posted: Sun Apr 11, 2010 8:38 pm Post subject: read propertyfile |
 |
|
Voyager
Joined: 02 Oct 2009
Posts: 90
Location: Atlanta
|
|
| Back to top |
|
 |
| mqmatt |
| Posted: Mon Apr 12, 2010 2:07 am Post subject: |
|
|
Grand Master
Joined: 04 Aug 2004
Posts: 1213
Location: Hursley, UK
|
Note that the mqsiapplybaroverride command changed quite a lot in V6.1; there are now more options for specifying overrides. For example, you can specify sets of <propertyname=propertyvalue> and <oldvalue=newvalue> overrides, using either a properties file or manually on the commandline. You can also now insert and replace a whole new deployment descriptor in a BAR file.
If you're on V6.1 or V7, one of the newer options might be more appropriate for you, depending on how your change management and build systems are set up.
If you're still on V6.0, then bear the new options in mind for when you migrate. |
|
| Back to top |
|
|
| hallmark |
| Posted: Tue Apr 13, 2010 6:14 am Post subject: |
|
|
Voyager
Joined: 10 Mar 2005
Posts: 76
|
| Quote: |
we have a requirement where we have to build only one barfile and then it has to be used for different environments (DEV,QA,PROD) progressively .
|
Excellent requirement and main reason why bar overrides are there.
| Quote: |
So my questions is this a good approach to deal with such situation or is ther any other solution which could be better?
|
We have a similar solution and we have a property file of the overrides for each bar file at each environment level. This tends to get quite cumbersome. I have tried various methods to minimise the amount of abstract source code to represent an environment's overrides...
1. Have a set of environment variables on each of the target hosts that the deployment scripts can source and generate a specific override file within the deployment script from these environment variables plus the parameterised override file in the deployment package...
2. A single source controlled file with all barfile overrides contained therein and then again logic in the deployment script to generate a specific override file and apply it
But my biggest recommendation is to try as hard as possible to mimimise the differences between environments. There is a tendancy because of the flexibility of bar overrides and scripting ability to allow its use to proliferate and you end up with overrides for nearly everything from datasources to logfile locations. The more there are the more likely an inappropriate override can be applied.
Your admin team has to know what each is for and whether it is appropriate for each environment, since your code is packaged from DEV and promoted it can be quite easy for an override to slip through (e.g suddently running multiple instances in UAT without any warning or any review as to whether it was warranted, acceptable etc...). I'm not saying it can't be done and controlled, its just more of an overhead the more its used and without thought can have unintended consequences.
_________________
Rob |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
