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