4:01 a.m.
Hi everyone,
Yesterday Lukas asked on IRC if there was a discussion about
configuration. AFAIK, there wasn't, hence I'm sharing how we support
configuration in metrics.
# Metrics REST server
The REST server runs on top of Wildfly.
Configuration is a set of key/value pairs (configuration properties)
defined by the following sources, in order of precedence:
* system properties (-Dkey=value)
* external java.util.Properties file, which path is defined by the
metrics.conf system property; by default, <user.home>/.metrics.conf is
used (if it exists)
* internal java.util.Properties file (META-INF/metrics.conf)
The rationale behind is that the system should be able to:
1. start with reasonable defaults
2. switch to another configuration easily
# pTrans
pTrans is different because it's a standalone application, so it's much
easier to follow the daemon configuration habits.
pTrans takes a path to a properties configuration file as a program
argument. This argument is mandatory.
# Configuration file format.
metrics started with properties file and I think it's fine.
But if we feel the need for a more structured format, we should pick
something which can be easily parsed by a variety of programming
languages, especially languages widely used for administration (Python
and Ruby).
Regards,
Thomas
4:41 a.m.
I am not for or against using properties for config simply because I do not
yet know what the requirements for the configuration will end up being.
On the other hand I feel we should from the start use something that is
capable of handling more structured configuration formats without us needing
to rewrite all the configuration handling code if that need arose (by
abandoning java's Properties and moving to something different).
Hence I propose using Apache Commons Configuration for reading the
configuration files. I think Artificer uses it, too, so Brett et al. can
comment if that would be the right thing to do or not.
Commons configuration supports XPATH for accessing nested data so working with
hierarchical properties should be quite nice with it. The disadvantage is that
it drags several other deps with it -
http://commons.apache.org/proper/commons-configuration/dependencies_1_10.....
Other option could be to commit to a single configuration format and use a
dedicated parser for that with minimal deps. For example if we chose JSON as
the config format we could use JBoss DMR for reading/writing such configs. The
advantage of that approach is that DMR is absolutely tiny with no external
deps. The disadvantage is that JSON cannot have comments (which is easily
amended by a custom reader that would strip the comments before the contents
are passed to DMR for parsing (a recommended approach from the author of JSON
- https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr)).
On Thursday, February 05, 2015 11:01:53 Thomas Segismont wrote:
Hi everyone,
Yesterday Lukas asked on IRC if there was a discussion about
configuration. AFAIK, there wasn't, hence I'm sharing how we support
configuration in metrics.
# Metrics REST server
The REST server runs on top of Wildfly.
Configuration is a set of key/value pairs (configuration properties)
defined by the following sources, in order of precedence:
* system properties (-Dkey=value)
* external java.util.Properties file, which path is defined by the
metrics.conf system property; by default, <user.home>/.metrics.conf is
used (if it exists)
* internal java.util.Properties file (META-INF/metrics.conf)
The rationale behind is that the system should be able to:
1. start with reasonable defaults
2. switch to another configuration easily
# pTrans
pTrans is different because it's a standalone application, so it's much
easier to follow the daemon configuration habits.
pTrans takes a path to a properties configuration file as a program
argument. This argument is mandatory.
# Configuration file format.
metrics started with properties file and I think it's fine.
But if we feel the need for a more structured format, we should pick
something which can be easily parsed by a variety of programming
languages, especially languages widely used for administration (Python
and Ruby).
Regards,
Thomas
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
8:09 a.m.
I have a few points:
1) pick one way to configure, not N ways. I've since learned that while it is nice
that the agent has so many ways to configure itself (-D cmd line, agent-configuration.xml,
setconfig prompt, -c <file> command line option, config <file> option, etc.)
its a pain to keep track of it all and making sure all of it works and never breaks along
the line.
2) If at all possible, have a single configuration point (a single .xml file for example),
not multiple files and certainly not multiple files in multiple different directories.
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.
4) Keep in mind installation use-cases - don't make configuration so hard that we have
to write a convoluted installer to get things to run.
Note that standalone.xml has a section for just system properties - so if you want to use
system properties as your way of configuration, that can be done in standalone.xml as
well.
Anyway, those are my thoughts. If they can't be done with metrics, or inventory, or
whatever, then so be it. But I take those points above from experience with the RHQ's
configuration.
----- Original Message -----
I am not for or against using properties for config simply because I
do not
yet know what the requirements for the configuration will end up being.
On the other hand I feel we should from the start use something that is
capable of handling more structured configuration formats without us needing
to rewrite all the configuration handling code if that need arose (by
abandoning java's Properties and moving to something different).
Hence I propose using Apache Commons Configuration for reading the
configuration files. I think Artificer uses it, too, so Brett et al. can
comment if that would be the right thing to do or not.
Commons configuration supports XPATH for accessing nested data so working
with
hierarchical properties should be quite nice with it. The disadvantage is
that
it drags several other deps with it -
http://commons.apache.org/proper/commons-configuration/dependencies_1_10.....
Other option could be to commit to a single configuration format and use a
dedicated parser for that with minimal deps. For example if we chose JSON as
the config format we could use JBoss DMR for reading/writing such configs.
The
advantage of that approach is that DMR is absolutely tiny with no external
deps. The disadvantage is that JSON cannot have comments (which is easily
amended by a custom reader that would strip the comments before the contents
are passed to DMR for parsing (a recommended approach from the author of JSON
- https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr)).
On Thursday, February 05, 2015 11:01:53 Thomas Segismont wrote:
> Hi everyone,
>
> Yesterday Lukas asked on IRC if there was a discussion about
> configuration. AFAIK, there wasn't, hence I'm sharing how we support
> configuration in metrics.
>
> # Metrics REST server
>
> The REST server runs on top of Wildfly.
>
> Configuration is a set of key/value pairs (configuration properties)
> defined by the following sources, in order of precedence:
>
> * system properties (-Dkey=value)
> * external java.util.Properties file, which path is defined by the
> metrics.conf system property; by default, <user.home>/.metrics.conf is
> used (if it exists)
> * internal java.util.Properties file (META-INF/metrics.conf)
>
> The rationale behind is that the system should be able to:
>
> 1. start with reasonable defaults
> 2. switch to another configuration easily
>
> # pTrans
>
> pTrans is different because it's a standalone application, so it's much
> easier to follow the daemon configuration habits.
>
> pTrans takes a path to a properties configuration file as a program
> argument. This argument is mandatory.
>
> # Configuration file format.
>
> metrics started with properties file and I think it's fine.
>
> But if we feel the need for a more structured format, we should pick
> something which can be easily parsed by a variety of programming
> languages, especially languages widely used for administration (Python
> and Ruby).
>
>
> Regards,
> Thomas
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
8:58 a.m.
Le 05/02/2015 15:09, John Mazzitelli a écrit :
I have a few points:
1) pick one way to configure, not N ways. I've since learned that while it is nice
that the agent has so many ways to configure itself (-D cmd line, agent-configuration.xml,
setconfig prompt, -c <file> command line option, config <file> option, etc.)
its a pain to keep track of it all and making sure all of it works and never breaks along
the line.
Not N, 2 ways :)
I had in mind that the configuration file was the "main" way. I'd be
fine with removing the system property override mechanism.
2) If at all possible, have a single configuration point (a single .xml file for
example), not multiple files and certainly not multiple files in multiple different
directories.
Agreed. That's what metrics does. When we'll have alerts and a bunch of
notifiers in the same nest then multiple files might be inevitable.
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.
4) Keep in mind installation use-cases - don't make configuration so hard that we
have to write a convoluted installer to get things to run.
Yes. Storing configuration in a file and then pointing to this file with
a command line parameter or a system property is the best way to make it
easy to automate installation with a config management tool.
Note that standalone.xml has a section for just system properties - so if you want to use
system properties as your way of configuration, that can be done in standalone.xml as
well.
Anyway, those are my thoughts. If they can't be done with metrics, or inventory, or
whatever, then so be it. But I take those points above from experience with the RHQ's
configuration.
----- Original Message -----
> I am not for or against using properties for config simply because I do not
> yet know what the requirements for the configuration will end up being.
>
> On the other hand I feel we should from the start use something that is
> capable of handling more structured configuration formats without us needing
> to rewrite all the configuration handling code if that need arose (by
> abandoning java's Properties and moving to something different).
>
> Hence I propose using Apache Commons Configuration for reading the
> configuration files. I think Artificer uses it, too, so Brett et al. can
> comment if that would be the right thing to do or not.
>
> Commons configuration supports XPATH for accessing nested data so working
> with
> hierarchical properties should be quite nice with it. The disadvantage is
> that
> it drags several other deps with it -
> http://commons.apache.org/proper/commons-configuration/dependencies_1_10.....
>
> Other option could be to commit to a single configuration format and use a
> dedicated parser for that with minimal deps. For example if we chose JSON as
> the config format we could use JBoss DMR for reading/writing such configs.
> The
> advantage of that approach is that DMR is absolutely tiny with no external
> deps. The disadvantage is that JSON cannot have comments (which is easily
> amended by a custom reader that would strip the comments before the contents
> are passed to DMR for parsing (a recommended approach from the author of JSON
> - https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr)).
>
> On Thursday, February 05, 2015 11:01:53 Thomas Segismont wrote:
>> Hi everyone,
>>
>> Yesterday Lukas asked on IRC if there was a discussion about
>> configuration. AFAIK, there wasn't, hence I'm sharing how we support
>> configuration in metrics.
>>
>> # Metrics REST server
>>
>> The REST server runs on top of Wildfly.
>>
>> Configuration is a set of key/value pairs (configuration properties)
>> defined by the following sources, in order of precedence:
>>
>> * system properties (-Dkey=value)
>> * external java.util.Properties file, which path is defined by the
>> metrics.conf system property; by default, <user.home>/.metrics.conf is
>> used (if it exists)
>> * internal java.util.Properties file (META-INF/metrics.conf)
>>
>> The rationale behind is that the system should be able to:
>>
>> 1. start with reasonable defaults
>> 2. switch to another configuration easily
>>
>> # pTrans
>>
>> pTrans is different because it's a standalone application, so it's much
>> easier to follow the daemon configuration habits.
>>
>> pTrans takes a path to a properties configuration file as a program
>> argument. This argument is mandatory.
>>
>> # Configuration file format.
>>
>> metrics started with properties file and I think it's fine.
>>
>> But if we feel the need for a more structured format, we should pick
>> something which can be easily parsed by a variety of programming
>> languages, especially languages widely used for administration (Python
>> and Ruby).
>>
>>
>> Regards,
>> Thomas
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
9:25 a.m.
> 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.
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
12:32 p.m.
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
4:14 a.m.
Am 05.02.2015 um 19:32 schrieb Jay Shaughnessy
<jshaughn(a)redhat.com>:
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.
Right said Fred
7 a.m.
Le 06/02/2015 11:14, Heiko W.Rupp a écrit :
> Am 05.02.2015 um 19:32 schrieb Jay Shaughnessy <jshaughn(a)redhat.com>:
> 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.
Right said Fred
OK. Then how should we provide configuration to a deployment then? There
are two ways I'm aware of:
- System properties defined in standalone.xml
Configuration properties can be read with System.getProperty
- JNDI entries
Configuration properties can be read with @Resource or a programmatic
lookup.
Any other option?
2:05 a.m.
If the main hawkular deliverable is an integrated solution that builds on wildfly, then
the priorities are clear and the configuration question is already answered.
It doesn’t matter what configuration option you provide for the components themselves,
because once integrated the configuration becomes subject of the target environment.
Whatever mechanism you chose, it’s very likely going to be replaced by the mechanism the
target environment uses.
Therefore I would suggest the following:
a) every component provides configuration builder interface (java, programmatically)
b) the main configuration use the default wildfly mechanism
a) allows the community to build custom adapters if needed. b) interfaces with a) and
covers the main hawkular use cases.
/HeikoB
2:45 a.m.
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
2:54 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/06/2015 09:45 AM, Thomas Segismont wrote:
I have the feeling that inserting our configuration in the Wildfly
config file will make building assemblies and setting up
integration tests more difficult.
Not sure about tests, but surely not making assemblies :-) Keycloak
uses something similar, with XSLT:
https://github.com/keycloak/keycloak/blob/master/distribution/appliance-d...
https://github.com/keycloak/keycloak/blob/master/distribution/appliance-d...
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJU1IFJAAoJECKM1e+fkPrXp4cH/iMBKi5bXY4sAQF6hM3+nYoH
hhTvchwAHCtiAznRidYDdugOempD+d69xuEjEWJEM4Q2g4+F62Aqk/efJPJ/3mq9
6O4lCHsPwZKlEsCTjvJI7aNw7EIy6qQ+o5K7pTv3X3OQZwF1GIFhryVBSuqrMLZ3
qV70BYuK5cc08rUMQmOg7+MAiFnUxLFIk63D3QC4jXPOF7mpTGIOnm8qamu+WhGQ
+Uo0tZXIS4DVaHQWeS1mVqCK1w1XKq4+oEve43pVgjxBl8Zr5AiQNmOeruDnb576
zoSciyB6TyKEzBRcZ/ECP+Myrqf0tcFeFFYvGtrlgoRbynPOfdcIm69ESngTAxs=
=RtXM
-----END PGP SIGNATURE-----
3:43 a.m.
Le 06/02/2015 09:54, Juraci Paixão Kröhling a écrit :
On 02/06/2015 09:45 AM, Thomas Segismont wrote:
> >I have the feeling that inserting our configuration in the Wildfly
> > config file will make building assemblies and setting up
> >integration tests more difficult.
Not sure about tests, but surely not making assemblies:-) Keycloak
uses something similar, with XSLT:
https://github.com/keycloak/keycloak/blob/master/distribution/appliance-d...
https://github.com/keycloak/keycloak/blob/master/distribution/appliance-d...
Indeed, they use XSLT to declare the extensions (not configuration) in
the standalone.xml file.
And then in the assembly descriptor they add a keycloak-server.json file
to the configuration directory:
https://github.com/keycloak/keycloak/blob/master/distribution/appliance-d...
The keycloak-server.json file is where you actually configure KC. But I
guess you know that :)
4:16 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/06/2015 10:43 AM, Thomas Segismont wrote:
And then in the assembly descriptor they add a keycloak-server.json
file to the configuration directory:
https://github.com/keycloak/keycloak/blob/master/distribution/appliance-d...
The keycloak-server.json file is where you actually configure KC.
But I guess you know that :)
Which they are actually thinking in dropping it, in favor of putting
everything on the standalone.xml .
http://lists.jboss.org/pipermail/keycloak-dev/2015-February/003622.html
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJU1JSOAAoJECKM1e+fkPrXqgEH/16w5o00vBQ5+L5WbcKXeVRE
QhiNlGTEVeGxJgK8O9xKuM4OhK4eQv+aeFb3Ikg5hdshsPNxBn3xZyosh4dLBjQ9
TZvsj2PDqFpb+3Afkfk2wK/ukE1cDXd34QvXxrSVT/9pmQ9i8mUYdbwjRoHXHRVy
3GOyDorh8yIGAmbYOh5WVBspRljOrc1KyWHfrDyMDK0hrfObS8eZHbl24MwAptPt
64OYRSOIAGvig2VM9sJauQiVJdt5nRdRjAS45oScOnITjQDrSsvcnxbhLVTbU3dI
tAQRhWyebS4Wd0H6nNLirWAvDWhG+s2Wp8tomo+XJWTJnlkeHwCeG5M0I63S7xY=
=+VIo
-----END PGP SIGNATURE-----
4:16 a.m.
Am 06.02.2015 um 09:45 schrieb Thomas Segismont
<tsegismo(a)redhat.com>:
I have the feeling that inserting our configuration in the Wildfly
config file will make building assemblies and setting up integration
tests more difficult.
I do expect that we created hand-tailored versions of standalone.xml
And not fancy tooling like that RHQ installer.
4:13 a.m.
Am 05.02.2015 um 16:25 schrieb John Mazzitelli
<mazz(a)redhat.com>:
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.
I am absolutely with Mazz here.
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.
And still. Hawkular Metrics will still need a container (e.g. WildFly to run on), so for
now that standalone metrics will not
be a process.
And as Mazz said, the properties inside standalone.xml can be read like system properties
you pass in via -Dkey=val,
but just live in that central place and not scattered around.
Ptrans is different, agreed.
And in general: we should out of the box (as it was said) deliver settings that are good
most of the time.
The installer in RHQ, that is firing a AS7, then modifying its port settings, then
rebooting it and using the new
settings should have taught us something...
8:22 a.m.
I believe the way we read/use config can be decided at the sub-project
level (provided we don't use an exotic format).
Le 05/02/2015 11:41, Lukas Krejci a écrit :
I am not for or against using properties for config simply because I
do not
yet know what the requirements for the configuration will end up being.
On the other hand I feel we should from the start use something that is
capable of handling more structured configuration formats without us needing
to rewrite all the configuration handling code if that need arose (by
abandoning java's Properties and moving to something different).
Hence I propose using Apache Commons Configuration for reading the
configuration files. I think Artificer uses it, too, so Brett et al. can
comment if that would be the right thing to do or not.
Commons configuration supports XPATH for accessing nested data so working with
hierarchical properties should be quite nice with it. The disadvantage is that
it drags several other deps with it -
http://commons.apache.org/proper/commons-configuration/dependencies_1_10.....
Other option could be to commit to a single configuration format and use a
dedicated parser for that with minimal deps. For example if we chose JSON as
the config format we could use JBoss DMR for reading/writing such configs. The
advantage of that approach is that DMR is absolutely tiny with no external
deps. The disadvantage is that JSON cannot have comments (which is easily
amended by a custom reader that would strip the comments before the contents
are passed to DMR for parsing (a recommended approach from the author of JSON
- https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr)).
On Thursday, February 05, 2015 11:01:53 Thomas Segismont wrote:
> Hi everyone,
>
> Yesterday Lukas asked on IRC if there was a discussion about
> configuration. AFAIK, there wasn't, hence I'm sharing how we support
> configuration in metrics.
>
> # Metrics REST server
>
> The REST server runs on top of Wildfly.
>
> Configuration is a set of key/value pairs (configuration properties)
> defined by the following sources, in order of precedence:
>
> * system properties (-Dkey=value)
> * external java.util.Properties file, which path is defined by the
> metrics.conf system property; by default, <user.home>/.metrics.conf is
> used (if it exists)
> * internal java.util.Properties file (META-INF/metrics.conf)
>
> The rationale behind is that the system should be able to:
>
> 1. start with reasonable defaults
> 2. switch to another configuration easily
>
> # pTrans
>
> pTrans is different because it's a standalone application, so it's much
> easier to follow the daemon configuration habits.
>
> pTrans takes a path to a properties configuration file as a program
> argument. This argument is mandatory.
>
> # Configuration file format.
>
> metrics started with properties file and I think it's fine.
>
> But if we feel the need for a more structured format, we should pick
> something which can be easily parsed by a variety of programming
> languages, especially languages widely used for administration (Python
> and Ruby).
>
>
> Regards,
> Thomas
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
3390
days inactive
3394
days old
17 comments
7 participants
participants (7)
-
Heiko Braun -
Heiko W.Rupp -
Jay Shaughnessy -
John Mazzitelli -
Juraci Paixão Kröhling -
Lukas Krejci -
Thomas Segismont