Thanks, Andrea. I was running in DEVELOPMENT mode and switching to DEPLOYMENT mode fixed the problem. I hope this gets documented somewhere.
Martin, are you saying that page rendering will not block waiting for the static resource to render while it will block on a component resource to render? Maybe I need to learn more about page locking in Wicket ... Thanks, Alec On Wed, Apr 27, 2011 at 3:20 AM, Martin Grigorov <mgrigo...@apache.org> wrote: > Static resources are more suitable for the cases when you want to > avoid page locking. > E.g. when you need to deliver dynamic response and there is a chance > that the processing will be slower or there will be more clients for > the same resource. Using a normal component for this will suffer that > only one request can use one page instance (pagemap in 1.4) at a time. > > On Wed, Apr 27, 2011 at 11:54 AM, Andrea Del Bene <adelb...@ciseonweb.it> > wrote: >> Hi Alec, >> >> are you sure you are testing your code in DEPLOYMENT mode and not in >> DEVELOPMENT mode? >> >> To answer your question about benefits of using shared resources, I can say >> that they make sense when you need to access a resource (like a picture) >> with >> an absolute path instead of a relative one (which typically is >> "./resource/package.of.class/pictureName.png" ). >> >>> Hello, >>> >>> I would like to get my Javascript files filtered and gzipped. I added >>> the following code in my Application#init(): >>> resourceSettings.setJavascriptCompressor(new >>> DefaultJavascriptCompressor()); >>> >>> However, when I add a resource using the following code, I can still >>> see comments and white spaces in the Javascript files loaded by the >>> web pages: >>> final JavascriptResourceReference resourceRef = new >>> JavascriptResourceReference(scope, "/common.js"); >>> >>> component.add(JavascriptPackageResource.getHeaderContribution(resourceRef)); >>> >>> What am I doing wrong? >>> >>> Also, I am struggling to understand the benefits of using shared >>> resources, e.g. when does it make sense to create a shared resource >>> for a Javascript file? >>> >>> Thanks, >>> >>> Alec >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
