3 Replies Latest reply on Feb 4, 2009 6:51 AM by heiko.braun

    db properties reorg

    tom.baeyens

      heiko,

      can you explain the purpose of the reorg of the db properties? i couldn't find what was extra things became possible. probably there is some aspect that i didn't get.

      ideally i would like to move to the following situation:

      * a config module that has the default persistence configuration and produces it in a jar file in the repo.

      jbpm configuration would contain a reference to hibernate.cfg.xml *and* hibernate.properties

      hibernate.properties would contain the hypersonic in memory configs.

      * the db module approx as it was: containing ${database}.properties files for all the db's

      in the parent pom, there is a section that takes the specific database properties file, resolves the properties and overwrites the default hibernate.properties with it.

      ------------------------------------------------------------------------

      do you see problems with this approach ? things that would be invalidated that you've build just now ?

      the difference between how it was originally is that by extracting the default configs in a separate module, we remove the necessity for each module to have its own configuration files in the resources. so we can prevent spreading copies all over the code base that have to be kept in sync.

        • 1. Re: db properties reorg
          heiko.braun

           


          Ideally i would like to move to the following situation:

          * a config module that has the default persistence configuration and produces it in a jar file in the repo.


          right, that something we agree upon. Just that the current configuration resides with the jpdl module which produces a a config jar that goes into the repo: jbpm-jpdl-4.0.0-SNAPSHOT-config.jar

          Another requirement is to switch between hibernate managed connections (simple tests, jdbc properties) to container managed connections (intgeration tests, datasources). This is something we already did in jBPM3
          and I simply wanted to leverage the existing build, which is non trivial.

          Hence the change from hibnerate.cfg.xml+hibernate.properties to a single hibernate.cfg.xml which includes the connection settings.

          So basically, the db.properties (i.e. mysql.properties) disappeared and have been replaced by hibernate.mysql.cfg.xml, which ship with the jpdl-config.jar.

          Currently this get's expanded into every module that needs db connection settings and is used by the installer to finally create hibernate.cfg.xml and *-ds.xml for deployment into the AS.

          The build is driven by profiles.xml which contains the connection properties (i.e. Qa on your local box vs. jboss QA environment) and by the 'mvn -Ddatabase=mysql' switch, that defaults to hsqldb.

          Does that answer your question?


          • 2. Re: db properties reorg
            tom.baeyens

             

            "heiko.braun@jboss.com" wrote:
            Another requirement is to switch between hibernate managed connections (simple tests, jdbc properties) to container managed connections (intgeration tests, datasources).


            that was the use case what i forgot

            i don't like the current set up yet. i got the feeling that it must be possible to make it less complex.

            but i'll give it some time to get used to it and then see where and how (if at all) things need to be improved.

            one thing that i haven't figured out yet is the configuration variation for the pvm tests. in the pvm, we need a jbpm.cfg.xml which is almost as the full configuration file, but it should exclude the jpdl things (only one or two things).

            i'm still chewing on how we can get to one unified configuration source for all modules... not trivial.

            • 3. Re: db properties reorg
              heiko.braun

               



              i'm still chewing on how we can get to one unified configuration source for all modules... not trivial.



              We got that already, but maybe I don't understand you correctly.
              What do you see missing?



              i got the feeling that it must be possible to make it less complex.


              complexity doesn't matter at build time. it aims at automation anyway.
              but it's complex, I agree. Hence the reason to leverage the experience and build constructs that thomas introduced in jbpm3. Remember that there is already 6 month work in it and a lot under the covers that is not obvious at a first glance.