10:01 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev