Join Percona’s Senior Technical Services Engineer, Adamo Tonete as he presents “MongoDB Index Types, How, When and Where Should They be Used?” on Wednesday, July 12, 2017 at 11:00 am PDT / 2:00 pm EDT (UTC-7).
Course Of The Month
10 days, 18 hours left to enrollBecome a Premium Member and unlock a new, free course in leading technologies each month.
Solved
Changes to the jivelive.jsp are not being reflected on Fastpath webchat service.
Posted on 2013-10-24
Hi,
I am attempting to modify my jivelive.jsp file in my OpenFire webchat directory so I can use a text link instead of an image for my webchat service on our website. However, no matter what changes I make to the file, it is not reflected on the server when I go to load the JSP file in a web browser. If I restart OpenFire, the file is replaced with an original copy. I had read a few things stating that the webchat.war file needs to be recompiled with these changes to the .jsp but I'm not sure if that's even possible. I have already attempted to extract the .war file, change the .jsp, and recreate the .war file which seems to load just fine in OpenFire, but the jivelive.jsp still shows as the original when I browse to it in a browser. Any help is appreciated.
Thank you
I am attempting to modify my jivelive.jsp file in my OpenFire webchat directory so I can use a text link instead of an image for my webchat service on our website. However, no matter what changes I make to the file, it is not reflected on the server when I go to load the JSP file in a web browser. If I restart OpenFire, the file is replaced with an original copy. I had read a few things stating that the webchat.war file needs to be recompiled with these changes to the .jsp but I'm not sure if that's even possible. I have already attempted to extract the .war file, change the .jsp, and recreate the .war file which seems to load just fine in OpenFire, but the jivelive.jsp still shows as the original when I browse to it in a browser. Any help is appreciated.
Thank you
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
2
2-
2
- +1
7 Comments
Active today
I don't have experience with OpenFire (only with Tomcat) but I am guessing that it too would have some sort of "temp" or "work" directory like Tomcat. You may need to clear out any files in there too, as OpenFire might be caching the compiled version of your JSP and not updating that cache when you change the JSP. It is a bit of a guess going on the llimited info.
Active today
Apparently the new version of OpenFire uses Jetty. This was working perfectly fine under Tomcat before the update
It is likely that your tomcat instance automatically recompiled jsp files on any change to the file, and your jetty instance does not.
The most likely reason you're not seeing the changes is that the .java/.class files generated from the .jsp file are not being regenerated and reloaded by jetty. You also could be editing the wrong .jsp file, but let's assume that you have found the right .jsp file to edit.
So -- you can go into the working directory of the jetty instance and remove the .class and .java files for your changed .jsp, and that should force jetty to recompile and reload.
If jetty does not automatically reload changed class files (we don't know what your settings are), then you might have to stop and start jetty after you force the regenerate and recompile of the .java and .class files.
There is probably a flag in the jetty configuration which you can set so that it will do this automatically on file change, just the way tomcat does. You could look for that.
Warning: since the .jsp file is in a war, the next time you update the war (or re-expand it from the original .war file) your jsp changes will go away.
In order for the war to have your changes, you have to replace the .jsp/.java/.class files in the war itself.
If you are getting a 3rd party war, then you'll need to make this change every time you get a new version of the 3rd party war.
The most likely reason you're not seeing the changes is that the .java/.class files generated from the .jsp file are not being regenerated and reloaded by jetty. You also could be editing the wrong .jsp file, but let's assume that you have found the right .jsp file to edit.
So -- you can go into the working directory of the jetty instance and remove the .class and .java files for your changed .jsp, and that should force jetty to recompile and reload.
If jetty does not automatically reload changed class files (we don't know what your settings are), then you might have to stop and start jetty after you force the regenerate and recompile of the .java and .class files.
There is probably a flag in the jetty configuration which you can set so that it will do this automatically on file change, just the way tomcat does. You could look for that.
Warning: since the .jsp file is in a war, the next time you update the war (or re-expand it from the original .war file) your jsp changes will go away.
In order for the war to have your changes, you have to replace the .jsp/.java/.class files in the war itself.
If you are getting a 3rd party war, then you'll need to make this change every time you get a new version of the 3rd party war.
Active today
Hi,
I've tried to rebuild the entire war file and redeploy it with the changed files and I'm not finding any .class or .java files in the WAR file or in the directory. When I browse to the open fire plugins /webchat directory, the jivelive.jsp file has the modifications I have made to the jivelive.jsp in the .war file, but even when I reboot the server I am not seeing the changes reflected when I browse to that file in a web browser. I've done a system-wide search and that is the only jivelive.jsp file on the system and there are no .class or .java files. Any other ideas on this? Not sure what's going on.
I've tried to rebuild the entire war file and redeploy it with the changed files and I'm not finding any .class or .java files in the WAR file or in the directory. When I browse to the open fire plugins /webchat directory, the jivelive.jsp file has the modifications I have made to the jivelive.jsp in the .war file, but even when I reboot the server I am not seeing the changes reflected when I browse to that file in a web browser. I've done a system-wide search and that is the only jivelive.jsp file on the system and there are no .class or .java files. Any other ideas on this? Not sure what's going on.
The way servlet engines work is that the .jsp files are converted to .java files and compiled. The produced .class file is loaded by the classloader into memory. This can be done without writing anything to disk, which is possibly what jetty is doing. You might find it educational to check tomcat's \work\Catalina\yourdomainh
Unfortunately, amit_n_panchal was completely wrong that your solution was to rebuild and redeploy the .war file. The solution can be incorporated into rebuilding and redeploying the war file, but until you solve the problem, rebuilding and redeploying will not change anything.
You need to look for the jetty configuration (I've mentioned this above) to see what this configuration is doing. Set the flag that saves .java and .class files to disk -- that will help you debug the problem.
You will probably need to read the jetty documentation for all of this. But you can start by looking for the webdefault.xml for your app. Plus the webdefault.xml for your war, which you'll need to overwrite or make sure that it is not used. Since the war is not your code, that might be difficult.
I need to warn you again that you are choosing to edit a 3rd party war file, which means that every time you deploy it or get an update to it, you'll have to modify it, make sure that the changes are recompiled, and deploy it. Most people don't do this because of the maintenance headaches. And of course the configuration headaches you're seeing here.
Jetty's jsp compiler changed in version 2.2 to use the jvm's compiler, which does not write out the classes unless you explicitly set the init-param "saveBytecode" for the jsp servlet.
Make sure when you're adding that init-param to the jsp servlet that if you edit $JETTY_HOME/etc/webdefault
By the way -- are you fully stopping and starting the jetty instance? The classloader might hold your changed jsp's class in memory even if you have changed the jsp file and regenerated the class file. Redeploy can be done such that only a single webapp is reloaded, which might not be enough to get the old compiled jsp out of your web server's stack. It should be, but jetty is its own little world, so they might have decided to handle the behavior differently.
Unfortunately, amit_n_panchal was completely wrong that your solution was to rebuild and redeploy the .war file. The solution can be incorporated into rebuilding and redeploying the war file, but until you solve the problem, rebuilding and redeploying will not change anything.
You need to look for the jetty configuration (I've mentioned this above) to see what this configuration is doing. Set the flag that saves .java and .class files to disk -- that will help you debug the problem.
You will probably need to read the jetty documentation for all of this. But you can start by looking for the webdefault.xml for your app. Plus the webdefault.xml for your war, which you'll need to overwrite or make sure that it is not used. Since the war is not your code, that might be difficult.
I need to warn you again that you are choosing to edit a 3rd party war file, which means that every time you deploy it or get an update to it, you'll have to modify it, make sure that the changes are recompiled, and deploy it. Most people don't do this because of the maintenance headaches. And of course the configuration headaches you're seeing here.
Jetty's jsp compiler changed in version 2.2 to use the jvm's compiler, which does not write out the classes unless you explicitly set the init-param "saveBytecode" for the jsp servlet.
Make sure when you're adding that init-param to the jsp servlet that if you edit $JETTY_HOME/etc/webdefault
By the way -- are you fully stopping and starting the jetty instance? The classloader might hold your changed jsp's class in memory even if you have changed the jsp file and regenerated the class file. Redeploy can be done such that only a single webapp is reloaded, which might not be enough to get the old compiled jsp out of your web server's stack. It should be, but jetty is its own little world, so they might have decided to handle the behavior differently.
Featured Post
We value your feedback.
Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
I. Introduction
There's an interesting discussion going on now in an Experts Exchange Group — Attachments with no extension (http://www.experts-exchange.com/discussions/210281/Attachments-with-no-extension.html). This reminded me of questions tha…
In this post we will learn different types of Android Layout and some basics of an Android App.
Viewers will learn about the different types of variables in Java and how to declare them.
Decide the type of variable desired:
Put the keyword corresponding to the type of variable in front of the variable name:
Use the equal sign to assign a v…
Get a first impression of how PRTG looks and learn how it works. This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.
- Linux
- Windows OS
- Networking
- Paessler
- Network Management
- Network Analysis, Network Operations
Suggested Courses
Earn Certification
HTML5 Specialist - Certification
Free withPremium
Course of the Month10 days, 18 hours left to enroll
628 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.