Bug 1151435
| Summary: | [GSS] (6.4.0) Behaviour of overlays with wildcards is inconsistent | |||
|---|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | Shaun Appleton <sappleto> | |
| Component: | CLI | Assignee: | Alexey Loubyansky <olubyans> | |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Petr Kremensky <pkremens> | |
| Severity: | high | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 6.3.1 | CC: | brian.stansberry, istudens, jmartisk, kkhan, lakagwu, sdouglas | |
| Target Milestone: | DR11 | |||
| Target Release: | EAP 6.4.0 | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| URL: | https://access.redhat.com/support/cases/01199478 | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | Bug Fix | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1154108 (view as bug list) | Environment: | ||
| Last Closed: | Type: | Bug | ||
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1154108 | |||
I have discussed this via internal irc with Alexey We came to the following conclusions - There are some differences between the two scenarios... The 2 apporaches are not equivalent The following one line approach is equivalent to the 3 line approach above [standalone@localhost:9999 /] deployment-overlay add --name=myoverlayC --content=/META-INF/persistence.xml=/home/sappleton/persistence.xml --deployments=jboss-kitchensink-ear-*.jar --redeploy-affected and as this applies to the jar and the .jar is not a deployment you have to force a deployment by using: [standalone@localhost:9999 /] /deployment=jboss-kitchensink-ear.ear:redeploy and this works fine. so the question is should [standalone@localhost:9999 /] deployment-overlay add --name=myoverlay4 --content=/jboss-kitchensink-ear-*.jar/META-INF/persistence.xml=/home/sappleton/persistence.xml --deployments=jboss-kitchensink-*.ear --redeploy-affected work? echo-dmr output:
[standalone@localhost:9999 /] echo-dmr deployment-overlay add --name=myoverlay6 --content=/jboss-kitchensink-ear-*.jar/META-INF/persistence.xml=/home/sappleton/persistence.xml --deployments=jboss-kitchensink-*.ear --redeploy-affected
{
"operation" => "composite",
"address" => [],
"steps" => [
{
"address" => [("deployment-overlay" => "myoverlay6")],
"operation" => "add"
},
{
"address" => [
("deployment-overlay" => "myoverlay6"),
("content" => "/jboss-kitchensink-ear-*.jar/META-INF/persistence.xml")
],
"operation" => "add",
"content" => {"bytes" => bytes {
0x3c, 0x3f, 0x78, 0x6d, 0x6c, 0x20, 0x76, 0x65,
...,
...,
...,
0x6e, 0x63, 0x65, 0x3e, 0x0a
}}
},
{
"address" => [
("deployment-overlay" => "myoverlay6"),
("deployment" => "jboss-kitchensink-*.ear")
],
"operation" => "add"
},
{
"address" => [("deployment" => "jboss-kitchensink-ear.ear")],
"operation" => "redeploy"
}
]
}
[standalone@localhost:9999 /]
I think this is a CLI issue. --redeploy-affected is a convenience method implemented in the CLI, and for this to work for subdeployments it should also look at sub deployment names when determining what to deploy (not just top level deployments). Alexey Loubyansky <alex> updated the status of jira WFLY-3999 to Resolved Verified on EAP 6.4.0.DR11. deployment-overlay add --name=myoverlay --content=/META-INF/persistence.xml=/tmp/persistence.xml --deployments=jboss-kitchensink-ear-*.jar --redeploy-affected the deployment overlay is used and the application is redeployed. |
Adding an overlay with wildcards in 3 steps as follows works: [standalone@localhost:9999 /] deployment-overlay add --name=myoverlay2 --content=/META-INF/persistence.xml=/home/sappleton/persistence.xml [standalone@localhost:9999 /] deployment-overlay link --name=myoverlay2 --deployments=jboss-kitchensink-ear-*.jar [standalone@localhost:9999 /] /deployment=jboss-kitchensink-ear.ear:redeploy Adding an overlay with wildcards as follows fails: [standalone@localhost:9999 /] deployment-overlay add --name=myoverlay4 --content=/jboss-kitchensink-ear-*.jar/META-INF/persistence.xml=/home/sappleton/persistence.xml --deployments=jboss-kitchensink-*.ear --redeploy-affected But the surprising thing is the content/ directory is updated with the correct file (copy of persistence.xml) and the standalone.xml file gets updated to refer to the correct file ie. <deployment-overlay name="myoverlay4"> <content path="/jboss-kitchensink-ear-*.jar/META-INF/persistence.xml" content="fe9d945e86732be60449eb2ce86d67c77293d730"/> <deployment name="jboss-kitchensink-*.ear"/> </deployment-overlay> But the expected change is never seen in the server.log This test was conducted using jboss-kitchensink-ear.ear from the eap quickstarts and modifying the show_sql within the persistence.xml Note that debug logging of org.hibernate was required to see the change (or not) in the server.log file So the one-line approach ingores the wildcard in jboss-kitchensink-ear-*.jar Whereas the 3 line approach doesn't.