J2EE Application Configuration Challenge - what is best??

Discussions

General J2EE: J2EE Application Configuration Challenge - what is best??


  1. I am interested on getting some opinions (hopefully based on experience) on a debate topic I have going...

    We have a need to store some configuration information for our J2EE applications. We use EJB, JMS, servlets and we are writing some connectors.

    The question is WHERE to put application or server configuration information? We can declare it in deployment descriptors, the appserver's JNDI, an external JNDI (perhaps based on LDAP), in a database or we can just hard-code it.

    The configuration would need to be dynamic. Some stuff would change more frequently than other stuff, but the fact that we dont hard code it in the first place is due to the fact that it may need to change at some point.

    The sort of information we want to be able to set can be categorised as follows:

    Global Configuration:
    Logging. Log4J layout patterns, logging levels etc. In general this would look the same for all components of the system - however we might want to turn on a higher level if we are tracing a problem.

    Per Location Configuration:
    We will be deploying the same applications to servers in New York, Tokyo, Hong Kong, Paris and London. Each location will have slightly different settings for some things. For example the network address of other servers the components have to connect to will be different in each location.

    Per Application Configuration:
    There are some application level settings that you may want to be able to change frequently. These settings might be deal limits, timeouts etc etc.


    Anyway; The question is where to put all of this configuration?

    The file-system is out. Access to the filesystem is not allowed - and it is not replicated globally. Not to mention little security.

    Some Appserver's JNDI implementations dont allow you to store anything but CORBA objects in their JNDI tree. Other JNDI implementations are not persistant.

    Putting it the deployment descriptors means that you cannot change it at run-time. You generally dont have access the java:comp/env portion of the tree - it is read only as well. A change means a re-deploy.

    Putting it in a database *sounds* like a good idea - but I think there will be a performance hit - and the relational model is not necessarily good for properties with a hierarchy.

    The other option is a 3rd party JNDI implementation (ie perhaps based on LDAP).

    I would like to get some informed opinions - some feedback on how other people have tackled this problem. This problem has to have been faced before.

    Cheers,
    Nick


  2. Nick,

    Maybe you can use the JMX (Java Management Extensions) framework for this. With this framework you can configure your beans at runtime, I dont know if it also defines a storage mechanism for the settings but I would store this in a database table and read it in on object creation. jBoss has the notion of services that are JMX MBeans.

    hope this helps,

    Joost.
  3. Why is file system out? You can secure access to files if you like through java access control.

    I have built a Configuration Service as a JMX MBean and it works well with JBOSS. The MBean gets strted by JBOSS on start up. It scans the whole project directory looking for property files of a given name and reads the properties.

    It's also accessible from a browser through the JMX HTTP adapter, so that you can dynamically update configuration data runtime.

    Pranab

  4. >> Why is file system out? You can secure access to files
    >> if you like through java access control.

    Access to the filesystem from your ejb's is out because;
    1) It is not allowed in the spec (for the following good reasons) - ie the appserver is required to prevent it.
    2) There is poor security on the filesystem
    3) It limits the portability of the beans if there is a requirement to have a duplicate, identical filesystem on all servers.
    4) There is no transactional support
    But probably most importantly;
    5) It is difficult to replicate a filesystem
    6) If there are 10-20 servers, it is very difficult to manage the configuration if you have to visit each machine to change the configuration.

  5. I vote for storing it in LDAP accessable via JNDI and building a web interface to update and administer it. We have done exactly that.



  6. I must admit that is the way I am leaning - I was just wondering if I was making it too complicated (failing to see the forest for the trees)

    Cheers,
    Nick
  7. Dat, does you implementation store properties as individual objects or as one serailized object?
    What mechanism do you use for dynamic updates
  8. There are a number of objects, related properties are grouped together as attributes in one object, otherwise we would have a ridiculous amount of objects.
    In our situation, changes to the properties occur rarely but if dynamic updates are required, it's a relatively easy task via JNDI to do so.

  9. Seems like a very good start for a project with lots of property-files. Could you describe your design a bit more?

    E.g.
    Is your service an Entity EJB with BMP?
    Who registers the service with the MBean Server, and how is that done?

    /Fredrik