[Hawkular-dev] About configuration

[Lukas Krejci]

On Thursday, February 05, 2015 10:25:53 John Mazzitelli wrote:
> > > 3) Why not try to have all our configuration set in standalone.xml? If
> > > we
> > > are going to be deployed in Wildfly, it would be nice to have everything
> > > (not just our config, but the config for the wildfly subsystems too) in
> > > one place. This also allows us to piggyback on jboss-cli - we simply use
> > > the jboss-cli to have a cmdline interface to our configuration.
> > 
> > I'd rather keep our apps config out the Wildfly config.
> 
> What is your reasoning for wanting to keep our apps config out of Wildfly
> config?
> 

The main reason for me is that I don't want to require running in Wildfly. 
IMHO, the core component implementations should be consumable as libraries and 
for that requiring wildfly is a big no-no.

At the same time the core impl needs to be configured somehow, too. We can say 
that that can only be done by "filling" the configuration "pojo" 
programmatically and leave the exercise of reading and storing the data to the 
user of the library. Or we could use commons configuration for a similar 
purpose with the benefit of it already knowing how to read/persist. Or as I 
said, we could use DMR or whatever else. I just don't want to tie ourselves so 
strongly to Wildfly. If we can only be configured when deployed inside a 
container then I think we will not support an important usecase of us (the 
individual components of hawkular that is) being able to function as a 
library.

That said, I wholly agree with you that IF we are deployed inside Wildfly then 
standalone.xml is the exact place to read the config from.

> The reason why I say it would be nice to use standalone.xml for our config
> is:
> 
> 1) all configuration, for everything, is in one place. Remember JBoss 4,
> with all their many .xml config files? It was hard to manage, which is one
> reason why they went to a single .xml file (though, granted, I believe they
> are thinking about making it possible to import .xml files into the main
> config - don't know if that's available yet).
> 
> 2) It gives us, for free, a CLI - we don't have to write and maintain one.
> If everything is in standalone.xml, we can use the JBoss CLI to look at our
> config and change it along with the rest of the wildfly subsystems.
> 
> 3) If our components consist of Wildfly Extensions, then this is how you
> configure that extension. So it would be natural to have all config (for
> the extension and the other pieces of the component) in the same place.
> 
> 4) Address and port assignments. Right now, standalone.xml allows you to
> define socket binding groups - allowing a "one stop shop" to define all
> your port bindings. Adjusting the port-offset provides a nice way to easily
> offset ports so you can run multiple components on the same box. If we have
> different configs (that need to specify hostnames/ports), we now have
> multiple places where this is configured - thus opening up to possible
> conflicts plus just a pain to have to now go to different places to
> configure bindings. The port bindings in one place is nice for
> manageability.
> 
> The one negative of this approach is if our components can run outside of
> being embedded in Wildfly, we lose all of the above. We would need our own
> configuration mechanism (and CLI) if we can run outside of WildFly.
>

So in another words, we're on the same page.

> But I see alot of positives for putting our subsystem configuration in with
> the rest of WildFly subsystem configs.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev