[jboss-jira] [JBoss JIRA] (WFCORE-865) Patching regression between WFCore 2.0.0.Alpha9 and Alpha11
Alexey Loubyansky (JIRA)
issues at jboss.org
Wed Aug 5 05:01:07 EDT 2015
[ https://issues.jboss.org/browse/WFCORE-865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexey Loubyansky resolved WFCORE-865.
--------------------------------------
Resolution: Won't Fix
It's a consequence of https://issues.jboss.org/browse/WFCORE-830.
The patching module in the later version supports multiple patch streams, instead of assuming that every patch being applied comes from the same (identity) patch stream.
So, what happens here. Every patch stream has a name, for example: EAP, WildFly, BRMS, MyCustomLayer, etc. As specified in patch.xml, the patches attached to this issue target EAP (EAP patch stream).
The actual installation is not identified as the EAP though, it's WildFly (which is a different stream).
The patch is still accepted because there was no content conflict found and there is no notion of content boundaries between different patch streams, so the content coming from different patch streams may overlap (debatable but that was a conscious decision based on the time constraints).
So, now if you execute 'patch info --streams' you'll see WildFly and EAP streams displayed.
Every patching management operation now accepts (an optional) parameter/argument which identifies the target patch stream. So, if you added --patch-stream=EAP to patch info and history commands, you would see what you had expected.
In case --patch-stream argument is missing, the default patch stream is assumed as the target. The default patch stream is identified by values provided by org.jboss.as.version module, which in this case is WildFly.
So, the patches in this case targeted EAP but the info and history commands targeted WildFly which did not have any patch history.
> Patching regression between WFCore 2.0.0.Alpha9 and Alpha11
> -----------------------------------------------------------
>
> Key: WFCORE-865
> URL: https://issues.jboss.org/browse/WFCORE-865
> Project: WildFly Core
> Issue Type: Bug
> Components: Patching
> Affects Versions: 2.0.0.Alpha11
> Reporter: Ladislav Thon
> Assignee: Alexey Loubyansky
> Attachments: test-patch-10.0.0.Alpha5.zip, test-patch-10.0.0.Alpha6.zip
>
>
> With WildFly 10.0.0.Alpha5 (Core 2.0.0.Alpha9):
> {code}
> ./wildfly-10.0.0.Alpha5/bin/jboss-cli.sh --command="patch apply test-patch-10.0.0.Alpha5.zip"
> {
> "outcome" : "success",
> "result" : {}
> }
> ./wildfly-10.0.0.Alpha5/bin/jboss-cli.sh --command="patch history"
> {
> "outcome" : "success",
> "result" : [{
> "patch-id" : "test-patch",
> "type" : "cumulative",
> "applied-at" : "8/4/15 9:07 AM"
> }]
> }
> ./wildfly-10.0.0.Alpha5/bin/jboss-cli.sh --command="patch info"
> Version: undefined
> Cumulative patch ID: test-patch
> One-off patches: none
> {code}
> With WildFly 10.0.0.Alpha6 (Core 2.0.0.Alpha11):
> {code}
> ./wildfly-10.0.0.Alpha6/bin/jboss-cli.sh --command="patch apply test-patch-10.0.0.Alpha6.zip"
> {
> "outcome" : "success",
> "result" : {}
> }
> ./wildfly-10.0.0.Alpha6/bin/jboss-cli.sh --command="patch history"
> {
> "outcome" : "success",
> "result" : []
> }
> ./wildfly-10.0.0.Alpha6/bin/jboss-cli.sh --command="patch info"
> Version: undefined
> Cumulative patch ID: base
> One-off patches: none
> {code}
> With WildFly 10.0.0.Alpha6, based on {{patch history}} and {{patch info}}, it looks like the patch doesn't even apply, but that's not actually true, because trying to apply the patch once again results in
> {code}
> WFLYPAT0039: Requested WildFly version 10.0.0.Alpha6 did not match the installed version 10.0.0.Alpha6_PATCHED
> {code}
> So the patch in fact _is_ installed, it's just that neither {{patch history}} nor {{patch info}} doesn't show it like it used to.
> The only reason I could come up with is that I use {{EAP}} as the {{<upgrade name="...">}}:
> {code}
> <upgrade name="EAP" version="10.0.0.Alpha6" to-version="10.0.0.Alpha6_PATCHED"/>
> {code}
> However:
> 1. This used to work just fine in WildFly 10.0.0.Alpha5 and before.
> 2. If this is now considered wrong, the patch shouldn't even apply in the first place.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
More information about the jboss-jira
mailing list