Enabling manual deployment

[gbrown1]

I'm currently profiling a Wildfly 17 instance to try to identify some application bottlenecks, and I'm seeing what appears to be some strange file system monitoring behavior. When the application server starts up, something appears to create an instance of WindowsWatchService that ends up consuming quite a bit of CPU time. I can't tell if this is impacting overall application performance or not, so I want to try to disable it.

I thought it might be caused by the deployment scanner, so I tried removing the deployment scanner subsystem from standalone.xml. This seems to resolve the problem, but it also prevents my app from deploying. I suspect that I need to enable manual deployment mode; however, I haven't been able to find any clear documentation on how to do this (I have seen a lot of docs that reference manual mode, but none with examples of how to actually do it).

Here is how I have currently configured the deployment scanner:

        <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0">

            <deployment-scanner path="deployments" relative-to="jboss.server.base.dir"

                scan-enabled="false" scan-interval="0"

                auto-deploy-zipped="false" auto-deploy-exploded="false"

                runtime-failure-causes-rollback="${jboss.deployment.scanner.rollback.on.failure:false}" />

        </subsystem>

In wildfly-17.0.0.Final\standalone\deployments, I have an exploded EAR folder (foo.ear) and a foo.ear.dodeploy file. However, when I start the server, my EAR is not deployed.

What am I doing wrong?

Thanks,

Greg

[zhurlik]

Hi,

What happens when you set auto-deploy-zipped = true

Thanks,

Vlad

[gbrown1]

Isn't that the default? If so, that also does not resolve the problem.

[zhurlik]

Are you dropping a zip file?

[gbrown1]

No, as I mentioned in my original post it is an exploded EAR (a folder).

[zhurlik]

I guess you need to use ear file instead of a folder, based on Admin Guide - JBoss AS 7.0 - Project Documentation Editor

auto-deploy-exploded

BOOLEAN

Controls whether exploded deployment content should be automatically deployed by the scanner without requiring the user to add a .dodeploy marker file. Setting this to 'true' is not recommended for anything but basic development scenarios, as there is no way to ensure that deployment will not occur in the middle of changes to the content.

[gbrown1]

I have auto-deploy-exploded set to false, and I have a .dodeploy marker file. Based on the documentation you posted (and I have already read), I would expect this configuration to work.

[zhurlik]

Hmm... I remember that once I had issues with deployment and it was related with .war and .dodeploy files and last modified dates, could you check them via ls -l

[jaikiran]

When you say manual deployment, do you mean you want to have the application deployed, through the standalone/deployments folder, once when teh server boots up? Or do you mean you want to use management APIs to trigger the deployment even when server is up and running.

FWIW, setting scan-enabled to false (like in the config you pasted) altogether disables looking for deployments in the directory configured for the scanner and that's what you are seeing in your tests.

[gbrown1]

Yes. I am basically looking for a way to hard-code the applications I want deployed, vs. having the deployment scanner try to figure it out dynamically.

[ctomc]

look at deploying your application via cli and "deploy" command.

just be careful with parameters it takes to deploy exploded archive.

[gbrown1]

OK. I was hoping I might be able to do it declaratively, in standalone.xml or something similar. Thanks for your help.

[ctomc]

the deploy command will result in some extra configuration being written to standalone.xml.

take notice the part with <deployment> tag(s)

Once you get hang of what are all the options and what result in xml is, you can do it declarative.