Hi, if you can initialize your resource in a page constructor, you can do the same thing with an IInitializer. You could create shared resources there, for example - then just use any of the applicable resource classes and use TextTemplate for interpolation.
Carl-Eric www.wicketbuch.de On Thu, 09 Dec 2010 12:38:23 +0100 Chris Wewerka <christian.wewe...@1und1.de> wrote: > Hi, > > thanks Carl-Eric. > We're using sticky sessions already and the config seems to work for > everyting except CSS files. I've just seen that the browser also > sends the cookie containing the jsessionid along with the css > request, so maybe our sticky session config is wrong here. Already > wrote the admin a mail about that. > > So, but I think we can also pre initialze our css resources. > Our CSS contains paths to images which vary only between staging and > do not depend on page params. > > The problem is that it's not static, so we can simply use > PackageResource, but we have to interpolate our variable for the > imageserver. > > PackageResource uses the configured ResourceStreamLocator which in > turn uses the configured IResourceFinder which is per default > org.apache.wicket.util.file.WebApplicationPath. This buddy uses an > FileResourceStream and here I have to intercept: Write a separate > impl. of WebApplicationPath which uses an TextTemplate instead of an > FileResourceStream, and configure this in the application so that > Application.get().getResourceSettings().getResourceFinder() returns > my interpolating implementation. > > Is there a simpler way for this? > > Best regards > Chris > > > > On 12/09/2010 11:48 AM, Carl-Eric Menzel 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
