6 Replies Latest reply on May 11, 2011 9:01 AM by kcbabo

    Auto-generation of config Models?

    dward

      While I was going through and tediously adding javadoc comments to all the config Models, the obvious slapped me right in the face: This is all incredibly BOILERPLATE code.  There is no reason that we should have to code this, and maintain them in git.

       

      What I would like to do is write a maven mojo (representing another maven goal) for our switchyard plugin.  One that generates the Models for us from the XSDs that we already have in place.  This would be part of the generate-sources phase (or whatever it's called in maven) of the build.

       

      Now, my second thought was, "Ummm... why aren't we using JAXB and it's source generator for this config stuff again?"  There are still very valid reasons:

      1. The lower-level Configuration API (which resides underneath the higher-level Model API) is very flexible, and allows developers and users to ad-hoc extend and use config sources without ever needing to write a Model in the first place. JAXB doesn't have this.
      2. Still providing the BaseModel functionality allows developers and users to override anything generated, or even write against it without generation if they don't want everything the generation does.  And they will STILL get the benefits of the marshalling features. JAXB doesn't have this.
      3. An important feature of the Configuration and Model codebase is auto-merging.  This is something we depend upon when our Model Scanners return their results to the ConfiguratorMojo, and it needs to merge all the model data.  JAXB doesn't have this.
      4. The code required to marshall/unmarshall Configurations and Models is one line.  JAXB isn't too hard to use, but it's more than one line.
      5. The namespace-based versioning features of the Model APi is pretty powerful.  Honestly I'm not sure what is available in that regard from JAXB.
      6. The Configuration and Model codebase is not dependent upon an XML representation.  Yes, we currently only have 1, which is DOM-based, but that is hidden from the rest of the code.  JAXB is XML-only.

      There's probably more reasons, but I think the above is sufficient.

       

      One other thing I would like to do as part of this work is somehow get rid of the "v1.V1" stuff.  I need to give some thought for how we can future-proof as much of our model-dependent code, but what I do know is that the "v1.V1" stuff feels hokey when you're coding against it.

       

      I was first thinking that my time-estimate to do the above work would be 3 days or so, but you know how that goes, so I would want to be given a week to do it.

       

      Comments and criticism welcome, as always.

        • 1. Auto-generation of config Models?
          dward

          A couple other points:

          1. Writing Models by hand can be error-prone.  Auto-generating them will remove that risk.
          2. I would like to do this work for 0.1, as M1 is pretty much wrapped up.
          • 2. Auto-generation of config Models?
            kcbabo

            JAXB initialization can be awfully slow, IIRC.  Perhaps not a huge deal when parsing an application configuration, but we had talked about using the same underlying configuration support for runtime configuration as well.  In that case, it should be possible to read runtime configuration quickly during startup and not have a significant impact on startup cost.  This really shows in environments like Java SE, OSGi, Tomcat, and AS7, where the initial startup time will be 1-3 seconds and if we add 2-3 seconds with a JAXB init, that's gonna stand out like a sore thumb.  Anyway, not super relevant to your initial request for comments, but it's an important consideration to keep in mind.

             

            In terms of eliminating boilerplate code, I'm all for that provided it makes the configuration "feature" more useful.  And by that I mean adding more configuration models becomes easier, less error-prone, etc.  We have to balance this enhancement against a large set of features that we want in 0.1.

            • 3. Auto-generation of config Models?
              dward

              Understood Keith. +1 on everything you said.  I'll add a JIRA for this for 0.1 to keep track of it.  Thanks.

              • 4. Auto-generation of config Models?
                dward
                • 5. Auto-generation of config Models?
                  dward

                  Cross-linking related discussion:

                  When implementing configuration ...

                  • 6. Auto-generation of config Models?
                    kcbabo

                    I think the existing configuration setup is cool and I think a feature that makes it easier to generate/map config to value objects would be even cooler.  This might be something that is worth looking closer at in 0.2 or 0.3 with the following perspective:

                    • Implementation experience and conventions from the existing models we have produced
                    • A hard look at whether JAXB is the appropriate technology for this capability.  I raised concerns above and there have been various other emails floating around describing how JAXB can be a significant pain for configuration.
                    • Approaches that other teams have taken, perhaps short of auto-generation but with a similar set of benefits