sticky sessions or make sure your cluster has session replication enabled - so that when the css hit comes into the second server it has the page from the first server.
-igor On Thu, Dec 9, 2010 at 12:48 PM, Carl-Eric Menzel <cmen...@wicketbuch.de> wrote: > Hi, > > seems to me you should probably use sticky sessions in your > loadbalancer ;-) > > I think if your resource depends on instance variables in your Page you > really need to do that. If you just depend on stuff happening in the > initialization of the Page class (not an instance) you could use an > Initializer that gets run on application startup. See > org.apache.wicket.IInitializer for details. > > Carl-Eric > www.wicketbuch.de > > > On Thu, 09 Dec 2010 11:22:54 +0100 > Chris Wewerka <christian.wewe...@1und1.de> wrote: > >> Hi, >> >> I've used the approach described in >> https://cwiki.apache.org/confluence/display/WICKET/Dynamically+Generate+a+CSS+Stylesheet >> for dynamic CSS and js files. (already added my comment, point 5) >> >> But I've experienced a problem in our live cluster (two tomcats with >> apaches and a loadbalancer) >> >> For example, if server1 and server2 sit behind a loadbalancer and >> your wicket app is freshly started it might happen, that the first >> user gets directed to server1, from which he gets the start page. >> This page may include dynamic css like above which the browser now >> loads in a separate request which maybe gets delegated to server2, >> which maybe has never initialized the start page. Now the wicket app >> from server2 serves the css without resolving the variables. >> >> I'm scanning through the wicket resources, especially >> SharedResources.java and PackageResource but I'm not sure how to >> solve the problem since CSSPackageResource is for static resources >> and DynamicWebResource is in a different branch of the Resource >> hierarchy, so before writing my own DynamicCSSResource >> implementation, I wanted to ask if someone else had the same problem >> and if there is already a solution for it, which I didn't find yet. >> >> Regards Chris >> >> --------------------------------------------------------------------- >> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
