I am working on a Java project and have a problem with Wildfly 10's deployment. I don't find the solution in its documentation and would appreciate some help.
When I deploy a .WAR, Wildfly creates a temporary folder to store the exploded files:
./standalone/tmp/vfs/temp/tempb75b67d7adb84a3d/web.war-47f6d3d54946006d/
and as soon as I stop Wildfly with /etc/init.d/wildfly stop, all these temporary files are instantly deleted from the disk.
Problem:
The WAR contains default .properties files which have to be modified/configured by the administrator. Since the files are deleted with every deployment, this is not currently possible.
Questions:
Is there a way to have Wildfly deploys the .WAR to a permanent folder (similar to Apache Tomcat) ?
Is it a good J2E practice to do so considering the client wants to deploy this .WAR to a Debian Cloud infrastructure, but also occasionally to Windows Server?
What alternatives should we consider to store the .properties values?
WildFly does support unzipped (exploded) deployments. Have a look at $JBOSS_HOME/standalone/deployments/README.txt for details. Basically, you can just unzip your WAR to a subdirectory and add a marker file to have it deployed.
However, any configuration information that depends on the given host environment should not be placed in the WAR. A WAR is a compile-time artifact which should be regarded as immutable at run-time. (The fact that some web containers unzip the WAR and expose its internals is an implementation detail you should never rely on.)
Instead, you can define configuration data via system properties, environment variables, JNDI entries, whatever.
A very simple approach I often use with WildFly is the -P option:
cd $JBOSS_HOME/bin
./standalone.sh -P myconfig.properties
where myconfig.properties is a simple Java properties file. WildFly reads this file very early in its start-up phase and sets all properties as system properties.
Being system properties, these configuration items will be visible to all deployments, which shouldn't be a problem as long as you control what gets deployed to your server. To avoid conflicts between properties for different deployments, you can use deployment specific prefixes for your property keys, e.g.
app1.jdbc.url = jdbc:postgresql://localhost/app1
app2.jdbc.url = jdbc:postgresql://localhost/app2
Related
I would like to manage EAR deployed and exploded in the Wildfly application server on the fly, meaning to change its content (mainly JAR files as submodules) without need to reinstantiate or redeploy the whole package. (which takes time and during the time other modules are not available)
I was trying to do this through the Wildlfy CLI using the commands available for deployment, for example the following commands:
/deployment:myapp.ear:remove-content
/deployment:myapp.ear:add-content
These commands effectively remove or add content inside exploded application on Wildfly, however it seems to be not deployed without redeploying the whole application again.
Is there any way how to achieve it? Is it feasible?
I am assuming this all you are looking for in the context of testing your application and not for production kinds of instances.
If so, you can use WildFly standalone mode and a deployment scanner, which can be configured to keep scanning directories for any change and deploy it. Thanks!
I'm a .NET Programmer and right now I'm struggling with a web service I developed in JAVA. The web service doesn't have access to a database, only do some cryptographic tasks. To deploy it, I build the project with dependencies in Net Beans, generate a WAR File and upload it in the JBOSS web console.
The problem is that I'm looking for the analog of Web.Config in .Net, where some parameters can be set by a human without compiling again . In my code I call a XML file with all the parameters, however, the location of the file must be hardcoded. My solution was to set an enviornment variable with the folder so I always have to look for the XML there.
But I have an inconvenience: The same deploy will be set in two instances of JBOSS in the same server and both web services will have access to the same file, but that can't happen because some configurations are different in each one.
I tried the Web.xml file, but where can I find it in the JBOSS folder? Each time I upload the war or disable/enable it, it change the folder of the web.xml
What can you suggest?
The idea of using the web console is to work with artifacts (closed package) and you shouldn´t be manually modifying them.
From what i understood of your requirement, one option is to put an external file in the classpath of each jboss.
https://developer.jboss.org/wiki/HowToPutAnExternalFileInTheClasspath?_sscc=t
I recently tried to setup GIT continuous deployment for a Java WebApp (https://azure.microsoft.com/en-us/documentation/articles/web-sites-publish-source-control/).
I've uploaded my war archive into a separate branch on my GIT repository (see https://gist.github.com/koraktor/85964), setup the fetch keys and run it.
As you may see here - https://azure.microsoft.com/en-us/documentation/articles/web-sites-java-add-app/ all Java WebApps have a 'webapps' folder beneath 'wwwroot' folder.
Git continous deployment will copy all files under 'wwwroot' folder, hence, Java WebApps cannot be continuously deployed. The files need to be copied under 'webapps' folder.
Is there anything that I'm missing here? Or actually is not possible to continuously deploy a Java WebApp using Git?
Found a relatively simple solution - http://blogs.msdn.com/b/azureossds/archive/2015/12/11/use-custom-context-for-azure-tomcat-application.aspx
Deploy a custom Tomcat (don't forget the web.config) (see https://azure.microsoft.com/en-us/documentation/articles/web-sites-java-custom-upload/).
Modify your server.xml to point to wwwroot directory.
Modify any JAVA_OPTS if you want (OPTIONAL) (e.g In this web.config, you can specify your own JVM memory settings:
<environmentVariable name="JAVA_OPTS" value="-Djava.net.preferIPv4Stack=true -Dfile.encoding=UTF-8 -Xms512m -Xmx8192m -XX:MaxPermSize=256m" />
There is a small problem with this approach, when you want to create a deployment slot (see https://azure.microsoft.com/en-us/documentation/articles/web-sites-staged-publishing/) . That deployment slot is a brand new WebApp that only clones the settings not the files in the main WebApp (not the custom Tomcat that you just deployed). Hence, you will have to copy it over (which is a little bit error-prone).
Usually deployment slots, should be as similar to production slots as possible.
While development I need to frequently update my web app source code & deploy the updated war to a remote Tomcat server. Uploading a big war(25MB) takes too long(around 30 min) on my connection which is very unproductive. Is there any way I could reduce the war size ? There are a lot of external dependencies in my project. Could I deploy just the changes(may be dependencies remain intact) ?
It depends how much control you have over the upload process. If you have remote access to the filesystem, the following should work:
Upload the WAR
Let Tomcat expand it
Stop Tomcat
Delete the WAR
Start Tomcat
Tomcat should run your app from the expanded directory
Upload changed files only and replace the old ones in the expanded directory
For static files, no further action is necessary
If up update classes or JARs, you'll need to restart Tomcat
What you are asking (Could I deploy just the changes?) cannot be done. There are other things you can do though to reduce the file size of your war file:
You can place libraries in tomcat's common directory (tomcat-dir/common/lib) and remove them from your dependencies in your war file (Does Tomcat load the same library file into memory twice if they are in two web apps?).
Place static file on a cdn or another web application on your tomcat (that would require code modification though)
You can use git hooks (http://www.git-scm.com/book/en/v2/Customizing-Git-Git-Hooks). Altough, this requires a git repository on your webserver. Deployments may triggered by push events.
Actually, if exploded war deployment is an option for you then you could use kwatee. It's a free and unrestricted tool (I'm the author) with a simple web interface (or CLI automation) that can do incremental exploded war updates and many other things.
Currently, I have a web application, export it with eclipse in a war, copy it manually with scp on the server, run a script that extracts the war, uses local configuration files to overwrite the ones in the war, and copies the extracted folder in tomcat/webapps. This sounds easy for a server or two, but not for 100.
How can I improve this, in order to have better control of the versions/configurations installed and to deploy it more easily?
You could really benefit from using Cruise Control, or Hudson to do continuous builds for you. In there you can have the war-local configurations built into the war. You could build many flavors of these. Then, to deploy, it's just a matter of pushing the proper wars to their rightful place. No exploding, rewarring required.
See Deploy web application on multiple tomcat servers with Kwatee Agile Deployment. Once you have configured the deployment parameters with the web interface you could trigger from Ant using the kwatee task or from a continuous integration tool with the python CLI tools.
To help manage these multiple configurations, I have programmed a very lightweight library named xboxng here
It is flexible and pretty easy to use (no need for JNDI).
Store the specific configuration files of each server in a directory, put these under version control, and use something like Ant to take a "naked" war, unzip it, replace the files with the config files of the server you want to deploy to, and rebuild the war.
Then scp the war to the server directly. This can also be done using ant.
configs
- server1
- file1.properties
- file2.xml
- server2
- file1.properties
- file2.xml
ant -Dserver=server2 war deploy
As this is not a single answer question, depending on the project and, why not, personal taste, I will post some the steps I believe could help the whole process of management/deployment.
This does not mean that the solutions offered by the other posters are wrong (some of them received my upvote), but that this is what I found will work better for me.
1) In order to have only one version of war with multiple configurations, I used JNDI. I set up a env variable to the path where I could find the config. This was added to web.xml:
<env-entry>
<description>path to configuration files</description>
<env-entry-name>appName/pathToConfigFiles</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>/configFolder/appName/</env-entry-value>
</env-entry>
This has a default value, when the config files are taken from the war, but it can be overriden by context.xml.
<Environment name="appName/pathToConfigFiles"
type="java.lang.String" value="/etc/.."/>
This way if someone needs for example to change the database connection parameters I will not have to deploy a new war. The admin can change the file in the configuration folder.
The db config file and log4j file are my only external files. The rest of the configuration is done through the database.
Main advantage is that the same artifact can be deployed both in testing and production and on any of the 100 servers. I currently use it on Tomcat, but env variables should be available in other app servers.
2) Changed from an IDE build to a build-tool. I chose maven, but you can use ant/whatever.
For this I found useful the following sources:
"Maven by Example" book;
M2Eclipse plugin
For this I will also need to install Nexus as a mirror repository.
3) Install a continuous integration tool like Jenkins/Hudson. It is a wonderful tool, but because of its complex nature, it will take time to configure it and increment it's functionality. I am currently reading Jenkins: Definitive Guide, and I am trying to obtain the following functionalities:
Automated build server
Automated junit test server
Adding metrics
Automated test env deployment and Acceptance Testing
Continuous Deployment
Until this will be accomplished the wars will be deployed through bash scripts. I just scp the war to the server (no exploding/rewarring).