When implementing configuration ...

[kcbabo]

I just added configuration support for Atom bindings through the Camel component here.  While doing so, I uncovered some areas where I don't think we've reached agreement in terms of a consistent approach.  If you check out the link, you'll notice the following in the code:

• The model implementation has a no-arg constructor which allows the configuration model to be created from scratch.  This is required in order to provide tooling support and is useful for testing.
• The model interface defines getters and setters for configuration values (see previous bullet).
• The model implementation does not store configuration values in local variables - it relies on the underlying configuration model for storage.
• Unit tests cover
  • Creating a model from scratch
  • Reading an existing model
  • Writing a model

I'm not saying the above is absolutely right, but I am raising it as a potential set of best practices for developing config support.  For others that have used the config APIs, I would like to hear your opinion on this approach.  We are going to start writing a lot more config models in the near future, so now's the time to work this out.

[beve]

Hmm, I think I might be guilty of some of the above when implementing components. I'll take a look through the Camel and Clojure components and create jiras for the issues I find.

[kcbabo]

We didn't have an established approach in place previously, so you're not really guilty of anything. :-)  That said, if you agree with the approach in the original post then it would be nice if we could update the existing configurations up to form.  So yes, please file JIRAs if you can. :-)

[dward]

I really want to get this done before we end up with a mess of config models strewn all over the place:

https://issues.jboss.org/browse/SWITCHYARD-152

Here's the forum reference:

Auto-generation of config Models?

[tfennelly]

I think the idea of generated code is good in theory, but in my experience, generated models end up looking like a dogs dinner in practice e.g. XJC generated JAXB code.  Couldn't we use a custom config on one of those static code analysis tools (PMD, FindBugs etc) to look for unwanted patterns in the model code?

[tfennelly]

Also... I think you could sink a huge amount of time into something like this.

[dward]

• We wouldn't need convention if we had this.
• There's a significant (not huge, but significant) cummulative amount of time in everyone having to write their own config models.
• This would eliminate config model errors.

[kcbabo]

You always need convention, that's what guides the implementation of the auto-generation feature.  We are just now discussing what those conventions should be.  I agree that auto-generation is a desirable end state, but it's not something that we should undertake at this point.