| Author |
Message
|
| iamfat |
 Posted: Mon Mar 19, 2012 6:48 pm Post subject: How can we use ESQL to read a property file??? |
 |
|
Apprentice
Joined: 08 Mar 2012
Posts: 32
Location: China
|
We have some db variables in a property file.
But we only use ESQL in our flow, no java code in the flow.
Can we use ESQL to read the property file and get the value of a variable in the file?? Or we have to use java node to get the value?
Help~~ Thank you....
 |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Mon Mar 19, 2012 10:39 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
There are numerous and lengthy discussions here about this issue.
The first thing to remember is that Broker is NOT an Application Server.
Then ask yourself, how often the data in these properties files will change.
Then ask yourself who is going to manage those changes and make sure that they are in Source Control.
You have a DB already. So what is wrong with it? Why do you need to change?
Is it because you have some Java Coders who are starting to develop in ESQL and are finding old habits (viz, if it is too hard, dump it into a properties file...) are really hard to break.
To sum it up, this idea is generally considered to be a bad thing.
Would you like to expand on your reasons why you want to do this?
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Mon Mar 19, 2012 11:25 pm Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
I used properties files (during development with an App-Server).
They are surprisingly new... you have them (in the current form/in a usable way) since a couple of years (only). It's new: All Java-Coders jump on it  .
For Broker: Consider using a DB-Table (e.g. just 2 cols: key (name) & value. Also look at caching (shared row!)
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| iamfat |
| Posted: Tue Mar 20, 2012 5:37 pm Post subject: |
|
|
Apprentice
Joined: 08 Mar 2012
Posts: 32
Location: China
|
| smdavies99 wrote: |
There are numerous and lengthy discussions here about this issue.
The first thing to remember is that Broker is NOT an Application Server.
Then ask yourself, how often the data in these properties files will change.
Then ask yourself who is going to manage those changes and make sure that they are in Source Control.
You have a DB already. So what is wrong with it? Why do you need to change?
Is it because you have some Java Coders who are starting to develop in ESQL and are finding old habits (viz, if it is too hard, dump it into a properties file...) are really hard to break.
To sum it up, this idea is generally considered to be a bad thing.
Would you like to expand on your reasons why you want to do this? |
It's designed by the architecture team. We have to use a property file to config the db pwd, and other property.
We already solved this issue. We use the ESQL-Java interface.
Created a ESQL procdure which invoke a java static method. That java method will get the property file.
Thank you.
If i'm an architecture i'll configure the value in the broker[Configurable Service]. Save pwd in the property file is stupid.
I have to do what the architecture designed. |
|
| Back to top |
|
|
| iamfat |
| Posted: Tue Mar 20, 2012 5:38 pm Post subject: |
|
|
Apprentice
Joined: 08 Mar 2012
Posts: 32
Location: China
|
| mqsiuser wrote: |
I used properties files (during development with an App-Server).
They are surprisingly new... you have them (in the current form/in a usable way) since a couple of years (only). It's new: All Java-Coders jump on it .
For Broker: Consider using a DB-Table (e.g. just 2 cols: key (name) & value. Also look at caching (shared row!) |
you are right. use DB-Table is better than property file.
Thank you. |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Tue Mar 20, 2012 11:22 pm Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
| iamfat wrote: |
you are right. use DB-Table is better than property file.
Thank you. |
Sometimes one will have to do "less" recommended things/approaches. It is good that Broker has/offers a wide range/variety.
Probably your architects screwed this one up ... but likely your business "just requires it" (e.g. a properties-file, e.g. because of "audit-requirements").
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Mar 21, 2012 4:37 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| iamfat wrote: |
| It's designed by the architecture team. We have to use a property file to config the db pwd, and other property. |
So you store db passwords and other sensitive data in a clear text properties file? If the architecture team are happy with this, has anyone mentioned it to your security and audit functions....?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| joebuckeye |
| Posted: Wed Mar 21, 2012 5:04 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 365
Location: Columbus, OH
|
Make sure you test changing the property file and how the code knows it needs to read it again.
I was helping on a project that used property files and they were perfectly happy with them until they changed a value in it and then figured out the only way to pick up the changed values was to restart their flow. |
|
| Back to top |
|
|
| iamfat |
| Posted: Wed Mar 21, 2012 5:05 pm Post subject: |
|
|
Apprentice
Joined: 08 Mar 2012
Posts: 32
Location: China
|
| mqsiuser wrote: |
| iamfat wrote: |
you are right. use DB-Table is better than property file.
Thank you. |
Sometimes one will have to do "less" recommended things/approaches. It is good that Broker has/offers a wide range/variety.
Probably your architects screwed this one up ... but likely your business "just requires it" (e.g. a properties-file, e.g. because of "audit-requirements"). |
I don't know exactly why they want to do this.
We just follow the design, i joined this team recently.
Maybe they have there way.  |
|
| Back to top |
|
|
| iamfat |
| Posted: Wed Mar 21, 2012 5:10 pm Post subject: |
|
|
Apprentice
Joined: 08 Mar 2012
Posts: 32
Location: China
|
| Vitor wrote: |
| iamfat wrote: |
| It's designed by the architecture team. We have to use a property file to config the db pwd, and other property. |
So you store db passwords and other sensitive data in a clear text properties file? If the architecture team are happy with this, has anyone mentioned it to your security and audit functions....? |
Nobody mentioned this.
I think populate the configuration into the broker Configurable Services is a better way.  |
|
| Back to top |
|
|
| iamfat |
| Posted: Wed Mar 21, 2012 5:22 pm Post subject: |
|
|
Apprentice
Joined: 08 Mar 2012
Posts: 32
Location: China
|
| joebuckeye wrote: |
Make sure you test changing the property file and how the code knows it needs to read it again.
I was helping on a project that used property files and they were perfectly happy with them until they changed a value in it and then figured out the only way to pick up the changed values was to restart their flow. |
Yeah. That depends on how we read the property file. We can reload the property file every exactly seconds.
Anyway, use the property file is not a good way.
But our team maybe considered the autobuild issue.
We have many environments DEV TEST PRODUCT etc.
Maybe they use different version of property file will help them change the environment very fast. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Mar 21, 2012 5:28 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
With the odbc set up and the configurable services on WMB, you have 0 change when you deploy into the next environment. Your environment setup happens once when you configure the broker...
On the other hand there is no way to dynamically switch the environment at runtime... Oh wait! that's called dynamic routing and you move the message to a different queue!!!
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Wed Mar 21, 2012 7:39 pm Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
| joebuckeye wrote: |
| [...] the only way to pick up the changed values was to restart their flow. |
Depending on your requirements this is an ok-approach. Polling every 3 seconds might also not be the best approach. Triggering the flow (to refresh) with a message... requires additional in-queues...
And: Refreshing (of cached stuff) is independent of prop-files and also applies to data that was retrieved from a db.
Think positiv 
@fjb_saper: You wouldn't mix different environments... exceptions apply ofc
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Mar 22, 2012 5:19 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fjb_saper wrote: |
| With the odbc set up and the configurable services on WMB, you have 0 change when you deploy into the next environment. Your environment setup happens once when you configure the broker... |
The flow should obtain environment specific details from a common spot configured at the broker level. So (for example) the flow would use a database called CLIENTS. This doesn't vary between environments. What varies is which database (DEV, TEST, etc) the CLIENTS ODBC points to in which environment. Likewise if the flow uses a web service; the URL would be obtained from a configuration setting not by reading it out of a property file.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Mar 22, 2012 5:33 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| User Defined Configurable Services, UDP values promoted to flow, FileRead node file, Database entry - in that order would be my preferences. |
|
| Back to top |
|
|
|
|
