I have one application using embedded Camunda engine 7.16, deployed in Wildfly 15, and it works fine.
for some weird architectural reasons, I now need to be able to deploy the same application a second time, in a different environment in which I would like to disable Camunda, because it’s not used there (and the underlying DB doesn’t have the Camunda tables).
In Spring Boot, we can easily disable the starter through properties, but how can we achieve the same in Wildfly ? I have the processes.yml file in the resources/META-INF folder, but is there a way to ignore it a startup ?
Otherwise, I will probably look at some options from Is there a quick way to delete a file from a Jar / war without having to extract the jar and recreate it? , and based on a property at startup, I would try to delete the processes.xml in the war file in the container before it actually starts the application, but that’s hack-ish to say the least
Thanks
Related
I'm distributing a simple Java webapp as open source. The webapp needs to be configured before it can be run – a configuration file needs to be created, and the location of that configuration file needs to be made known to the webapp as a parameter in web.xml.
Now my question is how to best package and distribute the webapp in order to make it easy to install, and how to describe that installation process in the documentation. The options I can think of are:
Distribute the webapp as a WAR archive. Recommend that users deploy the WAR into their Tomcat/Jetty/whatever, then drop their configuration file into /webapps/myapp/WEB-INF, and modify /webapps/myapp/WEB-INF/web.xml accordingly
Distribute the webapp as source. Recommend that users should drop their configuration file into the /src/main/webapp/WEB-INF folder, then modify their /src/main/webapp/WEB-INF/web.xml accordingly, then build a WAR using Ant or Maven, and deploy that into their servlet container.
There are probably other options that I can't think of.
What setup is likely to be most convenient to users that need to install, configure and deploy the webapp?
Edit: I should add that the configuration file isn't just a few lines – it's a large file that contains a database schema and other stuff and is potentially generated using an external editor; so just providing good defaults isn't an option.
Externalize this configuration and maybe provide some default values. If you make a new version of your app, everybody will have to remember to back-up that configuration file, then redeploy and then copy back that file--> this is a nightmare.
There are many ways to put that configuration somewhere else. You can use Java Preferences for example.
I would say the WAR, although not requiring the configuration would likely be more convenient :)
What is it, loosely, that must be configured such that there isn't a sensible default value for everyone? URL string?
Providing an answer of my own, after more reading on the issue: JNDI seems to be the “official”, although somewhat heavyweight, way of solving this. With JNDI, a configuration option (like the location of the full config file I need) can be declared in the web.xml, and its actual value can be set in a per-webapp context.xml that lives in the /webapps directory of Tomcat (or the /contexts directory of Jetty). This setup has a bunch of advantages:
The big configuration file can live outside of the servlet container and webapp
The webapp can be updated without danger of losing the configuration
The distributed war doesn't need to be modified or rebuilt
Downside: It's sort of complicated, requires messing around with XML, and configuring JNDI on Tomcat works differently from Jetty (requiring twice as much documentation).
Maybe use a system property for the config file location. Can easily be passed on the command line as -Dorg.example.config.file=/foo/bar, in startup scripts or in Java code. I think I've seen some tools, e.g. logging frameworks, use system properties for similar things in webapps.
We package our application as a .war file, we advertise support for JBoss AS5 and instruct our clients to copy the .war into their JBoss 'deploy' directory, and start up their application server in order to deploy the .war.
We are introducing support for JBoss AS7, so our deployment instructions for AS7 will have to change to something like
-copy the application.war to $JBOSS_HOME/standalone/deployments
-touch $JBOSS_HOME/standalone/deployments/application.war.dodeploy
-start JBoss AS7
This deployent method seems awkward to me, and possibly fragile, as failure to successfully create the *.dodeploy file would cause the deploy to fail. Also JBoss startup problems may cause the deploy to fail, causing the *.dodeploy file to be renamed *.failed - so it would have to be renamed back to *.dodeploy before attempting to redeploy. We are thinking the process seems a little awkward for some of our clients, who may not be familiar with JBoss AS7.
Is there any way to automate this deployment process so that it is smoother for deployers who may not be comfortable with how things work with JBoss AS7? How are other people handling this type of situation? thanks for any suggestions.
There is a web interface that's fairly easy to use. You can access it after JBoss AS7 has been started by going to http://localhost:8080. There is a link on that page that takes you to the administration console.
You could also write scripts for deployments using the CLI interface. There is some information here https://docs.jboss.org/author/display/AS7/Management+Clients about how to use it.
Lastly you can always write your own Java client to deploy applications. I wrote a blog post a while back on how to write a custom deployment CLI interface.
If you're aware of the marker files then you might have made a conscious choice to disable the automatic deployment mode for the deployment folder, which ships enabled by default. Autodeploy is great for everything but exploded files, and removes the need to manually manage the marker files. With autodeploy enabled, you can use the "touch" command on the application itself, which will update the timstamp and trigger the application for deployment (or redeployment). So you can still script if need be, but focus on the file rather than the marker files.
Just for reference, there are five ways to deploy files, of which three will be common to the typical administration setup. These are the graphical Management Console, the Management Command Line Interface (CLI) and the deployment folder you mention. The other two are via an IDE (such as JBoss Developer Studio or Eclipse with JBoss Tools), and even via Maven.
For people that may not be comfortable with the scripting as you say, then you can't go past the Manage Deployments section in the Console GUI. The Console deployment does not move/copy the application to the deployment folder, so using both the Console and the Deployment folder can make for some effort in file management.
For bash-savvy users, the CLI is great, and is often recommended by the AS7 team as a preferred method of deploying and managing applications. The user guide section on the CLI is located here: https://docs.jboss.org/author/display/AS7/Admin+Guide#AdminGuide-RunningtheCLI.
An example of all deployment methods can be found on this YouTube video by one of the developers: "5 ways to deploy your application to JBoss AS 7". Hope that helps.
You only need .dodeploy for exploded deployments. If your deployment is a zipped war,ear,etc. then it will be picked up automatically.
Change your deployment mode from manual to auto which does this deployment automatically.
Steps :
1) Open your jboss configuration file : standalone.xml.
2) Look for deployment-scanner and add auto-deploy-zipped="true"
<deployment-scanner scan-interval="5000" relative-to="jboss.server.base.dir"
path="deployments" auto-deploy-zipped="true" auto-deploy-exploded="false"/>
3) Restart your Jboss.
Now it will automatically pick your zipped version of ear/war/jar/sar files for deployment.
You can still use your old scripts without using any markers.
This can be changed in the standalone.xml by changing the "auto-deploy" attributes on the deployment-scanner element in the standalone.xml configuration file.
More details can be found in the deployments folder README.
I am developing WebSphere 6.1 EAR app and I need to override configuration entries specified in META-INF/ibconfig directory. There reside extra configuration files, that describe various server objects - from JDBC to shared libraries and links. The problem is that these settings override those already defined at server.
Specifically, if I have an application already installed on server and Shared libraries and refs already created and install Enhanced EAR as update to that application, those from EAR will prevail and will purge previously created.
What I seek is some deployment options - for admin console or for wsadmin - that will allow to ignore these configuration entries without actually deleting them from EAR file.
Best, and thank you in advance.
We use a python (actually jython) deploy script where all our configuration is set. Most of the configuration is read from files which are also used by maven in the process of creating the ear, and so minimizing the risk of typo's
AdminApp.install(earFile,['-MapResRefToEJB',createResRefMap(),'-MapModulesToServers', createModuleMap(), '-MapRolesToUsers', createRoleMap()])
setAppClassLoading()
AdminConfig.save()
AdminControl.invoke(appServer,'startApplication',appName)
Have a look in the documentation for all options.
There is a deployment option that can be used to ignore the application bindings in your updated EAR file, such that the existing configuration in your installed EAR takes precedence. When updating your application using wsadmin, the option is update.ignore.new. If updating your application using the admin console, this option is available by selecting the "use existing bindings" option from the "Preparing for the application update" step during the update.
This should accomplish what it seems that you are looking for. For example, consider that you have a resource reference in your application named "jdbc/MyDataSource" that is mapped to jdbc/ProductionDataSource in your installed application, and you are updating this application with a version of the EAR file that maps this resource reference to jdbc/TestDataSource in the IBM config files. Using the update.ignore.new option, this resource reference will continue to remain mapped to jdbc/ProductionDataSource after you have completed your application update. (Note that the default deployment behavior in WAS is that, without using this option, the resource reference would map to jdbc/TestDataSource in your updated application unless you explicitly overrode it otherwise during the deployment process.)
I seem to have run into an issue in what I am trying to do. I have been writing an automation app that is supposed to run a new instance of our Spring MVC application (on a newly created cloud server instance). I thought that if I just made this automation app unzip my .war after downloading it and then change the info in the spring.properties to match my datbase settings, etc then it should work fine. However, this seems to be causing some major problem as the app won't load using Tomcat after I do do this (gives errors about register JDBC and just hangs). It works fine if I put in the spring.properties settings I want before building the .war and then just run the .war normally within Tomcat.
I'm hoping someone could shed some light on why this issue may be occurring and / or what I can do so that I can dynamically set the properties in spring.properties before running a .war file without having to build the .war with new settings (as this would add more hassle to everything).
Option 1: Use context:property-placeholder and override values using System Property at run-time.
Option 2: Read run-time properties from a file external to the war
6 Tips for Managing Property Files with Spring
So, perhaps this is not the correct answer, but if you're trying to externalize your datasource, then you should use JNDI with Tomcat. It's much cleaner. You just use the jee namespace with spring then to lookup your datasource. This way the server admins can setup the datasource within server.xml :)
I'm about to use MySQL with Hibernate on a Tomcat 5.5.x server.
Do I have to put mysql-connector-java-[version]-bin.jar in $CATALINA_HOME/common/lib/ or could I place it in WEB-INF/lib inside my WAR file with my other library dependencies?
It would be easier to have it in my WAR in WEB-INF/lib, as I could get it using the Maven repository that way. Are there any big draw backs to having it there instead of in the common libraries directory of Tomcat?
If your jar is in common then it's loaded globally in tomcat. Every webapp sees it. If you put it in your webapp only your webapp sees it. What I assume Boris is referring to is if some part of your global tomcat config loads something that needs a mysql connection (like a connection pool) then it's going to need the jdbc driver, so it'll need it in common. Otherwise, no.
I believe there's a security configuration you can set up in the tomcat config that stores its config in a db. If you use this, it'll need a driver.
Why would you want stuff in webapp/WEB-INF/lib? well, because it's modular, it's part of your webapp, if you move your webapp somewhere else it doesn't need an extra part of it that's part of your tomcat installation. Maintenance is much easier if you can drop your webapp directly in a stock tomcat installation. Another reason- if you have multiple webapps, they're all going to use the jars in common, which could cause library conflicts and version issues.
In general, put as little in common as you can get away with. Even if you only have a single app.