0 Replies Latest reply on Jan 29, 2008 12:08 AM by Andrew Alsup

    Administering web-app settings (web.xml vs JNDI)

    Andrew Alsup Newbie

      We're migrating from Oracle's OC4J to JBoss AS. So far, I love JBoss.

      However, we have a number of webapps that rely on OC4J's ability to override context-parameter values defined in the web.xml. The orion-web.xml file can be deployed separately from the WAR, making it an attractive mechanism for storing settings that differ depending on the target environment (i.e. DEV, TEST, and PROD).

      We used to provide 3 separate (pre-configured) WARs to the administrators. 1 WAR for each of the target environments. This turned into a mess and wasted time as the deployment servers are accessed remotely via (slow) VPN. The ability to provide a single executable (WAR) while giving the admins the ability to override critical settings defined in the web.xml was very nice.

      The jboss-web.xml provides no similar override feature for context-parameter values. To achieve a similar affect in JBoss, I have created an MBean: JndiPropertyBinder. The JBoss admin can edit a jndi-property-binding-service.xml file in the /deploy directory. The XML file defines the JNDI name to bind a bunch of name/value pairs. The application can then consult JNDI at runtime. The web.xml file defines the required resources via standard "resource-env-ref" tags. The XML file looks something like this:

      <mbean code="andy.jboss.mbean.JndiPropertyBinder" name="andy.jndi:service=JndiPropertyBinder_MyApp">
       <attribute name="JNDIName">java:/JndiPropertyBinder/MyApp</attribute>
       <attribute name="Properties">
       reportsServerUrl=http://www.myserver.com/oracle/reports
       reverseProxySpoof=true
       allowDocUploads=false
       </attribute>
       <depends>jboss:service=Naming</depends>
      </mbean>
      


      The only change to the web-app code is that the values are now obtained from JNDI rather than from the ServletContext.

      Does anyone have any suggestions for other ways to do this? Are other folks actually still building separate WAR/EAR artifacts for each target environment (DEV, TEST, and PROD)?

      Many thanks,
      Andy