[Hawkular-dev] Installer

[Thomas Heute]

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 at 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 at redhat.com <mailto:jpkroehling at 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 at redhat.com <mailto:theute at redhat.com>
> >      >>> <mailto:theute at redhat.com <mailto:theute at 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 at redhat.com <mailto:jpkroehling at redhat.com>
> >     <mailto:jpkroehling at redhat.com <mailto:jpkroehling at 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 at lists.jboss.org
> >     <mailto:hawkular-dev at lists.jboss.org>
> >     <mailto:hawkular-dev at lists.jboss.org
> >     <mailto:hawkular-dev at lists.jboss.org>>
> >      >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >      >>>
> >      >>>
> >      >>>
> >      >>>
> >      >>>      _______________________________________________
> >      >>>      hawkular-dev mailing list
> >      >>> hawkular-dev at lists.jboss.org
> >     <mailto:hawkular-dev at lists.jboss.org>
> >     <mailto:hawkular-dev at lists.jboss.org
> >     <mailto:hawkular-dev at lists.jboss.org>>
> >      >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >      >>>
> >      >>>
> >      >> _______________________________________________
> >      >> hawkular-dev mailing list
> >      >> hawkular-dev at lists.jboss.org <mailto:
> hawkular-dev at lists.jboss.org>
> >      >> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >      >>
> >      >
> >      > _______________________________________________
> >      > hawkular-dev mailing list
> >      > hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org
> >
> >      > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >      >
> >     _______________________________________________
> >     hawkular-dev mailing list
> >     hawkular-dev at lists.jboss.org <mailto: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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160203/6e949777/attachment.html