Because to me, it looks simpler to have a hawkular-server.properties (or
.yaml/.json/.xml) which groups all the hawkular components configuration
(from adapters to applications).
I have the feeling that inserting our configuration in the Wildfly
config file will make building assemblies and setting up integration
tests more difficult.
Le 05/02/2015 16:25, John Mazzitelli a écrit :
>> 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 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.
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