Obix Configuration Framework 1.0 Released

Discussions

News: Obix Configuration Framework 1.0 Released

  1. Obix Configuration Framework 1.0 Released (22 messages)

    The Obix configuration framework is an open-source XML and Java based configuration framework which provides developers with the ability to develop configurable software applications.

    In this release you will find;
    • A flexible format for encoding configuration data in XML
    • A straightforward means of accessing the data through Java objects.
    • Facilities for modularizing configuration data, allowing configuration files to be imported into (included in) each other files
    • Auto-detection and auto-reload of changes to configuration data
    • Integration into Java applications via JMX and J2EE listeners, JNDI support as well as the option to use plain Java classes
    • An extensible easy-to-use plug-in API which supports initialization

    The initialization features in the API can be used by the framework's developers to provide initialization utilities for other open source frameworks such as Apache Log4J, Hibernate, and Commons DBCP.

    Obix is a lightweight configuration framework, and is not really intended as competition to Spring. If being compared to Spring, then it is more for legacy environments not intent on using Spring, or environments where IoC is not required.

    Moreoever, Spring enables configuration by injecting properties within beans, Obix on the other hand is concerned primarily with system initialisation and the externalization of configuration data. Though this may appear to but Obix at odds with Spring, we are currently working on utilities for integrating Spring and Obix.

    Threaded Messages (22)

  2. Why would I use Orbix and not java.util.Properties?

    Thanks.
  3. system configuration[ Go to top ]

    We are actually trying to find a best way to configure system type of data. For example, a utility class (interface) queries the system to get a prefix about the system, then, the application starts with a right set of configuration (properties).

    As I understand, Spring doesn't handle this by default(I may be wrong because Spring is changing faster than I can follow up with all its features...) If I want to use different log4j properties for development laptop, integration test server, system test server, UAT server and then production server. We have to create different scripts in order to achieve that. Or use ant build script to swap the properties files.

    Can this framework handle such a need? In addition, how does this compare to the Apache Commons Configuration 1.2 framework?

    Thanks,

    Jason
  4. re: system configuration[ Go to top ]

    Certainly! Obix has the concept of configuration modules,
    so there are several ways you can play this.

    You can have a global (root) config, and import the configuration modules for your various systems into it. So your config sets woudl look like this:

    <configuration>
    <configuration-module moduleId="dev">
    mydev-config.xml
    </configuration-module>
    <configuration-module moduleId="uat">
    myuat-config.xml
    </configuration-module>
    ..........
    ..........
    ..........
    </configuration>

    To access your dev config in Java, you make the call

    Configuration dev =
    Configuration.getConfiguration().getModule("dev");


    If you have a J2EE app, or you are willing to use system properties, there are alternatives to using modules too.

    I hope this answers your questions ...
  5. re: system configuration[ Go to top ]

    Sorry, got the syntax in the example slightly wrong. It should be:

    <configuration>
     <configuration-import isRelativeLink="true"
    moduleId="dev">
       mydev-config.xml
     </configuration-import>

     <configuration-import isRelativeLink="true"
    moduleId="uat">
       myuat-config.xml
     </configuration-import>
    </configuration>


    This klets you import your dev and uat configs into the same set. The previous syntax would have meant specifying the config inline (i.e. within the same file).
  6. Configuring for different systems[ Go to top ]

    I dont know about Obix, but the framework I work on, SmartFrog (http://smartfrog.org/) has that notion of per-installation configuration built in through inheritance. You define a generic template and then different configurations can extend it with different options.

    So your test box can have mysql and jboss on the same host, log to console, while the server can have jboss on one host, mysql on the other, and the logs rotated with email forwarding of severe errors.

    Use ant to swap property files is bad as you end up with different binaries for each target platform, and you know things will go wrong.

    Other options
     -using JNDI to read config data
     -readin config data from the db
     -having a per-host .properties file and reading that in based on your hostname.

    -Steve
  7. Obix was conceived purely because of the limitations you have with things like java.util.Properties and ResourceBundles....

    Obix uses XML formats for configuration, in line with a lot of other tools (and J2EE standards for that matter). This means that you have the ability to store denser data e.g. multiple values for each config-entry. Also the ability to import/include configuration files into one another.

    For enterprise environments, you can make hot changes to configuration files, and these will be picked up automatically without you having to re-start your
    application. You also have declarative means of reading config, such as J2EE context listeners, which means that you don't have to write any of your own code to do so.

    There are also JMX managers, for environments where this is neccessary.

    Obix also lets you manage your system initialization process, by providing you the ability to invoke adaptors and plug-ins. It also provides plug-ins to let you initialise other open-source frameworks like Hibernate and Log4J...

    It is in effect a framework that specialises just in configuration and initialization, and as a consequence offers you a whole breath of features....
  8. Cross-references[ Go to top ]

    One of the problems encountered in Configuration Management is cross-configuration, in which different parts of the app need to take the same parameters?

    How does Obix handle this? Cut and paste? Or by having links that can be shared between things?

    I ask as both the CM frameworks I am involved in, Smartfrog and the XML-variant, CDL, which is being standardised in the Grid standards bodies, make a strength of letting you share references between things you configure. Its one of the strengths of having a "unified" CM language; instead of just having one single language to describe configs, you have to deal with keeping all the bits consistent.

    Still, having one single format to keep consistent is better than scattering port numbers, hostnames and passwords through source, .properties files and web.xml files. And if deployed things are configurable through JNDI, then they should be configurable through different mechanisms, such as LDAP servers, SmartFrog, Orbix or even databases.

    -steve
  9. re: Cross-references[ Go to top ]

    Obix lets supports links, and as such allows you to include one file in another. Pretty much the same way an import works... The syntax is along the lines of


    <configuration-import isRelativeLink="true"
                moduleId="my shared link">
       shared-config.xml
    </configuration-import>



    Hope this answers your question.
  10. What does Obix Configuration give me that I don't already have with Commons Configuration?
  11. Commons merely gives you generic Java interfaces for reading configuration. Obix on the other hand gives you xml formats for configuration, means of accessing this data via Java. It also has features to enable you to import/include configuration files into one another, and to create modular configuration sets.

    For enterprise environments, you can make hot changes to configuration files, and these will be picked up automatically without you having to re-start your application. You also have declarative means of reading config, such as J2EE context listeners, which means that you don't have to write any of your own code to do so.

    There are also JMX managers, for environments where this is neccessary.

    In effect, Obix concentrates on managing configuration info, and system initialization. This specialization means that it offers you quite a few features where this is concerned.
  12. For enterprise environments, you can make hot changes to configuration files, and these will be picked up automatically without you having to re-start your application.

    Is configuration reload transactional? Hot reconfiguration is pretty limited without the ability to rollback the configuration if things go wrong. A simple typo in a config file can render an application unusable.
  13. Rollback[ Go to top ]

    If you keep your config files under SCM, then rollback is a matter of going back to an old version. That goes for any file-driven deployment mech.

    One thing I've done in the past is have an ant script to copy away the existing .WAR file (with a datestamp) on a deploy. That gives you a history of upgrades, and an easy way to rollback from the ssh prompt in a hurry.
  14. Rollback[ Go to top ]

    I wasn't that clear in my first posting, but see my response above...
    P.
  15. Re: Transactionality[ Go to top ]

    Is configuration reload transactional? Hot reconfiguration is pretty limited without the ability to rollback the configuration if things go wrong. A simple typo in a config file can render an application unusable.

    Reload is transactional, in the sense that if it fails to read the entire configuration set, it sticks with the last working one. In other words, it doesn't replace the currently "good" configuration set, until it has managed to load a new one in its entirety. So the risk of your application crashing, due to a reload, is quite minimal--if not non-existent.
  16. Re: Transactionality[ Go to top ]

    Reload is transactional, in the sense that if it fails to read the entire configuration set, it sticks with the last working one. In other words, it doesn't replace the currently "good" configuration set, until it has managed to load a new one in its entirety. So the risk of your application crashing, due to a reload, is quite minimal--if not non-existent.

    Reload being transactional is a great step in the right direction. Loading a config set is only the first step, and in XML config case not many configurations will really fail there; you can always validate the config using a schema... The real problem is the human error that is not a simple syntax error. For example, mistyping an IP address in the configuration, your application still cannot function properly, and there's no hot deploy...

    Now this is a much harder problem to solve. One possible solution is to allow the developers to plugin configuration test classes for each configuration option. (possibly provide standard test classes for check if an ip address is available, and so on..) When the config system reloads the configuration it will then run the test code, if any of it fails the whole config will be rolled back to the last known working one...

    This is what we really need.

    I know this still won't solve all the problems. "Make things more idiot-proof, and we'll find even better idiots."

    P.
  17. Re: Testing for human errors[ Go to top ]

    The real problem is the human error that is not a simple syntax error. For example, mistyping an IP address in the configuration, your application still cannot function properly, and there's no hot deploy...Now this is a much harder problem to solve. One possible solution is to allow the developers to plugin configuration test classes for each configuration option. (possibly provide standard test classes for check if an ip address is available, and so on..) When the config system reloads the configuration it will then run the test code, if any of it fails the whole config will be rolled back to the last known working one... This is what we really need.I know this still won't solve all the problems. "Make things more idiot-proof, and we'll find even better idiots."P.

    Reading your post, what you suggest is do-able using an obix lifecycle listener. You can implement your test case as a lifecycle listener, and specify it at the end of the config file using the syntax <execute-after-adapt>, and this will be invoked after the file is parsed and read. if your data is wrong at that point, then throw a LifeCycleException, and that reverts to the previous set.
  18. Re: Testing for human errors[ Go to top ]

    It looks like I should have investigated a bit more before posting. This is good news indeed.

    P.
  19. Configuration Errors[ Go to top ]

    I dont have the links to hand, but it is in configuration errors that most major deployments go wrong. A big cause of this is because everything else gets tested in staging, but those late binding things: -the ipaddr of the db server, the configuration of the level-7 router, the PATH of the user account that hosts the app server, etc.

    With a deployment framework that can configure *everything*, and that includes the routers and the system accounts, then you could be consistent. nothing comes close yet. What you can do is have explicit config systems where as much as you can is fully automated, and data is shared across nodes. So the db is configured with a password and the same password string is passed to the app server.

    The other thing that declarative configuration tools do is let you infer and deploy health stuff. In smartfrog (again, such blatant product placement ;), we have things like a liveness checker that probes for web pages; it can get the path to a page from the run-time generated paths to things like the app server ipaddr and port, the servlet context, etc. Your configuration framework becomes not just the tool to config your system, but a source of information that health checkers can use to validate health.

    What is not there today is any realistic adaptation to failure. Except in those IBM 'autonomic computing' adverts. Things can go wrong in so many interesting ways, its hard to see how the os/middleware can really react to them.
  20. system configuration[ Go to top ]

    I haven't looked at Obix. But if as you indicated you want to change the configuration depending on diffrent environments such as log levels, DB connection parameters etc, there is a simple open source tool that does that and we have used it for 3 years with great success. Look at JFig at source forge: http://jfig.sourceforge.net/. It is specifically dedicated to solve thsi issue and is a small and effective framework. BTW Spring does let you do this. Just use a property file for each environment and in the Spring config file refer to the property as $property and you are done. Hope that helps.
  21. More Configuration Frameworks[ Go to top ]

    Here's a long list of Java based configuration frameworks that I've stumbled upon in the past.

    http://www.manageability.org/blog/stuff/configuration-deployment-frameworks-in-java/view

    Let me know if I forgot any.

    Carlos
  22. One of the important feature of commons-configuration is that it can accept configuration data from various input sources (properties file, XML file, System properties etc). Common properties are overidden. This concept is important in the sense that it allows you to set the default properties and let user overide them with their own.
    Is similar sort of functionality exist in Obix-framework?
  23. Config Framework![ Go to top ]

    Please take a look at this URL:
         http://issues.apache.org/jira/browse/CONFIGURATION-394

    The Configuration framework which we're looking for it is something on top of Apache Commons Configuration and must support Concurrency Issues, JMX issues and most of stores(e.g .properties file, .xml files or PreferencesAPI).

    What weblogic team provides on 'Administration Console' is intersting which through it you can have transactional(atomic) updates on configurations so that are registered listeners be notified.

    The Apache guys insist that this project is out of scopes of Commons Configuration, maybe!

    I've attached a simple configuration framework, take look please.