How to deploy expanded WAR using CLI?

[szhigunov]

I am porting an app to JBoss 7 and it requires to be deployed in expanded mode. CLI deploy command is the recommended way to deploy, but it only works with compressed file. Any ideas?

[kevinwu]

Modifying your configuration subsystem deployment-scanner and adding auto-deploy-exploded="true".  Or,  adding a marker file in deployment directory for each exploded war directory.  For example: if there is sample.war directory (web-app) under deployment directory, you have to have a sample.war.dodeploy marker file.

[szhigunov]

Thanks for replying. The options you described are valid but I am wandering is it possible to use JBoss CLI interface (not the directory scanner). JBoss docs do not recommend using scanner for production deployments.

[aloubyansky]

No, the deploy command expects a file, it'll complain if it's a directory. It open a file input stream and uploads the content to the deployment repository on the server. It could do some tricks like zip the directory and upload it to the server but at the end it would still be an archive.

I thought expanded deployments were also invented  for the development phase

[chrishiner]

If you get the war file onto the server outside of JBoss and unpack it, you can then do something like:

/deployment=filename.war:add(name="filename.war",runtime-name="filename.war",

content=[{"path"=>"/path/to/filename.war","archive"=>false}])

/server-group=somesrvgrp/deployment=filename.war:add(enabled=true)

I have several applications that I need to deploy expanded into production running in a domain, and that's what I've figured out so far.

[rhusar]

Chris, nice workaround. But whats preventing you from moving away from exploded archives to single file ones? Just wondering as I dont consider exploded archives a good fit for production environment.

[chrishiner]

We have a small number of applications that have one group responsible for the main code development and another group responsible for JSP content. 

The main application is only deployed once every four to six weeks but the content group deploys dozens of changes throughout the day.

Our current application server has the EAR deployed in expanded form, then our deployment system overlays the JSPs into it.  Then the app server notices the updated JSPs and recompiles them.

Ideally they'd rearchitect the app to pull all the content stuff out of a database or something, but that's what we have to work with now.

[szhigunov]

I am running standalone server so it is a little different.  I used the first command exactly as Chris suggested; for the second I used deploy. Everything seems to work including undeploy and redeploy. I still have concerns will this work in future JBoss versions.

/deployment=filename.war:add(name="filename.war",runtime-name="filename.war", content=[{"path"=>"/path/to/filename.war","archive"=>false}])

/deployment=filename.war:deploy

For the question why: the app I am porting to JBoss, reading resources (props, xmls ...) from the file system using absolute path. It gets it by

Class.forName("com.Clazz").getProtectionDomain().getCodeSource().getLocation(). In case of compressed deployment, that call returns you something like Jboss/bin/content/.. which is not a real path.

If the app used getResourceAsStream() there would be no issue.

[shonkylogic]

For EAP 6.2 standalone the 'name' attribute does not appear to be supported. So the CLI commands become:

/deployment=filename.war:add(runtime-name="filename.war", content=[{"path"=>"/path/to/filename.war","archive"=>false}])

/deployment=filename.war:deploy

In my case an exploded ear / war is required for Production due to an old version of Apache FOP requiring a real path to xsl files.