[Hawkular-dev] About configuration

[Jay Shaughnessy]

 From what I can see at the moment H Alerts will depend on H Bus, and be 
deployed in WFly via the nest.  I see no use case past that at the 
moment.  As such, using standalone.xml seems like an obvious choice and 
I expect that's what we'll use.  If and when we ever need to be consumed 
in another way then we, or the community, could add another 
configuration option.

On 2/5/2015 11:01 AM, Lukas Krejci wrote:
> 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
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>