I have a really annoying problem with a deployed Grails application on tomcat 7
I created a tool in my website that basically allows the site admin to edit message.properties files so that he can change the messages for a certain language as he desire.
All the changes are saved successfully to the file he edited.
In development, while running the website from STS (Soring Source Tools Suite; somethng like eclips) I just refresh the website in the browser and I see the changes instantly, all the changes that made to the message.properties file for the selected language is taking effect correctly.
But in the deployed application (same code same config no errors) the admin do the same thing, edit the resources in the same way as before, the message.properties file is saved with the new values correctly, but, I dont see the changes in the browser, unless I restarted tomcat, or after number of hours!
I've disabled the tomcat 7 caching, and I still face the same problem.
I've spent more than 4 days googling, but all the results are not related to my problem, and most of them are related to hibernate caching.
So, my question simply is as follows:
I want to go to a message.properties file in my deployed grails application, lets say message_en.properties, change lets say default.welcome.message=Welcome to default.welcome.message=Hello, World!
And then open any browser, and see Hello, World! instead of Welcome
Thanks in advance for any help =')
As they say, some big questions have a very simple answer!
Depending on a post I found, in my resources editor tool, I added this code in my action with other few changes in the bootstarp (see link at the end of the answer):
def messageSource
def saveMessageResources={
.
.
.
//my action logic
.
.
.
messageSource.clearCache()
}
and it worked :)
References: http://jira.grails.org/browse/GPAPPENGINE-44
Deployed application will not pick up changes until you restart it. Changes are reloaded on-thy-fly only in development mode for your convenience. It is called "hot-deployment" because only parts that are changed (messages.properties in your case) are applied.
If you want to edit messages in deployed application you can apply alternative solution - localisation plugin that keeps your messages in database.
Related
I realized my first WebApp with Vaadin 14 and deployed it to Tomcat 9 on the production server.
So far everything is working great, but when I'm using a non-existing route in the client browser the system responds with a plain text list of all available routes and shows even the following line on the bottom:
"This detailed message is only shown when running in development mode."
I have created the WAR-file with "-pProduction" and the startup-log of Tomcat does not show any dev-mode-message.
Any ideas what happens here? Thanks for reading my first question on this platform!
I worked my way through the Vaadin docs and tried the following entry in application.properties:
vaadin.productionMode=true
But nothing changed?
This is a known vulnetability CVE-2021-31413 in Vaadin 14.6.1 and older versions. The resolution is to update the Vaadin version to 14.6.2. The latest version is 14.9.1 as of writing this. Naturally I recommend that.
https://vaadin.com/security/cve-2021-31412
I'm trying to use sw-precache, but I must be doing something wrong!
I'm mostly using the demo code available from the github repo and can't seem to get updates to the app to come through. Once it's cached the first time, it never checks for new versions.
I was expecting that when I publish a new service worker, the browser would request the new service worker and update the cache accordingly in the background. Then using the registration code in the example, I would be able to prompt the user to refresh and get the latest version from their newly refreshed cache.
Would really appreciate if someone could please point me in the right direction.
Example
To demonstrate the problem, I've created an isolated example here:
https://github.com/stevenocchipinti/sw-precache-demo
The example uses a basic skeleton from create-react-app which has a built in build task which take care of fingerprinting the filenames, etc.
I suspect the problem is with me caching everything by using the following sw-precache config:
{
"staticFileGlobs": [ "build/**/*.*" ],
"stripPrefix": "build/"
}
There are more accurate steps in the repo's readme, but the basic steps I'm taking to reproduce the problem are as follows (with my probably incorrect expectations).
Steps and Assumptions
Browse to the app for the first
I should see Content is now available offline! in the console
Reload the page
The message in the console should not appear again because the service worker is installed, but the page should still work.
Go offline and reload the page
The page should still work
Make a visible change to the source code
Rebuild (run the build task and sw-precache)
This is where my understanding must be wrong
Reload the page
The service worker should update the cache in the background
When its done, you should see New or updated content is available. in the console
The actual visible changes should not be visible until the next reload
Reload the page again
The browser will use the new cache this time around
The changes should be visible now!
There shouldn't be any messages in the console
The problem
Once the app has been cached initially, it will never update unless you unregister the service worker or force a reload.
I'm not sure how to make this work - any help would be greatly appreciated!
After replicating your development hosting environment, I can see that you're serving your service-worker.js file with a browser HTTP cache lifetime of one hour:
There's more information as to why this is leading to the behavior you're seeing, along with best practices, in this previous answer. As mentioned at the top of that answer, browsers plan on changing their behavior to stop honoring the HTTP cache for the service worker file by default, mainly due to the type of confusion that you're experiencing here. For the time being, though, the production versions of both Chrome and Firefox continue to honor those headers.
I'm trying to set up an MVC application that will service several facebook applications for various clients. With help from Prabir's blog post I was able to set this up with v5.2.1 and it is working well, with one exception.
At first, I had only set up two "clients", one called DemoStore and the first client, ClientA. The application determines what client content and facebook settings to use based on the url. example canvasUrl: http://my_domain.com/client_name/
This works for ClientA, but for some reason when I try any DemoStore routes I get a 500 error. The error page points to an issue with the web.config.
Config Error:
Cannot add duplicate collection entry of type 'add' with unique key attribute 'name' set to 'facebookredirect.axd'
I am able to add additional clients with no problem, and changing DemoStore to something like "demo" while using the same facebook application settings works fine also.
Working calls:
http:// localhost:2888/ClientA/
http:// localhost:2888/ClientB/
http:// localhost:2888/Demo/
Failing call:
http:// localhost:2888/DemoStore/
I was thinking this might be an MVC issue, but the Config Error points to the facebookredirect handler. Why would the SDK try to add this value to the config during runtime, and only for this specific client?
Any insight would be greatly appreciated.
I managed to figure out what went wrong here. Silly mistake..
After I had set up the application routes to require the client_name I changed the Project Url in the project properties to point to demostore by default. When I hit ctrl+S a dialog popped up that I promptly entered through without reading.
When I changed the Project Url, IIS Express created a new virtual directory for the project. This was the source of my problem. Why? I'm not sure, but once I removed the second site from my applicationhost.config I was able to access the DemoStore routes.
Moral of the story: read the VS dialog messages!
I have the following projects within my solution.
MyWebApplication.Data --> Here i interact with my Data Repository
MyWebApplication.Services --> Here i interact with the Data Layer
MyWebApplication.Web --> The UI which relies on the Service Layer
MyWebApplication.Tests --> Unit testing project
For MONTHS i have had NO problems with IIS in my local dev environment. Ready for a long weekend of programming but all day i have been getting 500 Server Errors when simply trying to resolve the Home page. Before I went to bed all was well, the entire day thereafter i could NOT even load the home/index view.
After looking at the logs it says continually MyWebApplication.Data.System (which is a class i created called System()) does not include Web. But no where in code is this true. Then i get another error of mismatching files in the Temp Directory.
Steps I have taken:
Deleted all temp files
Created a new repository in IIS and pointed URL there, No luck
Cleaned solution
Deleted all bin folders to have regenerated... No Luck
PLEASE HELP!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Without the details of the error messages, one strategy may be to create a new MVC project and copy/paste the files over to it.
A few other common causes:
Are you referencing any 64-bit libraries but compiling the project as 32-bit (or vice-versa)? Try changing the "bitness" of your application.
If your application is 32-bit and is running on a 64-bit server, you need to enable running 32-bit apps in IIS. See http://exhibita.com/blog/post/2010/03/30/IIS-75-on-x64-with-32bit-applications.aspx
If all else fails, please post the exact error messages. If all it says is "HTTP 500: Internal Server Error", you should enable debug output or run your app from the server itself (actually using a web browser on the server), which will tell IIS it's "safe" to display full debug information. The debugging messages have actually been pretty useful in my experience.
Figured it out. In
MyWebApplication.Web project, within the Shared/Site.Master I added a imported a reference to my Data Layer. (i.e., <%# Import Namespace="MyWebApplication.Data" %>
I resolved by removing the static reference to my ShoppingCart class in the Data layer and just created an ActionResult to return the same and in the MasterPage (which currently holds the javsscript to allow the user to peek into their cart from anywhere in the site without a redirect to a specific page) used the Html.RenderAction() and just returned Content(shoppingCartString).
Guess I have learned that within the Site.Master page it is complied differently than every other page in an MVC application. I can positively say this because in other pages I am doing exactly as I attempted to do here without any issues. Maybe its the build process?
Anyhow, problem solved and hopefully it can help someone else too.
Summary
When using IntelliJ IDEA to debug a JSP, I'm seeing the JSP get triggered twice before the actual request from the browser. Does anyone know why?
Updated with servlet test below.
Overview
I'm using (evaluating) IntelliJ IDEA for (effectively) the first time. When doing web application debugging, I'm seeing an odd behavior that suggests to me I have something misconfigured somewhere: If I have a breakpoint set in code that will run in response to the startup page, the code runs twice before the browser is launched, and then a third time in response to the browser request. I'd like to know whether I may have gone wrong somewhere (or if I haven't gone wrong, what's going on).
The Setup
A) Created a new web application project
Created a new project from scratch
Gave it a name and identified it as a Java module
Accepted the default src directory
Chose "Web Application" from the Desired Technologies list
That gave me a standard structure (src, WEB-INF, etc.) with a default index.jsp in it.
B) Added some simple code to the JSP to output the date.
C) Put a breakpoint in the code.
D) Configured my web browser in File | Settings | Web Browsers
E) Went to Run | Edit Configurations... and:
Clicked [+] | Tomcat Server | Local
Gave it name
Clicked the Configure... button next to the drop-down list of application servers (since I didn't have any yet) and pointed it at my standalone Tomcat6 server (see below), accepting all the defaults
Back in the debug configuration, told it to deploy the "war exploded" artifact for this configuration
Added a "?foo=bar" query string to the default startup URL, so: http://localhost:8080/?foo=bar (you'll see why below)
Left everything else at defaults
Clicked OK
The Run
Choose Run | Debug. It happily starts up the Tomcat server.
It hits the breakpoint. Examining the request shows that this is a GET from user-agent "Java/1.6.0_20". It has the query string configured above. No attributes, no parameters other than the query string one.
Click Resume Program button (F9).
It hits the breakpoint again. This is also a GET from user-agent "Java/1.6.0_20", but it does not have the query string. No attributes, no parameters.
Click Resume Program button (F9).
It launches the browser and hits the breakpoint again. This is a GET from the browser (with the query string) and looks perfectly normal.
I see the behavior both with and without the query string, I just added it to see when/whether it showed up.
If I create a class and use that class from the code in the JSP and move my breakpoint into the class's code, that breakpoint does get hit all three times, so if it were doing real work (looking something up in a database, for instance), it would really do the work. I wondered if this was some phantom pre-compile call or something, but A) it shouldn't be, and B) it doesn't seem to be.
Run with Servlet
I wanted to tease out the behavior a bit more, so I added a servlet to the project, mapped it to the path /foo, and changed my debug configuration to trigger http://localhost:8080/foo?foo=bar rather than the index page. I also added another JSP to the project, at the root, called another.jsp. This revealed very interesting behavior:
Choose Run | Debug. It happily starts up the Tomcat server.
It hits the breakpoint in the servlet code. Examining the request shows that this is a GET from user-agent "Java/1.6.0_20". It has the query string. No attributes, no parameters other than the query string one.
Click Resume Program button (F9).
It hits the breakpoint in the index.jsp(?!). This is also a GET from user-agent "Java/1.6.0_20", but it does not have the query string. No attributes, no parameters. Note that index.jsp has nothing to do with the startup path /foo.
Click Resume Program button (F9).
It launches the browser and hits the breakpoint in the servlet again. This is a GET from the browser (with the query string) and looks perfectly normal.
The breakpoint in the another.jsp file is never hit. So I suspected the triggering of the index.jsp (with no query string) relates to it being the default "welcome file." So I added a welcome-file-list to my web.xml and set up another.jsp as the only welcome-file. Sure enough, now the breakpoint in another.jsp gets hit, and not the one in index.jsp.
More Details
Fairly generic Ubuntu 10.04 LTS desktop install
Freshly downloaded and unpacked IntelliJ IDEA Ultimate installation (30-day trial)
Freshly downloaded and unpacked standalone Tomcat6 install (IDEA didn't like the central install I'd done via Synaptic, the split directory structure confused it, so I stopped that server and just used a simple download-and-unpack version)
Sun's Java 6 JDK
Thanks in advance!
Examining the request shows that this is a GET from user-agent "Java/1.6.0_20".
That happens when you deploy the webapp on ROOT of Tomcat. The Tomcat server Eclipse plugin will do a self-test on / during startup (which indirectly loads the welcome-file as definied in web.xml).
What can you do? Either live with it or deploy on a context other than ROOT.