--layers=messaging-activemq does not add any default configuration into standalone.xml (and other attempted workarounds)

[fschoning]

I am trying to switch from using the unzipped wildfly to a galleon based install in order to better manage version updates. However I am having a lot of difficulty in getting the galleon setup right. I use pretty much a standard standalone.xml and then have to add activemq for JMS message beans, and infinispan for my own cached beans. So far the experience has not proven easy.

1) When installing using just --layers, then adding messaging-activemq does not add any default configuration into standalone.xml. I have to pick through an old standalone-full.xml to find the relevant sections and add then use jboss-cli to add them. This does not seem to be the case for other layers, and also I am concerned that a small mistake could have unforeseen and unfindable production issues down the line. Is it intentional that adding a messaging-activemq layer does not also add a default configuration?

2) I can install using --default-configs=standalone/standalone.xml or --layers but not both! So this also does not give me a path to install a basic standalone server installation with JMS message beans out the box. Is it possible to install both a default standalone server (with all default configs) and then add a messaging-activemq on top, also with default configurations?

3) Now I am resorting to installing --default-configs=standalone/standalone-full.xml just to get the default configs, and then considering removing sections I don't need with jboss-cli. Surely there is a better way to do this?

4) I also looked at updating an existing --default-configs=standalone/standalone.xml afterwards by doing another galleon call using --layers, but the second call just does nothing with no error messages shown.

5) I see from the galleon command line help that there are some commands for "universe" updates, but nothing in the documentation anywhere about "universes" and so I don't know how to do this or even if it is a viable option.

Or am I just using this galleon tool wrong, or is galleon actually not the recommended way of doing this anymore?

[jfdenise]

@fschoning , thank-you for your report. In general the CLI tool is limited when doing more advanced provisioning. One approach is to define a provisioning.xml that you can then provision using the command:

provision <path to provisioning.xml file> --dir=<install dir>

A provisioning file example that provision the standalone.xml default config and adds on top the microprofile-platform (all microprofile subsystems) to it:

<?xml version="1.0" ?>

<installation xmlns="urn:jboss:galleon:provisioning:3.0">
    <feature-pack location="wildfly@maven(org.jboss.universe:community-universe):current#25.0.1.Final">
        <default-configs inherit="false">
            <include model="standalone" name="standalone.xml"/>
        </default-configs>
    </feature-pack>
    <config model="standalone" name="standalone.xml">
        <layers>
            <include name="microprofile-platform"/>
        </layers>
    </config>
</installation>

Answer to your points:

1. I suspect that you were expecting an embedded broker to be added to your configuration. We don't have such layer. The "messaging-activemq" layer only adds the extension and subsystem.
2. If you want both in one go, use the provisioning.xml file. Something to note is that you will not get the benefit of trimming the server modules if you mix a default configuration (that brings all JBoss Modules modules) and layers that only bring the set of JBoss Modules they require.
3. One better approach would be to extend standalone.xml configuration using the feature-group we are using in WildFly to build the standalone-full.xml. This will just bring the messaging subsystem with the default config (and update ee and ejb3 subsystems). The provisioning.xml looks like:

   
   <?xml version="1.0" ?>

4. That should work, although the provisioning.xml is really the way to go when mixing Galleon layers and default configs. The second call should target the same --dir installation. But in your case we don't have a layer that brings the embedded server.
5. If you could clarify? There is one command to update an installation: update --dir=[install dir], if a new version exists it will get installed. for example:

install wildfly#25.0.0.Final --dir=foo update --dir=foo

You will get 25.0.1.Final version.

[fschoning]

Thanks for the info and your prompt response. For points 1, 2, 3 & 4 I will try using the provisioning xml instead and see how it goes. But I am concerned that by using layers and not default configs, I don't know which default subsystem configurations that are usually in a standalone.xml will now be left out, i.e. if there are other config-less layers like the messaging-activemq layer. So I am wary of this approach now. Point 4 unfortunately doesn't work. Point 5: The documentation says one of the main features of galleon is to be able to add modules/capabilities/subsystems to a operational server without a reinstall. So by update, I mean add (or remove) a new subsystem, and not update the wildfly version. If I install using default configs, then there is no way that I can add an additional layer afterwards, thus rendering the whole feature useless. The main reason is to be able to update operational servers with existing data in the caches etc.

Another point please, is there a galleon layer for infinispan server? There is a comment from Wildfly 23 docs onwards: "Infinispan modules are deprecated and planned for removal. These modules provide a temporary solution until WildFly directly manages the infinispan subsystem." It is not really clear what this actaully means? In my current version of Wildfly 19, I have to add my own Infinispan server subsystem for my applications bean caches because it was not possible to use the internal infinispan. Does "These modules provide a temporary solution until WildFly directly manages the infinispan subsystem" mean that I don't need my own subsystem anymore and can use the internal subsystem. If this is the case I cannot find any documentation anywhere on how to configure my own caches.

Thanks again for your help.

[jfdenise]

@fschoning , FYI, wuth WF 27 Beta1, you can use the new embedded-activemq Galleon layer that will create an embedded borker similar to the standalone-full.xml one.