3 Replies Latest reply: Jun 5, 2012 1:19 PM by 939774 RSS

    Configuration and administration best practice


      I am new to WebLogic and AppServers in general; I work on a team that is migrating an existing application to be a Web application (support for WebLogic and JBoss are planned). Sorry for the long post by I felt this was needed for the readers to well understand the problem.

      The questions:

      - Is there a set of best practices or perhaps standard ways for administrators to configure their deployments. By configuring, I mean providing application-specific options to an application to be deployed?
      - Are there any UI to help them do so?

      As the above questions are pretty generic, I provide below some insight on what I looked at, hoping it will help people to better understand my aim.

      Main technical solutions I have found up to now:

      Embedding configuration files into the ear or war:
      - Explanation: it covers different possibilities, for example putting "context-param" tags into the web.xml or providing a "foo.properties" files in the archive.
      - Pros: easy from the developer point of view.
      - Cons: Burden is on the admin, the admin needs to unpack the war, change the files, repack the war to change a single parameter. An external tool with UI could also be provided for these operations but in this case it means more development time. In addition, having the admin modify the archive even through a tool, is not something reassuring from a maintenance perspective.

      Using an external source of data
      - Explanation: Having something like a JNDI classname/url passed to the app (for example through "context-param"). The JNDI would contain mapping from option keys to values and would be read by the application at deployment time to overwrite default option values.
      - Pros: An administration tool fully decoupled from the application can be run to update the JNDI and change configuration in an easy way for the administrator.
      - Cons: more understanding by the developers need to be acquired before being able to do so (mostly about JNDI and App server resources). The administration tool needs to be fully developed.

      Using Weblogic deployment plans
      - Explanation: Put options in a deployment plan, for example have the plan adding them as "context-param" entries in the web.xml file.
      - Pros: easy from the developer point of view.
      - Cons: seems to be WebLogic specific (if somebody knows something similar on JBoss, let me know).
      - Unknown: There may be a way to have the entries being changed through the Weblogic admin console but I could not achieve to do so (entries do not appear on the Deployment Plan/Tuning parameters tab). If it cannot work this way, an external deployment plan generator with a UI is needed.

      Edited by: user754999 on May 25, 2012 7:44 AM
        • 1. Re: Configuration and administration best practice
          Even a discussion would be useful, it does not matter if you do not know "The" solution. Anybody there ?
          • 2. Re: Configuration and administration best practice
            You can have a mix between 2 solutions with a config into an XML file.

            In dev (for example production mode = false) the application get his configuration directly from XML file.
            In production, it's the same XML file format, but the XML is downloaded from a datasource.

            You have the same format (XML) of config with file in dev (easier for developpers) and in a database (easier to administratior rather repackaging an EAR at deployment).

            A king of framework class is doing the job of choosing the reight place depending on the env.

            The format is the same but the source different. Everydody happy ;))

            Edited by: user1094281 on 31 mai 2012 09:29
            • 3. Re: Configuration and administration best practice
              Thanks for your useful reply, it helped me designing the framework a bit more. I provide hereafter an overall picture of my current thoughts it can always be useful to others.

              Here is a solution that I feel is a good compromise:
              - Having a bunch of default options files embedded in the war.
              - Providing an appconfig.xml file to 'configure the configuration' in the WEB-INF directory. This file will specify a class name and a set of parameters; these will be used to construct the corresponding Java object at server startup (using reflexion). This object needs to implement a Java interface, let's call it 'Configuration'. The interface only provides access to key/values pair (a bit like a map). Internally, it could access any source of data to obtain these pairs (file, database...) but our code will not care. (On this topic, it is also worth having a look at Apache Commons Configuration API).
              - Internally, we use the Configuration object provided by the user. If there is no entry in it for a setting, we default to the settings stored in the files embedded in the war.
              - We provide (one or more) implementation of the Configuration interface and associated administration UI.

              Pros and Cons:
              - Depending where the admin wants to store the configuration he can chhose it by updating the appconfig.xml file in the War. This means uncompressing/recompressing the War but it is done only once.
              - The admin can then modify the configuration from wherever he made the appconfig.xml point to. If he/she uses our classes, a UI is available.
              - This approach also allows thirdparties integrating our application to implement their own Configuration object and administration UI, making the framework pretty flexible.