]
Tomas Hofman commented on WFCORE-1579:
--------------------------------------
David's comment on related issue (WFCORE-1333):
{quote}
While I agree that the server should not crash in this case, validating the attribute is
the wrong answer.
Here are a few ways in which it could fail:
* The directory might be moved or deleted while the server is running
* The directory's permissions might be modified while the server is running
* The user might expect to be able to start the server and add the directory after the
fact
The reason this fails is that a transient condition is being checked for in the
configuration, but the configuration has no way to enforce the ongoing conformence to the
constraint.
The right answer is for the deployment scanner to dynamically be able to handle the
directory appearing and disappearing. The user should be allowed to set a non-existent
path component, which causes the deployment scanner to find no files until the path is
created. The relative-to component, however, should be validated as that is a model
integrity check.
{quote}
Perform check when changing 'path' attribute of
'deployment-scanner' instance
-----------------------------------------------------------------------------
Key: WFCORE-1579
URL:
https://issues.jboss.org/browse/WFCORE-1579
Project: WildFly Core
Issue Type: Bug
Components: Deployment Scanner
Affects Versions: 3.0.0.Alpha1
Reporter: Tomas Hofman
Assignee: Tomas Hofman
Priority: Minor
When creating my own deployment-scanner, I have to provide {{path}} attribute where given
value is checked whether it is a real directory on current filesystem. Although when I
change value of this attribute in existing deployment-scanner instance, such check is not
performed and I can provide non-existent directory. This leads to server crash after
calling reload operation:
# start EAP7 server and connect to CLI
# create your own deployment-scanner instance pointing to existing directory
{code}
[standalone@localhost:9990 /]
/subsystem=deployment-scanner/scanner=mysc:add(path=/home/jstourac/Downloads/jboss-eap-7.0/standalone/deployments)
{"outcome" => "success"}
{code}
# change path of deployment-scanner to some nonexisting directory
{code}
[standalone@localhost:9990 /]
/subsystem=deployment-scanner/scanner=mysc:write-attribute(name=path,value=/nonexistent)
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
{code}
# perform reload operation
# server fails with following output in console.log
{code}
15:29:08,039 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5)
WFLYDS0013: Started FileSystemDeploymentService for directory
/home/jstourac/Downloads/jboss-eap-7.0/standalone/deployments
15:29:29,068 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread
1-3) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
15:29:29,070 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0019:
Host default-host stopping
15:29:29,071 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5)
WFLYJCA0019: Stopped Driver service with driver-name = h2
15:29:29,073 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0008:
Undertow HTTP listener default suspending
15:29:29,075 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0007:
Undertow HTTP listener default stopped, was bound to 127.0.0.1:8080
15:29:29,076 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004:
Undertow 1.3.21.Final-redhat-1 stopping
15:29:29,081 INFO [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0002:
Unbound mail session [java:jboss/mail/Default]
15:29:29,082 INFO [org.jboss.as] (MSC service thread 1-8) WFLYSRV0050: JBoss EAP
7.0.0.GA (WildFly Core 2.1.2.Final-redhat-1) stopped in 16ms
15:29:29,083 INFO [org.jboss.as] (MSC service thread 1-8) WFLYSRV0049: JBoss EAP
7.0.0.GA (WildFly Core 2.1.2.Final-redhat-1) starting
15:29:29,135 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread
Pool -- 13) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "deployment-scanner"),
("scanner" => "mysc")
]): java.lang.IllegalArgumentException: WFLYDS0023: /nonexistent does not exist
at
org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.<init>(FileSystemDeploymentService.java:273)
at
org.jboss.as.server.deployment.scanner.DeploymentScannerAdd.execute(DeploymentScannerAdd.java:124)
at
org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
at
org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
at
org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
at
org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
15:29:29,139 ERROR [org.jboss.as.controller.management-operation] (Controller Boot
Thread) "WFLYCTL0193: Failed executing subsystem deployment-scanner boot
operations"
15:29:29,140 ERROR [org.jboss.as.controller.management-operation] (Controller Boot
Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address:
([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem
deployment-scanner boot operations\""
15:29:29,141 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server
boot has failed in an unrecoverable manner; exiting. See previous messages for details.
15:29:29,144 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been
requested.
15:29:29,159 INFO [org.jboss.as] (MSC service thread 1-8) WFLYSRV0050: JBoss EAP
7.0.0.GA (WildFly Core 2.1.2.Final-redhat-1) stopped in 4ms
{code}
# one has to manually modify {{EAP_HOME/standalone/configuration/standalone.xml}}
removing problematic deployment-scanner part to be able to start server again
It would be great if there is same check to {{path}} atribute performed when changing it
in existing instance of deployment-scanner as what is performed during the adding a new
instance of deployment-scanner.