Zipped Resources plugin prevents js reloading
Locked
Zipped Resources plugin prevents js reloading
 
|
Hi,
I was having to stop and start my grails app for getting js changes in modules to reflect on the browser. On enabling debug, I saw this in the logs: 2012-07-24 16:29:41,277 [pool-5-thread-1] DEBUG pedresources.ZipResourceMapper - Skipping rename of /Users/rahulsomasunderam/.grails/2.0.3/projects/healthdock/tomcat/work/Tomcat/localhost/healthdock/grails-resources/bundle-bundle_auditMessage_defer.js as zipped file exists So I removed Zipped Resources from my BuildConfig and then everything works. I don't have much of a problem with removing it, but I've got some questions: * If I'm using Apache HTTPD with Tomcat using mod_proxy_ajp, does ZippedResources make any difference? * Can compression be achieved using Apache? If yes, is it any different from ZippedResources? (Not really a grails question, but I was hoping someone would know.) R, rahul
|
smime.p7s (6K)
Re: Zipped Resources plugin prevents js reloading
|
I've had a lot of trouble with the Resources during development not reloading changed files. I find that — if you can get away with it — disabling all resources processing under development it best. (I've been meaning to write up a post about this...) [Note: This only works if you don't rely on certain plugins, like one of the less plugins. If you disable processing with something like that, you'll get raw less files served up as CSS, and your styling will most likely break.] To effectively disable resources during development, add this to your Config.groovy: environments { development { grails.resources.debug = true grails.resources.processing.enabled = false grails.resources.adhoc.excludes = ['**/*.*'] } } I do this, and it makes writing complex JS applications much easier, since the JS reloads dynamically. You can also manually disable specific wrappers instead, like this: environments { development { // cached-resources grails.resources.mappers.hashandcache.excludes = ['**/*.*'] // resource bundling grails.resources.mappers.bundle.excludes = ['**/*.*'] // zipped-resources grails.resources.mappers.zip.excludes = ['**/*.*'] } } Either way, you can still use the resources plugins for production, without relying on a third-party wrapper like Apache. This should keep your application more portable, should you decide to run it under a different environment. - Phil Rahul Somasunderam wrote:
|
Re: Zipped Resources plugin prevents js reloading
|
On 25 Jul 2012, at 06:54, Phil DeJarnett wrote: > I've had a lot of trouble with the Resources during development not reloading changed files. I find that — if you can get away with it — disabling all resources processing under development it best. (I've been meaning to write up a post about this...) > > [Note: This only works if you don't rely on certain plugins, like one of the less plugins. If you disable processing with something like that, you'll get raw less files served up as CSS, and your styling will most likely break.] > > To effectively disable resources during development, add this to your Config.groovy: > > environments { > development { > grails.resources.debug = true > grails.resources.processing.enabled = false > grails.resources.adhoc.excludes = ['**/*.*'] > } > } > > I do this, and it makes writing complex JS applications much easier, since the JS reloads dynamically. You can also manually disable specific wrappers instead, like this: > > environments { > development { > // cached-resources > grails.resources.mappers.hashandcache.excludes = ['**/*.*'] > // resource bundling > grails.resources.mappers.bundle.excludes = ['**/*.*'] > // zipped-resources > grails.resources.mappers.zip.excludes = ['**/*.*'] > } > } > > Either way, you can still use the resources plugins for production, without relying on a third-party wrapper like Apache. This should keep your application more portable, should you decide to run it under a different environment. > >> Hi, If you are not using cached-resources plugin that gives resources unique names when their content changes, then some browsers may cache content because the file name does not change, even if you edited the file and resources reprocessed it. Most browsers seem to do a full reload on shift-reload. If you are using cached-resources you should never see this problem. We could look at adding a timestamp to resource URIs in dev mode only, through a switch. We have a mechanism for this already that is used when you add ?_debugResources=y to the URI in your browser address bar - but this also turns off resource processing. Marc ~ ~ ~ Marc Palmer Freelancer (Grails/Groovy/Java/UX) I offer commercial support for Grails plugins from as low as $50/mo. For details see: http://grailsrocks.com Blog: http://www.anyware.co.uk | Resumé: http://www.anyware.co.uk/marc Contributor @ http://grails.org | Founder @ http://noticelocal.com Developer @ http://weceem.org | Member @ http://spottymushroom.com Twitter: http://twitter.com/wangjammer5 --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: Zipped Resources plugin prevents js reloading
|
|
I understand that this is how it should work, but it just didn't for me. This is with both cached resources and zipped resources. I use Firefox, and I know about shift-refreshing. I also have a toolbar button that clears the cache completely (and works). I've actually watched the browser re-download the incorrect CSS and JS files in Firebug, because that's what was being served by Grails. The only way I found to consistently get updated JS and CSS files was to stop and restart the server, which is absolutely unacceptable for client-side JS development and CSS work. I don't know where the problem lays, but it was consistent enough to really piss me off at the time. I think it has to do with the delay between saving a file, then Grails picking up that the file changed, and Resources updating the cache. I'm on a Mac, if that helps any, running JDK 1.6. I love how resources works for production, but it pretty much only gets in the way during active development.
This really doesn't help. I use asynchronous JS loading via AMD modules, and they need to be loaded from ad-hoc URLs. In other words, I have no way of knowing the hashed file name in the client, so I have to load the normal URL, which is redirected to the cached one. Adding a timestamp doesn't solve it, and it actually changes the base URL of the Dojo AMD loader, potentially breaking the ability to find other modules. I still believe the correct way to use resources is to disable it by default on the development environment. It could be overridden to test the effect of resources modules using ?_enableResources=y. - Phil DeJarnett
|
Re: Zipped Resources plugin prevents js reloading
|
On Jul 25, 2012, at 8:24 PM, Phil DeJarnett wrote:
|
Re: Zipped Resources plugin prevents js reloading
|
|
In reply to this post by OverZealous
On 25 Jul 2012, at 19:24, Phil DeJarnett wrote: >> If you are not using cached-resources plugin that gives resources unique names when their content changes, then some browsers may cache content because the file name does not change, even if you edited the file and resources reprocessed it. >> >> Most browsers seem to do a full reload on shift-reload. >> >> If you are using cached-resources you should never see this problem. > > I understand that this is how it should work, but it just didn't for me. This is with both cached resources and zipped resources. I use Firefox, and I know about shift-refreshing. I also have a toolbar button that clears the cache completely (and works). I've actually watched the browser re-download the incorrect CSS and JS files in Firebug, because that's what was being served by Grails. The only way I found to consistently get updated JS and CSS files was to stop and restart the server, which is absolutely unacceptable for client-side JS development and CSS work. > Yes, well its not supposed to be like that obviously. > I don't know where the problem lays > , but it was consistent enough to really piss me off at the time. I think it has to do with the delay between saving a file, then Grails picking up that the file changed, and Resources updating the cache. I'm on a Mac, if that helps any, running JDK 1.6. > > I love how resources works for production, but it pretty much only gets in the way during active development. > It shouldn't, and doesn't for me and others. I'm wondering if there is another confounding factor here. What version of Grails are and Resources you using? For it to re-download the same content, the processing can not have run or be finished. If it has not run, that will likely be because Grails has not told Resources that something has changed. If it is running, on any recent-era Resources versions you should get a page showing that reload is occurring, which auto refreshes when it is done. >> We could look at adding a timestamp to resource URIs in dev mode only, through a switch. We have a mechanism for this already that is used when you add ?_debugResources=y to the URI in your browser address bar - but this also turns off resource processing. > > This really doesn't help. I use asynchronous JS loading via AMD modules, and they need to be loaded from ad-hoc URLs. In other words, I have no way of knowing the hashed file name in the client, so I have to load the normal URL, which is redirected to the cached one. Adding a timestamp doesn't solve it, and it actually changes the base URL of the Dojo AMD loader, potentially breaking the ability to find other modules. > Ah well this may well be the nuance. You're saying this is for undeclared resources. > I still believe the correct way to use resources is to disable it by default on the development environment. It could be overridden to test the effect of resources modules using ?_enableResources=y. You are welcome to turn it off - or uninstall it. However you should not need to. It is very important to see in development what you will see in production. If there are indeed bugs we need to find and fix them. I have not experience these problems you are mentioning, and I use it a lot. It doesn't mean they're not real, but there is something different between our setups. Maybe your Grails instance is not triggering reload as fast as you'd like. Maybe it is related to their ad-hoc nature - but are they really ad-hoc (i.e. linked to with r:external/g:external or r:resource/g:resource) or are they "legacy" i.e. just using a relative URL in JS? If they are "legacy" you should exclude them from processing. The legacy stuff is not meant for this kind of usage - the redirects will always cause you pain. The gain of zipping the JS is removed by requiring a redirect. Personally, I would try adding adhoc excludes (yes, excludes legacy stuff... bad name) for these dynamic JS resource you have. I suspect this may fix the problem for you, because it sounds like the issue is in the ad hoc reload handling / browser caching. Resources stuff is never going to work well with JS module systems that load code relative to themselves - if that is what your code is doing. Marc ~ ~ ~ Marc Palmer Freelancer (Grails/Groovy/Java/UX) I offer commercial support for Grails plugins from as low as $50/mo. For details see: http://grailsrocks.com Blog: http://www.anyware.co.uk | Resumé: http://www.anyware.co.uk/marc Contributor @ http://grails.org | Founder @ http://noticelocal.com Developer @ http://weceem.org | Member @ http://spottymushroom.com Twitter: http://twitter.com/wangjammer5 --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: Zipped Resources plugin prevents js reloading
|
|
In reply to this post by rlovtangen
On 25 Jul 2012, at 21:04, Ronny Løvtangen wrote: > > On Jul 25, 2012, at 8:24 PM, Phil DeJarnett wrote: > >>> If you are not using cached-resources plugin that gives resources unique names when their content changes, then some browsers may cache content because the file name does not change, even if you edited the file and resources reprocessed it. >>> >>> Most browsers seem to do a full reload on shift-reload. >>> >>> If you are using cached-resources you should never see this problem. >> >> I understand that this is how it should work, but it just didn't for me. This is with both cached resources and zipped resources. I use Firefox, and I know about shift-refreshing. I also have a toolbar button that clears the cache completely (and works). I've actually watched the browser re-download the incorrect CSS and JS files in Firebug, because that's what was being served by Grails. The only way I found to consistently get updated JS and CSS files was to stop and restart the server, which is absolutely unacceptable for client-side JS development and CSS work. >> >> I don't know where the problem lays, but it was consistent enough to really piss me off at the time. I think it has to do with the delay between saving a file, then Grails picking up that the file changed, and Resources updating the cache. I'm on a Mac, if that helps any, running JDK 1.6. > > I've had similar problems. And yes, it was not due to caching in browser, but due to resources plugin not serving the new css file. Had to restart Grails to get the new css. This was with resources plugin alone. Haven't had any problems for a while, maybe because of upgraded resources plugin or Grails versions, or because I still have 'grails.resources.processing.enabled = false' in dev mode in my most css intensive project. > Hi, Which Grails version, which Resources version - and how were you linking to the resources? Is there an existing JIRA for this? Thanks ~ ~ ~ Marc Palmer Freelancer (Grails/Groovy/Java/UX) I offer commercial support for Grails plugins from as low as $50/mo. For details see: http://grailsrocks.com Blog: http://www.anyware.co.uk | Resumé: http://www.anyware.co.uk/marc Contributor @ http://grails.org | Founder @ http://noticelocal.com Developer @ http://weceem.org | Member @ http://spottymushroom.com Twitter: http://twitter.com/wangjammer5 --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: Zipped Resources plugin prevents js reloading
|
|
On Jul 25, 2012, at 10:20 PM, Marc Palmer wrote: > > On 25 Jul 2012, at 21:04, Ronny Løvtangen wrote: > >> >> On Jul 25, 2012, at 8:24 PM, Phil DeJarnett wrote: >> >>>> If you are not using cached-resources plugin that gives resources unique names when their content changes, then some browsers may cache content because the file name does not change, even if you edited the file and resources reprocessed it. >>>> >>>> Most browsers seem to do a full reload on shift-reload. >>>> >>>> If you are using cached-resources you should never see this problem. >>> >>> I understand that this is how it should work, but it just didn't for me. This is with both cached resources and zipped resources. I use Firefox, and I know about shift-refreshing. I also have a toolbar button that clears the cache completely (and works). I've actually watched the browser re-download the incorrect CSS and JS files in Firebug, because that's what was being served by Grails. The only way I found to consistently get updated JS and CSS files was to stop and restart the server, which is absolutely unacceptable for client-side JS development and CSS work. >>> >>> I don't know where the problem lays, but it was consistent enough to really piss me off at the time. I think it has to do with the delay between saving a file, then Grails picking up that the file changed, and Resources updating the cache. I'm on a Mac, if that helps any, running JDK 1.6. >> >> I've had similar problems. And yes, it was not due to caching in browser, but due to resources plugin not serving the new css file. Had to restart Grails to get the new css. This was with resources plugin alone. Haven't had any problems for a while, maybe because of upgraded resources plugin or Grails versions, or because I still have 'grails.resources.processing.enabled = false' in dev mode in my most css intensive project. >> > > Hi, > > Which Grails version, which Resources version - and how were you linking to the resources? > > Is there an existing JIRA for this? Hmm, don't remember, but searching through the mailing list revealed this old thread of mine: http://grails.1312388.n4.nabble.com/reloading-of-static-files-in-Grails-1-4-0-M1-tc3616262.html So, it was the very early days of resources plugin and Grails 2 (Grails 1.4.0.M1 to be precise). Don't know which version of resources plugin, but most likely the latest version as of June 22, 2011. I didn't register any JIRA at the time, as I can remember. Do you know if you've fixed any bugs related to such issues? Ronny --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: Zipped Resources plugin prevents js reloading
|
|
On 25 Jul 2012, at 21:37, Ronny Løvtangen wrote: > > On Jul 25, 2012, at 10:20 PM, Marc Palmer wrote: > >> >> On 25 Jul 2012, at 21:04, Ronny Løvtangen wrote: >> >>> >>> On Jul 25, 2012, at 8:24 PM, Phil DeJarnett wrote: >>> >>>>> If you are not using cached-resources plugin that gives resources unique names when their content changes, then some browsers may cache content because the file name does not change, even if you edited the file and resources reprocessed it. >>>>> >>>>> Most browsers seem to do a full reload on shift-reload. >>>>> >>>>> If you are using cached-resources you should never see this problem. >>>> >>>> I understand that this is how it should work, but it just didn't for me. This is with both cached resources and zipped resources. I use Firefox, and I know about shift-refreshing. I also have a toolbar button that clears the cache completely (and works). I've actually watched the browser re-download the incorrect CSS and JS files in Firebug, because that's what was being served by Grails. The only way I found to consistently get updated JS and CSS files was to stop and restart the server, which is absolutely unacceptable for client-side JS development and CSS work. >>>> >>>> I don't know where the problem lays, but it was consistent enough to really piss me off at the time. I think it has to do with the delay between saving a file, then Grails picking up that the file changed, and Resources updating the cache. I'm on a Mac, if that helps any, running JDK 1.6. >>> >>> I've had similar problems. And yes, it was not due to caching in browser, but due to resources plugin not serving the new css file. Had to restart Grails to get the new css. This was with resources plugin alone. Haven't had any problems for a while, maybe because of upgraded resources plugin or Grails versions, or because I still have 'grails.resources.processing.enabled = false' in dev mode in my most css intensive project. >>> >> >> Hi, >> >> Which Grails version, which Resources version - and how were you linking to the resources? >> >> Is there an existing JIRA for this? > > Hmm, don't remember, but searching through the mailing list revealed this old thread of mine: http://grails.1312388.n4.nabble.com/reloading-of-static-files-in-Grails-1-4-0-M1-tc3616262.html > So, it was the very early days of resources plugin and Grails 2 (Grails 1.4.0.M1 to be precise). Don't know which version of resources plugin, but most likely the latest version as of June 22, 2011. I didn't register any JIRA at the time, as I can remember. Do you know if you've fixed any bugs related to such issues? OK, so to be clear you're talking about a problem from over a year ago - Resources 1.1.6 was released in December 2011 and 1.2RC-1 in June. Unless it can be reproduced with recent code and JIRA'd, its just not possible to justify the time to investigate. I am very happy to receive reproducible JIRAs on recent codebase. Kind regards Marc ~ ~ ~ Marc Palmer Freelancer (Grails/Groovy/Java/UX) I offer commercial support for Grails plugins from as low as $50/mo. For details see: http://grailsrocks.com Blog: http://www.anyware.co.uk | Resumé: http://www.anyware.co.uk/marc Contributor @ http://grails.org | Founder @ http://noticelocal.com Developer @ http://weceem.org | Member @ http://spottymushroom.com Twitter: http://twitter.com/wangjammer5 --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: Zipped Resources plugin prevents js reloading
|
|
On Jul 25, 2012, at 10:52 PM, Marc Palmer wrote: > > On 25 Jul 2012, at 21:37, Ronny Løvtangen wrote: > >> >> On Jul 25, 2012, at 10:20 PM, Marc Palmer wrote: >> >>> >>> On 25 Jul 2012, at 21:04, Ronny Løvtangen wrote: >>> >>>> >>>> On Jul 25, 2012, at 8:24 PM, Phil DeJarnett wrote: >>>> >>>>>> If you are not using cached-resources plugin that gives resources unique names when their content changes, then some browsers may cache content because the file name does not change, even if you edited the file and resources reprocessed it. >>>>>> >>>>>> Most browsers seem to do a full reload on shift-reload. >>>>>> >>>>>> If you are using cached-resources you should never see this problem. >>>>> >>>>> I understand that this is how it should work, but it just didn't for me. This is with both cached resources and zipped resources. I use Firefox, and I know about shift-refreshing. I also have a toolbar button that clears the cache completely (and works). I've actually watched the browser re-download the incorrect CSS and JS files in Firebug, because that's what was being served by Grails. The only way I found to consistently get updated JS and CSS files was to stop and restart the server, which is absolutely unacceptable for client-side JS development and CSS work. >>>>> >>>>> I don't know where the problem lays, but it was consistent enough to really piss me off at the time. I think it has to do with the delay between saving a file, then Grails picking up that the file changed, and Resources updating the cache. I'm on a Mac, if that helps any, running JDK 1.6. >>>> >>>> I've had similar problems. And yes, it was not due to caching in browser, but due to resources plugin not serving the new css file. Had to restart Grails to get the new css. This was with resources plugin alone. Haven't had any problems for a while, maybe because of upgraded resources plugin or Grails versions, or because I still have 'grails.resources.processing.enabled = false' in dev mode in my most css intensive project. >>>> >>> >>> Hi, >>> >>> Which Grails version, which Resources version - and how were you linking to the resources? >>> >>> Is there an existing JIRA for this? >> >> Hmm, don't remember, but searching through the mailing list revealed this old thread of mine: http://grails.1312388.n4.nabble.com/reloading-of-static-files-in-Grails-1-4-0-M1-tc3616262.html >> So, it was the very early days of resources plugin and Grails 2 (Grails 1.4.0.M1 to be precise). Don't know which version of resources plugin, but most likely the latest version as of June 22, 2011. I didn't register any JIRA at the time, as I can remember. Do you know if you've fixed any bugs related to such issues? > > > OK, so to be clear you're talking about a problem from over a year ago - Resources 1.1.6 was released in December 2011 and 1.2RC-1 in June. Unless it can be reproduced with recent code and JIRA'd, its just not possible to justify the time to investigate. > > I am very happy to receive reproducible JIRAs on recent codebase. Of course. I'm not complaining on an old plugin version, just commenting to someone experiencing similar problems on updated versions, that this problem has been experienced by others before. If there's no known fix for this issue in 1.1.6 or 1.2RC-1, then it might still be an issue with the current version, under special circumstances. Ronny --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
In reply to this post by Marc Palmer Local
On Wed, Jul 25, 2012 at 4:19 PM, Marc Palmer <[hidden email]> wrote:
> > On 25 Jul 2012, at 19:24, Phil DeJarnett wrote: > >>> If you are not using cached-resources plugin that gives resources unique names when their content changes, then some browsers may cache content because the file name does not change, even if you edited the file and resources reprocessed it. >>> >>> Most browsers seem to do a full reload on shift-reload. >>> >>> If you are using cached-resources you should never see this problem. >> >> I understand that this is how it should work, but it just didn't for me. This is with both cached resources and zipped resources. I use Firefox, and I know about shift-refreshing. I also have a toolbar button that clears the cache completely (and works). I've actually watched the browser re-download the incorrect CSS and JS files in Firebug, because that's what was being served by Grails. The only way I found to consistently get updated JS and CSS files was to stop and restart the server, which is absolutely unacceptable for client-side JS development and CSS work. >> > > Yes, well its not supposed to be like that obviously. > >> I don't know where the problem lays >> , but it was consistent enough to really piss me off at the time. I think it has to do with the delay between saving a file, then Grails picking up that the file changed, and Resources updating the cache. I'm on a Mac, if that helps any, running JDK 1.6. >> >> I love how resources works for production, but it pretty much only gets in the way during active development. >> > > It shouldn't, and doesn't for me and others. I'm wondering if there is another confounding factor here. > > What version of Grails are and Resources you using? > > For it to re-download the same content, the processing can not have run or be finished. If it has not run, that will likely be because Grails has not told Resources that something has changed. If it is running, on any recent-era Resources versions you should get a page showing that reload is occurring, which auto refreshes when it is done. > >>> We could look at adding a timestamp to resource URIs in dev mode only, through a switch. We have a mechanism for this already that is used when you add ?_debugResources=y to the URI in your browser address bar - but this also turns off resource processing. >> >> This really doesn't help. I use asynchronous JS loading via AMD modules, and they need to be loaded from ad-hoc URLs. In other words, I have no way of knowing the hashed file name in the client, so I have to load the normal URL, which is redirected to the cached one. Adding a timestamp doesn't solve it, and it actually changes the base URL of the Dojo AMD loader, potentially breaking the ability to find other modules. >> > > Ah well this may well be the nuance. You're saying this is for undeclared resources. > >> I still believe the correct way to use resources is to disable it by default on the development environment. It could be overridden to test the effect of resources modules using ?_enableResources=y. > > You are welcome to turn it off - or uninstall it. However you should not need to. It is very important to see in development what you will see in production. > > If there are indeed bugs we need to find and fix them. > > I have not experience these problems you are mentioning, and I use it a lot. It doesn't mean they're not real, but there is something different between our setups. Maybe your Grails instance is not triggering reload as fast as you'd like. > > Maybe it is related to their ad-hoc nature - but are they really ad-hoc (i.e. linked to with r:external/g:external or r:resource/g:resource) or are they "legacy" i.e. just using a relative URL in JS? If they are "legacy" you should exclude them from processing. The legacy stuff is not meant for this kind of usage - the redirects will always cause you pain. The gain of zipping the JS is removed by requiring a redirect. > > Personally, I would try adding adhoc excludes (yes, excludes legacy stuff... bad name) for these dynamic JS resource you have. I suspect this may fix the problem for you, because it sounds like the issue is in the ad hoc reload handling / browser caching. > > Resources stuff is never going to work well with JS module systems that load code relative to themselves - if that is what your code is doing. > > Marc > ~ ~ ~ > Marc Palmer > Freelancer (Grails/Groovy/Java/UX) > > I offer commercial support for Grails plugins from as low as $50/mo. > For details see: http://grailsrocks.com > > Blog: http://www.anyware.co.uk | Resumé: http://www.anyware.co.uk/marc > Contributor @ http://grails.org | Founder @ http://noticelocal.com > Developer @ http://weceem.org | Member @ http://spottymushroom.com > Twitter: http://twitter.com/wangjammer5 > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > I'm seeing something like this. We're on Grails 2.1.0, resources 1.2-RC1, lesscss-resources 1.3.0.3, no cached-resources. I think that the root issue is a Grails DirectoryWatcher bug (see ticket I submitted below), but certain combinations of the Resources plugin and the structure of different applications (the number of files with certain extensions in certain directories) make it cause functional impact. http://jira.grails.org/browse/GRAILS-9273 -- David M. Carr [hidden email] --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: Zipped Resources plugin prevents js reloading
|
|
In reply to this post by Marc Palmer Local
Marc Palmer wrote:
It was a relatively recent 2.0 version of Grails, but I don't remember exactly which version. I tend to upgrade my Grails pretty quickly, and I try to upgrade any plugins when I get a chance. (More below.)
I've seen the reload page. Works fine if the change is picked up at some point.
Not just the undeclared ones. I've seen it for normal CSS as well. It's just slapping a refresh string can sometimes break ad hoc (legacy) resources.
Zipping would still be a noticeable benefit for large JS libraries. Sure, for small files it isn't, but when you build the JS into a monolithic library, that compression can be 10Kb, easy.
It works perfectly fine under static (production) circumstances. It just isn't showing changes unless the server is restarted, which is a separate problem. I tried just disabling adhoc resources ( via grails.resources.adhoc.excludes = ['**/*.*']). This completely broke CSS files, where all image references are screwed up, replacing them with resource:/images/foo.png. So, if you globally disable ad-hoc, it breaks CSS processing. I can go through and disable it only for certain paths, of course. This is frustrating to say the least. This is the kind of stuff that drives me crazy with resources. It's a ton of magic, but it causes me more headaches than it ever should. I just tested reloading changes again, with Grails 2.1.0 and Resources 1.1.6. In a few quick tests, it was reloading OK. It may be a fixed issue. However, it wasn't consistent in the past, and that lack of consistency is a real problem. There's nothing like wasting an hour or two tracking down a "bug" when you already fixed it, but the browser didn't get the updated file. I don't have a lot of confidence I won't hit this hurdle again, either. - Phil DeJarnett
|
Re: Zipped Resources plugin prevents js reloading
|
|
On 25 Jul 2012, at 22:48, Phil DeJarnett wrote: > Marc Palmer wrote: >> What version of Grails are and Resources you using? > > It was a relatively recent 2.0 version of Grails, but I don't remember exactly which version. I tend to upgrade my Grails pretty quickly, and I try to upgrade any plugins when I get a chance. (More below.) > >> For it to re-download the same content, the processing can not have run or be finished. If it has not run, that will likely be because Grails has not told Resources that something has changed. If it is running, on any recent-era Resources versions you should get a page showing that reload is occurring, which auto refreshes when it is done. > > I've seen the reload page. Works fine if the change is picked up at some point. > >> Ah well this may well be the nuance. You're saying this is for undeclared resources. > > Not just the undeclared ones. I've seen it for normal CSS as well. It's just slapping a refresh string can sometimes break ad hoc (legacy) resources. > >> Maybe it is related to their ad-hoc nature - but are they really ad-hoc (i.e. linked to with r:external/g:external or r:resource/g:resource) or are they "legacy" i.e. just using a relative URL in JS? If they are "legacy" you should exclude them from processing. The legacy stuff is not meant for this kind of usage - the redirects will always cause you pain. The gain of zipping the JS is removed by requiring a redirect. > > Zipping would still be a noticeable benefit for large JS libraries. Sure, for small files it isn't, but when you build the JS into a monolithic library, that compression can be 10Kb, easy. > Yes true, but with the added min say of a 500ms RTT for the redirect to be handled, possibly a lot more. >> Personally, I would try adding adhoc excludes (yes, excludes legacy stuff... bad name) for these dynamic JS resource you have. I suspect this may fix the problem for you, because it sounds like the issue is in the ad hoc reload handling / browser caching. >> >> Resources stuff is never going to work well with JS module systems that load code relative to themselves - if that is what your code is doing. > > It works perfectly fine under static (production) circumstances. It just isn't showing changes unless the server is restarted, which is a separate problem. > > I tried just disabling adhoc resources ( via grails.resources.adhoc.excludes = ['**/*.*']). This completely broke CSS files, where all image references are screwed up, replacing them with resource:/images/foo.png. So, if you globally disable ad-hoc, it breaks CSS processing. > This is entirely expected. Images in CSS are adhoc because you don't declare them in modules usually - trivia: but you can if you want to. > I can go through and disable it only for certain paths, of course. This is frustrating to say the least. This is the kind of stuff that drives me crazy with resources. It's a ton of magic, but it causes me more headaches than it ever should. > It is easy to exclude one folder if there is a particular problem you are having. You can simply uninstall Resources however, you are not forced to use it. > I just tested reloading changes again, with Grails 2.1.0 and Resources 1.1.6. In a few quick tests, it was reloading OK. It may be a fixed issue. However, it wasn't consistent in the past, and that lack of consistency is a real problem. There's nothing like wasting an hour or two tracking down a "bug" when you already fixed it, but the browser didn't get the updated file. I don't have a lot of confidence I won't hit this hurdle again, either. I completely understand that frustration. However if we can't reproduce problems and get help from users to do this, how can we fix them? Marc ~ ~ ~ Marc Palmer Freelancer (Grails/Groovy/Java/UX) I offer commercial support for Grails plugins from as low as $50/mo. For details see: http://grailsrocks.com Blog: http://www.anyware.co.uk | Resumé: http://www.anyware.co.uk/marc Contributor @ http://grails.org | Founder @ http://noticelocal.com Developer @ http://weceem.org | Member @ http://spottymushroom.com Twitter: http://twitter.com/wangjammer5 --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
The issue still exist and I can reproduce it constantly
Environment - Grails 1.3.7 - Resources 1.1.6 The issue is with ZipResourceMapper - When I change a js file, I can see in logs that grails pickups the change and whole resource processing chain is rerun but at the end I see this 2012-07-31 12:24:51,120 [pool-1-thread-1] DEBUG org.grails.plugin.resource.mapper.zip - Skipping rename of C:\Users\Sudhir\.grails\1.3.7\projects\PROJECT-NAME\tomcat\work\Tomcat\localhost\sbi\grails-resources\bundle-bundle_colorpicker_head.js as zipped file exists processedFile=C:\Users\Sudhir\.grails\1.3.7\projects\PROJECT-NAME\tomcat\work\Tomcat\localhost\sbi\grails-resources\bundle-bundle_colorpicker_head.js.gz originalLastMod=13437176 86803 requestProcessors=[org.grails.plugin.zippedresources.ZipResourceMapper$_map_closure2@9ccb7d6] _linkUrl=/bundle-bundle_colorpicker_head.js proces sed=false _resourceExists=true declaringResource=null contentLength=3716 originalContentLength=0> Now when I open the directory C:\Users\Sudhir\.grails\1.3.7\projects\PROJECT-NAME\tomcat\work\Tomcat\localhost\sbi\grails-resources I can see that there's bundle-bundle_colorpicker_head.js and bundle-bundle_colorpicker_head.js.gz. If I open bundle-bundle_colorpicker_head.js I can see the changes in there but if I open bundle-bundle_colorpicker_head.js.gz the file content is still old. So it looks like zipped resources keeps serving the old gz file. |
«
Return to Grails - user
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |