• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

How to specify application configuration file

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have a J2EE server application that has its own xml based configuration file. The location of the configuration file is specified during installation by our customers.
There is no issue in accessing this file as long as the the my application module knows the location of the file. Here is my questions:
Q. What is the best way to pass configuration PATH information to my application module (e.g. uisng JNDI, application server config file, system property files etc.)? Since the product is going to support multiple application servers in a distributed environment, a generic approach is required.
regards
Kunal
 
Ranch Hand
Posts: 2713
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
System property is a good way to go. It is easy to implement, easy to change, and guaranteed to be supported across all vendors in the same manner.
 
Kunal Sharma
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Chris!
I don't know much about distributed deployment in J2EE, but how will this system property information will be shared among multiple server? Does application server duplicates it across multiple nodes or the information should be specified on each node separately, which might be an issue.
regards
 
Chris Mathews
Ranch Hand
Posts: 2713
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry, I missed the fact that this was for a clustered environment... I guess I should actually read the post before I respond.
Anyways, what I intended to suggest was a System Property that would point the application to a configuration file. This way the configuration information could be dynamically changed without restarting the server. Putting the actual properties file on the System Classpath you would eliminating the ability to change this information without restarting the Application Server.
However, for this to work you would need to specify the system property on each node and each node would have its own copy of the config file. This is probably not the ideal solution.
In the case of clustered applications the only real way to truely share information across the cluster is to use JNDI. However, depending on the type of information, quantity, and violatility; JNDI might be swatting a fly with a sledgehammer...
Even in a clustered environment you could use the properties file approach, however each node would need its own copy of this file. Therefore, a change to the configuration file would require the new file to be copied to each and every node in the cluster. This of course is opening up the chance for human error if the admin forgets to copy the file everywhere. However, this might not be a big deal if the file changes rarely or never changes.
In other words, I am going to take the ultimate cope out and say it depends on your application.
 
Kunal Sharma
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Duplicating configuration file is certainly a maitainance issue for our product and is not acceptable. Here is my thought to address this issue in a clustered environment. It may not make sense but I'll just share it here and see if that helps you in coming up with some better ideas.
Here is a little background within context:
1. My application has Configuration class that reads and caches configuration information. It provides high level intereface to access parsed configuration information.
2. The application also has a singleton class i.e. ApplicationManager which is responsible for instantiating Configuration class and holds a reference to the object for the duration of the application. Other modules access configuration information through the ApplicationManager interface.
3. In clustered environment, each node will have it's own instance of ApplicationManager and will have a copy of Configuration class.
I am trying that ApplicationManager on one node instantiates the Configuration class and stores it in the JNDI. ApplicationManager on other nodes will get reference to the Configuration object from the JNDI.
Now the issues which I have with above approach:
1. How to pass configuration file PATH information to the ApplicationManager? Certainly don't want to duplicate information on each node.
2. How can I make only one node constructing Configuration object and then sharing it with other nodes?
If there anything like master-slave nodes in J2EE, how can i distinguish them programatically? That way ApplicationManager on master node will instantiate Configuration and others will get it from JNDI.
If there nothing like master-slave nodes in J2EE, then ApplicationManager on each node will check if Configuration object is available in JNDI or not before attemting constructing one. In this case, how to isolate ApplicationManager on multiple node from constructing Configuration object?
I am relatively new to J2EE, so please excuse my ignorance on the subject.
regards
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic