| Author |
Message
|
| ghoshly |
 Posted: Wed Aug 24, 2011 1:52 pm Post subject: Access property file from esql using Java method : Where? |
 |
|
Partisan
Joined: 10 Jan 2008
Posts: 333
|
Hello,
I am trying to read/write property file ( containing name , value pairs) from esql using Java methods in WMB 6.0.2.
I have created a simple class with two functions to read and write from and to the property file and methods are working stand alone when I kept the property file inside the Java project folder itself.
I exported the complete project as .jar file and put the jar file in the bar and deployed the same in broker. Did I do something wrong here ?
When I am calling the method from esql, its not able to get the config file.
Please help. Let me know if you want to see the code snippet.
Calling Java method from esql is working as when I returned hardcoded values from method, its returning correctly. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Aug 24, 2011 2:36 pm Post subject: Re: Access property file from esql using Java method : Where |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| ghoshly wrote: |
Hello,
I am trying to read/write property file ( containing name , value pairs) from esql using Java methods in WMB 6.0.2.
I have created a simple class with two functions to read and write from and to the property file and methods are working stand alone when I kept the property file inside the Java project folder itself.
I exported the complete project as .jar file and put the jar file in the bar and deployed the same in broker. Did I do something wrong here ?
When I am calling the method from esql, its not able to get the config file.
Please help. Let me know if you want to see the code snippet.
Calling Java method from esql is working as when I returned hardcoded values from method, its returning correctly. |
Think hard.... then think again.... The property file is not where you expect it, especially if you used a relative path....
It would maybe be better to define them as UDP...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| ghoshly |
| Posted: Wed Aug 24, 2011 3:29 pm Post subject: Used absolute path and it works |
|
|
Partisan
Joined: 10 Jan 2008
Posts: 333
|
If I provide the absolute path to the property file, it is able to access it.
From Java perspective when the property file is in the project directory, class methods were able to access it without any path.
What is the relative path/directory the java methods looks first for the property file (or any other file we are trying to access) so that we can put the file in that location and need not have any path dependency. Is it not the shared-class path for the broker?
fjb,
Are you advising to use UDP instead of property file? In that case whenever any new look-up candidate is there, we need a code change again. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Aug 24, 2011 7:41 pm Post subject: Re: Used absolute path and it works |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| ghoshly wrote: |
If I provide the absolute path to the property file, it is able to access it.
From Java perspective when the property file is in the project directory, class methods were able to access it without any path.
What is the relative path/directory the java methods looks first for the property file (or any other file we are trying to access) so that we can put the file in that location and need not have any path dependency. Is it not the shared-class path for the broker?
fjb,
Are you advising to use UDP instead of property file? In that case whenever any new look-up candidate is there, we need a code change again. |
Well as far as I understand it you have to restart the flow anyways if you want to change the value once it has been loaded.
Your java method will have to cache the values in a hash map (java.util.Properties) because accessing the file system every time is way to expensive on the runtime. So a change of values (whether you use java or UDP) will have to come with a new deployment or flow restart... With a UDP you may have the additional benefit of changing the runtime values via the configmgr proxy...
$0.02 of one, or $0.02 of the other... I don't see that much where the problem lies using UDPs...
However if you are more comfortable with the properties file, go for it, just make sure that for performance you cache the values...
As for the location you need to look at how the broker explodes the bar file and where it places the different components... (typically look at /var/mqsi/components/<broker name> or the windows equivalent)...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| saurabh867 |
| Posted: Wed Aug 24, 2011 10:11 pm Post subject: Re: Access property file from esql using Java method |
|
|
Voyager
Joined: 13 Jun 2010
Posts: 78
|
Hi,
In windows the default java path would point to C:\Program Files\IBM\MQSI\6.1\bin. You can check this by printing user.dir and check in the console.txt.
But I would advice to used ESQL to provide a relative path.
If you have put your jar file inside the bar file then you can find the jar file in the location C:\Documents and Settings\All Users\Application Data\IBM\MQSI\components\<Your Broker>\<UUId of Exec group>\config\JAR in windows. To establish a relative path, use WORKPATH of esql which points to C:\Documents and Settings\All Users\Application Data\IBM\MQSI for windows then you can append the detail of your broker etc depending on the location of your file.
However using java to just read the property in broker is not a good option. |
|
| Back to top |
|
|
| ghoshly |
| Posted: Thu Aug 25, 2011 6:32 pm Post subject: How about Property file + Shared Row ? |
|
|
Partisan
Joined: 10 Jan 2008
Posts: 333
|
I completely oblige your advice.
How about the property file and Shared row variable usage for caching. I have implemented that, and it seems to be working though I have not completed the full regression test. Good point I see is no need to do flow restart or cache clearance as long as you do not change old values. I just added some new candidate in the property file and the flow picks up fine in the next run without any hickkup..!!
Would wait for your comments. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Aug 25, 2011 7:48 pm Post subject: Re: How about Property file + Shared Row ? |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| ghoshly wrote: |
I completely oblige your advice.
How about the property file and Shared row variable usage for caching. I have implemented that, and it seems to be working though I have not completed the full regression test. Good point I see is no need to do flow restart or cache clearance as long as you do not change old values. I just added some new candidate in the property file and the flow picks up fine in the next run without any hickkup..!!
Would wait for your comments. |
Shared row variable as cache works for me...
If you want to avoid restarting the flow even for changing the values, you need another input node in the flow and a compute node that does nothing else but flush the cache... So whatever message (dummy) you put on that input node would flush the cache...
Also make sure that any write/delete operation to the cache is synchronized (ATOMIC)...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| ghoshly |
| Posted: Thu Aug 25, 2011 9:50 pm Post subject: sorry, but thought the updation of shared a separate topic |
|
|
Partisan
Joined: 10 Jan 2008
Posts: 333
|
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Aug 25, 2011 10:29 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
IMHO, both the read and write operations on the shared row need to be atomic.
This ensures that only one thread can access the data at a time. This is especially important when you have additional instances of the fllow.
We use this to store flow parameters in the runtime. These are periodically read from a Database. IMHO, a lot easier to use than fiddling with properties files. To make a change outside of the referesh period we stop the flow. Update the DB and restart the flow. If we had to change a properties file we would have to retest the whole flow(s) as this is regarded as a source change. Yeah I know this sounds silly but we have been burned in the past when people have deployed UAT properties files into Production on our Application Server systems.
_________________
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 |
|
|
| ghoshly |
| Posted: Fri Aug 26, 2011 7:22 am Post subject: Thanks |
|
|
Partisan
Joined: 10 Jan 2008
Posts: 333
|
| I completely understand the issue, but in this shop people are against of using application database for Broker !!!! |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Aug 26, 2011 7:34 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Property files are not recommended to be used, if you must read the property file every message. Why would you want to read a property file every message? Reading a property file every message means you are paying latency penalty and horsepower penalty every time. Whats the point of doing that?
Thats the whole benefit of UDPs. UDPs do not consume resources every message.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Aug 26, 2011 7:43 am Post subject: Re: Thanks |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| ghoshly wrote: |
| I completely understand the issue, but in this shop people are against of using application database for Broker !!!! |
I guess that you are working at a Java shop then. Files for this, files for that. Some of the configuration files you have to use with a JBOSS server for a JCA connection are just crazy. The syntax is pure gobbledegook.
Just keep your email handy for the first time the wrong properties file is used in Production. Then you will have the pleasure of telling your PHM 'I told you so'.
_________________
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 |
|
|
| ghoshly |
| Posted: Fri Aug 26, 2011 9:43 am Post subject: Poor me.. |
|
|
Partisan
Joined: 10 Jan 2008
Posts: 333
|
I had a silly typo mistake..
| Code: |
| DECLARE propertyName CHARACTER InputRoot.XMLSC.CacheDestinationRow.Environment; |
'XMLSC' instead of 'XMLNSC' which was causing the error.
Thanks all for your guidance.  |
|
| Back to top |
|
|
| ghoshly |
| Posted: Fri Aug 26, 2011 10:00 am Post subject: How many UDP I would use for multiple |
|
|
Partisan
Joined: 10 Jan 2008
Posts: 333
|
I would not call this a Java shop either, because no one is pushing me to use Java or the property file. But they are not ready to use application database for keeping this look-up table I would say. Reason given : Database is not something "must have" for broker in future as in V7. No point in investing in DB license, DBA cost etc.
I do not understand clear, how I can use UDP for multiple look-up candidates (row in look up table) when that number is not fixed. Can we have a ROW variable as a UDP which can cater multiple rows for lookup ?
I am sorry if I am dragging to much, but trying to find an alternate to the property file approach without using a database. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Aug 26, 2011 10:13 am Post subject: Re: How many UDP I would use for multiple |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| ghoshly wrote: |
| trying to find an alternate to the property file approach without using a database. |
Singletons ... !! 
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
|
|
