2 Replies Latest reply on Sep 16, 2002 2:10 PM by ejain

    Application level env-entry

    ejain

      How does one best share configuration data between beans within an application? I am aware of env-entry in ejb-jar, however this is only suitable for use within a single bean.

      <env-entry>
      My lucky number.
      <env-entry-name>luckyNumber</env-entry-name>
      <env-entry-type>java.lang.Integer</env-entry-type>
      <env-entry-value>42</env-entry-value>
      </env-entry>

        • 1. Re: Application level env-entry
          mikefinn

          EJB 2.0 spec does not allow for this, AFAIK. EJBs are not allowed to see each other env crap.

          The other problem I had was how to share env info between not only EJBs, but Web App components as well.

          One solution is to have a 'global' properties file somewhere URL-loadable, and point to it from your "env-entry"s like:

          <env-entry>
          <env-entry-name>globalConfigFile</env-entry-name>
          <env-entry-type>java.lang.String</env-entry-type>
          <env-entry-value>http://path/to/configfile</env-entry-value>
          </env-entry>

          I haven't done it, but it's an idea.

          I got sick of maintaining this kind of stuff in ejb-jar.xml and web.xml, so here's what I did.

          I wrote an MBean to act as a deployer of properties, specifically, as a deployer of *properties.xml (of my own schema) files in the deploy directory. The deployer MBean then launches a 'deployment' mbean for each config file. The properties are then bound by the deployment mbean into JNDI to a known path (including app/module name).

          That way I can get to them from anywhere, since each app knows its "name", therefore the path to its env entries. These are basic key value pairs, where values are presumed type String.


          It's similar to the properties-service, but instead of putting them into System.properties, they are in JNDI.

          This probably has drawbacks (I have not considered the impact of clustered JNDI for example) and there will be folks who think there something bad about this, but it works very well for us. Especially great is the ability to hot-deploy these properties.

          FWIW,
          #mike

          • 2. Re: Application level env-entry
            ejain

            Thanks for the idea. Looks like I won't get around writting an MBean for this...