This week's book giveaway is in the Artificial Intelligence and Machine Learning forum.
We're giving away four copies of Machine Learning with R: Expert techniques for predictive modeling and have Brett Lantz on-line!
See this thread for details.
Win a copy of Machine Learning with R: Expert techniques for predictive modeling this week in the Artificial Intelligence and Machine Learning forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

Altering a properties file without redeployment

 
Ranch Hand
Posts: 223
1
jQuery Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,

Recently, I came across a question can we bring an changes properties to be effect without redeployment of the app ? That's too in Production server ! I tried to answer as restarting server as well but the answer was declined.  Do we've any turn around in like this situation ? Your ideas are welcome.

Thanks.
 
Saloon Keeper
Posts: 10675
228
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sure why not? Whenever a part of your application needs a property setting, you can reread the properties file. Or if that's too slow, you can add a command to your application to clear the cached properties.
 
Mohammed Sardar.
Ranch Hand
Posts: 223
1
jQuery Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan, I'm thinking after the application starts and being in running state in production environment. How can we bring the changes to the properties into effect ?
 
Saloon Keeper
Posts: 5811
146
Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What kind of properties are we talking about? If they're property bundles used for localization, then it depends on what framework you're using, if any - some allow reloading, others don't.

If they're just general settings that your code makes use of, you'll have to arrange for their new values to be picked up by the code that needs them.

You can use a Watchable to get notified whenever the file changes, and possibly an event bus to distribute the values to the code parts that need them. But it all depends on how the code uses the properties, so tell us more about that.
 
Saloon Keeper
Posts: 21137
134
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you have set up Tomcat in its default configuration and you deploy a WAR to TOMCAT_HOME/webapps, then Tomcat will automatically deploy that WAR, and as part of the default deployment mechanism, if your WAR is in fact a WAR file, it will "explode" (unzip) that WAR file and use the exploded resources to service requests for that webapp.

Special note: Before about version 8.03 (?) of Tomcat, once a WAR had been exploded, copying in a new WAR file would not replace the exploded WAR, so effectively the only way to get a new WAR file version to deploy would be to delete the exploded copy, after which Tomcat would explode the new WAR. In newer versions, replacing a WAR file will cause that WAR to be exploded in place of the previous exploded copy.

But let's ignore the WAR file right now and look at the exploded WAR. Can you replace application files in-place in Tomcat while a webapp is running? Absolutely! Tomcat periodically (every few seconds) will scan each deployed webapp, and if it detects changes, it will re-reploy that app using the new files.

Note that I said "re-deploy". It won't simply pick up new files, it will restart the webapp. That's partly for security (a great way to hack is to get into something while it's in the middle of being changed, so atomic changes are safer). It's also to ensure that the app maintains internal consistency and you don't, for example, dispatch to a servlet that has suddenly disappeared.

A hot deploy isn't quite the same thing as a cold deploy (such as from restarting Tomcat). Some static resources may not reflect the updates. In particular, PermGen (R.I.P.) objects tended to either be kept in stale form or simply orphaned, eventually eating up Tomcat's memory.

Also, in the case of resource and other configuration files, you might want to be careful. If those resources were digested into memory objects, changes to the resource file might not update/delete/replace those memory objects. So code accordingly.

Production note: A well-run shop should have some sort of process for managing production app updates. For non-critical updates, that would generally mean scheduling a fixed downtime window. For critical updates, restarting Tomcat doesn't take long if you must, although I'd hope that some senior people would have to approve it.

And for zero-downtime shops, you're probably best off running Tomcat clusters and cycling the updates into each cluster member one by one.
 
Mohammed Sardar.
Ranch Hand
Posts: 223
1
jQuery Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway]If you have set up Tomcat in its default configuration and you deploy a WAR to TOMCAT_HOME/webapps, then Tomcat will automatically deploy that WAR, and as part of the default deployment mechanism, if your WAR is in fact a WAR file, it will "explode" (unzip) that WAR file and use the exploded resources to service requests for that webapp.



Thanks Tim for explaining various options and it's really good learning to me. But I still have many doubts to explore these options to know more from technical perspective. I hope you will shed some light to my novice brain.

1. If you have set up Tomcat in its default configuration and you deploy a WAR to TOMCAT_HOME/webapps, then Tomcat will automatically deploy that WAR, and as part of the default deployment mechanism, if your WAR is in fact a WAR file, it will "explode" (unzip) that WAR file and use the exploded resources to service requests for that webapp.

Does all the wep servers explode the war file to know all the configuration stuff to execute the application ?. (IBM, WebSphere)

2. But let's ignore the WAR file right now and look at the exploded WAR. Can you replace application files in-place in Tomcat while a webapp is running? Absolutely! Tomcat periodically (every few seconds) will scan each deployed webapp, and if it detects changes, it will re-reploy that app using the new files.


So, Once the WAR is deployed how can we change the properties file which is with (.properties extension). Correct me if I'm wrong do you mean make correction and then deploy the file or through code can we make changes to the application.properties ? or by running any batches ? I don't get that point actually. What I've learned once we deployed the WAR that'it until and unless till we redeploy the same copy will run in the server. Also I'm thinking how can we make changes to the WAR file without opening the properties in any IDE ?

3. A well-run shop should have some sort of process for managing production app updates. For non-critical updates, that would generally mean scheduling a fixed downtime window. For critical updates, restarting Tomcat doesn't take long if you must, although I'd hope that some senior people would have to approve it.

I agree but this happens with own intention of Business to make this change. Yes, It was a hypothetical to me as well. '

4. And for zero-downtime shops, you're probably best off running Tomcat clusters and cycling the updates into each cluster member one by one.

I'm still a growing developer who starves for knowledge so I'm trying to understand the role of clusters in Webapp world from now on. Thanks for that.

Thanks.
 
Tim Holloway
Saloon Keeper
Posts: 21137
134
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Many webapp servers explode WARs, but I don't know the that the JEE spec defines or requires exploding. They just find it convenient. I don't know if WebSphere explodes WARs offhand. I think WebLogic and WildFly do.

For Tomcat specifically, all that's required is to replace the properties file in the exploded WAR directory. Tomcat will detect the change next time it scans, although since properties file doesn't contain code, you might not see a redeploy. As I said earlier, for data files such as property files, you'd probably have to know to re-read the properties file yourself in application code.

I should caution that hacking production webapps on the fly like this is very perilous. Manual changes to the app often don't get back-posted to the original app source and thus can get lost when the app is updated and a full redeployment is done. I say this from sad experience. The best use of hot changes to app files is for testing and debugging, not for production.

An exploded WAR is just a standard directory subtree that happens to have a WAR format (for example, WEB-INF directory and its children). You don't need an IDE to update files in it - a simple file copy will do.
 
Tim Moores
Saloon Keeper
Posts: 5811
146
Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would advise strongly against having the web app redeploy just to pick up property changes. Reread my previous post about options that do not require that, and consider whether those might be suited to your situation.
 
Tim Holloway
Saloon Keeper
Posts: 21137
134
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To expand on Tim Moores comment, there are 2 places you can keep properties files.

A) As a part of the webapp itself (WAR)

B) As external file(s)

It's also not uncommon to use a hybrid approach where the default property values are stored in the WAR, but override values are stored in files outside of the WAR (and outside the webapp server directories). In the Unix family of OS's, such external properties might typically be defined in the /etc directory.

In case B, no re-deployment is needed at all. This is the better approach. However, you do need a mechanism, as Tim says, to watch for changes in those properties and refresh the webapp's in-memory view of them if those external files change.

Further complicating things, often when I design a webapp like this, I define the location of the exernal property file(s)/directory as webapp environment variables (which are NOT the same thing as OS environment variables), and use JNDI to obtain it, which allows me to - among other things - make a WAR that works well regardless of whether the webapp server runs under Windows or under Linux/MacOS. But one thing at a time. Consider what we've said about external properties files first. Making their locations configurable instead of hard-coded can come later.
 
I knew I would regret that burrito. But this tiny ad has never caused regrets:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!