i still don't get why it needs to be so complicated

If we do:
        <subsystem xmlns="urn:org.hawkular.agent:agent:1.0" autoDiscoveryScanPeriodSecs="600" enabled="{hawkular.embedded-agent.enabled}">
            <diagnostics enabled="true" interval="1" reportTo="LOG" timeUnits="minutes"/>
            <storage-adapter password="${hawkular.embedded-agent.password}"" serverOutboundSocketBindingRef="hawkular" type="HAWKULAR" username="${hawkular.embedded-agent.username}"/>
 instead of putting the values directly (and we can even still default the values).

Then we just need to provide a file such as:
     hawkular.properties
with
     hawkular.embedded-agent.enabled=true
     hawkular.embedded-agent.username=jdoe
     hawkular.embedded-agent.password=password

and start with:
sh standalone.sh -P hawkular.properties

IMO it's much easier for a user to read/modify the property files for the things that are expected to be changed by the user rather than messing with standalone.xml (it's still an option for die-hard users).

What am I missing ?

Thomas.





On Mon, Feb 1, 2016 at 9:11 AM, Juraci Paixão Kröhling <jpkroehling@redhat.com> wrote:
I like this idea. Instead of a script, we could have a "first boot"
service that would perform this operation.

- Juca.

On 29.01.2016 22:25, John Doyle wrote:
> So how about a dedicated property file that contains the things the user
> needs to set for Hawkular, and then a script that takes the values for
> the property file and uses offline-cli commands to put the values into
> the standalone.xml? From then on they are manageable.  The user would
> not have reason to go back to the property file. It would essentially be
> one time use.
>
> ~jd
>
> On Fri, Jan 29, 2016 at 11:45 AM, Juraci Paixão Kröhling
> <jpkroehling@redhat.com <mailto:jpkroehling@redhat.com>> wrote:
>
>     Then it's still treated as "external" and cannot be managed by tools
>     that are Wildfly CLI-aware ?
>
>     - Juca.
>
>     On 29.01.2016 15:57, John Mazzitelli wrote:
>      > The file is NOT managed by WildFly, it can be whatever file you
>     want, read-only, read-write, doesn't matter. The way RHQ did it, we
>     shipped rhq-server.properties in a directory that was familiar with
>     customers so they knew where it was and could edit it easily.
>      >
>      > ----- Original Message -----
>      >> I did not know about this :) Do you know if the file is then
>     managed by
>      >> Wildfly, or is it read-only?
>      >>
>      >> - Juca.
>      >>
>      >> On 29.01.2016 15:39, John Doyle wrote:
>      >>> You can do this:
>      >>>
>      >>> $JBOSS_HOME/bin/standalone.sh
>     --properties=$JBOSS_HOME/my-jboss.properties
>      >>>
>      >>> Maybe I'm oversimplifying?
>      >>>
>      >>> On Fri, Jan 29, 2016 at 9:16 AM, Thomas Heute
>     <theute@redhat.com <mailto:theute@redhat.com>
>      >>> <mailto:theute@redhat.com <mailto:theute@redhat.com>>> wrote:
>      >>>
>      >>>      Yes, it's what I hoped for (but really have no idea if
>     that can work).
>      >>>
>      >>>      On Fri, Jan 29, 2016 at 3:06 PM, Juraci Paixão Kröhling
>      >>>      <jpkroehling@redhat.com <mailto:jpkroehling@redhat.com>
>     <mailto:jpkroehling@redhat.com <mailto:jpkroehling@redhat.com>>> wrote:
>      >>>
>      >>>          The advantage I see in managing the properties inside
>      >>>          standalone.xml is
>      >>>          that it can be managed via Wildfly CLI and compatible
>     tools.
>      >>>          Perhaps
>      >>>          even with future versions of Hawkular.
>      >>>
>      >>>          Unless there's a way to tell Wildfly to load the system
>      >>>          properties from
>      >>>          a separate file. This would be the best of two worlds.
>      >>>
>      >>>          - Juca.
>      >>>          _______________________________________________
>      >>>          hawkular-dev mailing list
>      >>> hawkular-dev@lists.jboss.org
>     <mailto:hawkular-dev@lists.jboss.org>
>     <mailto:hawkular-dev@lists.jboss.org
>     <mailto:hawkular-dev@lists.jboss.org>>
>      >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>      >>>
>      >>>
>      >>>
>      >>>
>      >>>      _______________________________________________
>      >>>      hawkular-dev mailing list
>      >>> hawkular-dev@lists.jboss.org
>     <mailto:hawkular-dev@lists.jboss.org>
>     <mailto:hawkular-dev@lists.jboss.org
>     <mailto:hawkular-dev@lists.jboss.org>>
>      >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>      >>>
>      >>>
>      >> _______________________________________________
>      >> hawkular-dev mailing list
>      >> hawkular-dev@lists.jboss.org <mailto:hawkular-dev@lists.jboss.org>
>      >> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>      >>
>      >
>      > _______________________________________________
>      > hawkular-dev mailing list
>      > hawkular-dev@lists.jboss.org <mailto:hawkular-dev@lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/hawkular-dev
>      >
>     _______________________________________________
>     hawkular-dev mailing list
>     hawkular-dev@lists.jboss.org <mailto:hawkular-dev@lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev