[ https://issues.redhat.com/browse/WFWIP-359?page=com.atlassian.jira.plugin... ] Kabir Khan commented on WFWIP-359: ---------------------------------- [~msvehla] This actually seems like a bug in patching: I have a vanilla (faked to be 7.3.4) server, which I start and then try to apply patches via the CLI: {code:java} [standalone@localhost:9990 /] patch apply ../xp-patching/jboss-eap-xp-1.0.0-patch.zip WFLYPAT0013: There is no layer called microprofile installed [standalone@localhost:9990 /] patch apply ../xp-patching/jboss-eap-xp-2.0.0-patch.zip WFLYPAT0013: There is no layer called microprofile installed {code} Next I run the setup command and enable the 2.0.0 patch stream, then in CLI I can apply the wrong patch as you did using the patch-apply command: {code:java} [standalone@localhost:9990 /] patch apply ../xp-patching/jboss-eap-xp-1.0.0-patch.zip { "outcome" : "success", "response-headers" : { "operation-requires-restart" : true, "process-state" : "restart-required" } } {code} The manager status command results in the same output you showed. I see it has created a $JBOSS_HOME/.installation/jboss-eap-xp-1.0.conf in addition to the $JBOSS_HOME/.installation/jboss-eap-xp-2.0.conf that was created by the manager setup command. These $JBOSS_HOME/.installation/<patch-stream-name>.conf files are part of the setup of each patch stream. So it seems that patching checks for the layer rather than the presence of the jboss-eap-xp-1.0.conf file. Now, I am not sure how to fix this as this seems to be a deeper issue in patching, for which I don't know the history. The issue is (ignoring the XP streams) that if you download EAP 7.3.0, the .installation/ directory is empty. Once you apply the first base patch you end up with a .installation/JBoss\ EAP.conf ("JBoss EAP" is the name of the main patch stream), as well as the .installation/layers/ and .installation/patches directories containing some more information. I deduce from this that: 1. The main check when applying the patches is the presence of the layers affected by the patch.zip 2. The .installation/<patch-stream-name>.conf is created on demand if not there I don't know how safe it is to update patching to change 2. to enforce the presence of the .installation/XXX.conf file as it could have unforeseen consequences for layered projects etc. CC [~aloubyansky] [~brian.stansberry]   I can try to inspect the patch in the patch-apply command to make sure it is valid for the patch stream. But that still does not stop users from running CLI to apply patches from the wrong XP stream.   -- This message was sent by Atlassian Jira (v7.13.8#713008)