Hi @bdwyertech, first of all thanks for your work on the Chef WildFly cookbook :smile: I was trying to use it with WildFly 10.0.0.Final, it installs well but doesn't run. I assume because of a change in the the standalone.xml files. What would be the recommended way to fix or workaround this?
For the time being, you can likely override the template from a wrapper cookbook
resources("template[#{::File.join(node['wildfly']['base'], 'standalone', 'configuration', node['wildfly']['sa']['conf'])}]").tap do |cfg|
cfg.source 'YOUR FILE'
cfg.cookbook 'YOUR COOKBOOK'
end
That's just a quick guess, a little bit more background on that type of thing here
@jeusdi Check out these attributes. You can put users in there with the correct format. https://github.com/bdwyertech/chef-wildfly/blob/master/attributes/users.rb#L23-L29
1. Resource Driven
- Allow for more customization of the installation itself, and allow for multiple instances.
2. Drop support for XML Templates
- It is tough to adjust those XML config templates (standalone, etc.) for each new version of WildFly that comes out. Use Java Properties or the JB-CLI to set/maintain configuration instead.
3. Configuration via WildFly Management API
- Shelling out to
jb-cliis terribly slow, Java has to load up for each command. The existing HTTP API is extremely fast -- The only gotcha is we need a user configured for authentication, and that this will require a gem dependency to handle the Digest authentication (Net::HTTP doesn't support it natively).
It looks like every time chef-client runs (every 30 minutes), it's updating standalone.conf, which triggers a service restart, even though nothing in standalone.conf (content, permissions, etc) is actually changing. Is there something I'm supposed to be doing that I've missed? Or something dumb I'm doing that I shouldn't? (wildfly 16.0.0-final on Centos 7)