Re: Caching the context path
Hi David,
what you're doing with different brandings I do similar for different languages
with Wicket 1.3.
I want www.xy.de/de/ map to german and www.xy.de/en/ map to english interface of
the application.
What I did was extending WicketFilter to support path-extensions. I just
implemented:
public String getRelativePath( HttpServletRequest request )
{
String relPath = super.getRelativePath( request );
int idx;
int len = relPath.length();
if( len 2 (idx = relPath.indexOf( '/' )) = 0 )
{
String lang = relPath.substring( 0, idx ).toLowerCase();
Locale locale = availableLocales.get( lang );
if( locale != null )
{
relPath = len lang.length() ? relPath.substring( lang.length() + 1 )
: ;
request.setAttribute( LANG_ATTRIBUTE, locale );
}
}
return(relPath);
}
So, this takes the first part of the relativePath from the request and checks if
I have a supported language for it. If so, I set the Locale in the
request-Attributes and my Application can access that.
Something similar might work for you.
Best regards --- Jan.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Caching the context path
Kent, Have you considered using mod_rewrite (in Apache) to convert the one URL to the other? Thanks for the suggestion. Actually, I already use mod_proxy on my proxy server to rewrite the URLs to something like this: ProxyPass /cxt/ http://192.168.x.x:8080/cxt/ ProxyPassReverse /cxt/ http://192.168.x.x:8080/cxt/ What you're suggesting won't really change anything, I think, since there would be no way of knowing how to do the reverse mapping. In other words, if I mount my project on wicket, and redirect cxt1 and cxt2, I would have to write this: ProxyPass /cxt1/ http://192.168.2.2/wicket/ ProxyPassReverse /cxt1/ http://192.168.2.2/wicket/ ProxyPass /cxt2/ http://192.168.2.2/wicket/ ProxyPassReverse /cxt2/ http://192.168.2.2/wicket/ The ProxyPass commands are fine, but there is a problem with the reverse mapping, since the same path maps to two different values. Unless, of course, mod_proxy is much smarter than I am assuming. What could be possible is this: ProxyPass /cxt1/ http://192.168.2.2/wicket/cxt1/ ProxyPassReverse /cxt1/ http://192.168.2.2/wicket/cxt1/ ProxyPass /cxt2/ http://192.168.2.2/wicket/cxt2/ ProxyPassReverse /cxt2/ http://192.168.2.2/cxt2/ But, like I wrote in my last mail, I don't see the difference... Is there something I didn't consider that you were trying to suggest? Your app can still retrieve the requested URL to determine the branding. Oh... you did point out one thing that I didn't fully appreciate until now... you're right! Even if I rewrite the URL with mod_proxy, the original request stays intact... this could be useful... Thanks! Cheers, Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Caching the context path
Jan,
Thanks! This sounds just like what I need.
Can I ask: on what context path did you mount your wicket? You must have
mounted it on /*, right?
Cheers,
Dave
-Original Message-
From: Jan Kriesten [mailto:[EMAIL PROTECTED]
Sent: 16 August 2007 19:02
To: users@wicket.apache.org
Subject: Re: Caching the context path
Hi David,
what you're doing with different brandings I do similar for
different languages
with Wicket 1.3.
I want www.xy.de/de/ map to german and www.xy.de/en/ map to
english interface of
the application.
What I did was extending WicketFilter to support path-extensions. I just
implemented:
public String getRelativePath( HttpServletRequest request )
{
String relPath = super.getRelativePath( request );
int idx;
int len = relPath.length();
if( len 2 (idx = relPath.indexOf( '/' )) = 0 )
{
String lang = relPath.substring( 0, idx ).toLowerCase();
Locale locale = availableLocales.get( lang );
if( locale != null )
{
relPath = len lang.length() ? relPath.substring(
lang.length() + 1 ) : ;
request.setAttribute( LANG_ATTRIBUTE, locale );
}
}
return(relPath);
}
So, this takes the first part of the relativePath from the
request and checks if
I have a supported language for it. If so, I set the Locale in the
request-Attributes and my Application can access that.
Something similar might work for you.
Best regards --- Jan.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Caching the context path
David Leangen wrote: so what exactly are you doing? Well... the end goal is to use the URL as the controlling input for the branding of my application. So I have a BrandingService with something like: I'd suggest a better way of doing this... Run a single Wicket app. For the different inbound URLs, get Apache to add a header X-Branding with some appropriate String. Add a HeaderContributor in your base page which points to the appropriate CSS for that attribute, dug out of the WebRequest object. I assume you're using 1.3.x for this? Regards, -- Alastair Maw Wicket-biased blog at http://herebebeasties.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Caching the context path
I'd suggest a better way of doing this... ... For the different inbound URLs, get Apache to add a header X-Branding with some appropriate String. ... Oh, that's interesting, too... I assume you're using 1.3.x for this? No... unfortunately, I'm stuck on 1.2.6 for now. Why? Won't this work on 1.2.6? Cheers, Dave -Original Message- From: Al Maw [mailto:[EMAIL PROTECTED] Sent: 16 August 2007 21:07 To: users@wicket.apache.org Subject: Re: Caching the context path David Leangen wrote: so what exactly are you doing? Well... the end goal is to use the URL as the controlling input for the branding of my application. So I have a BrandingService with something like: I'd suggest a better way of doing this... Run a single Wicket app. For the different inbound URLs, get Apache to add a header X-Branding with some appropriate String. Add a HeaderContributor in your base page which points to the appropriate CSS for that attribute, dug out of the WebRequest object. I assume you're using 1.3.x for this? Regards, -- Alastair Maw Wicket-biased blog at http://herebebeasties.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Caching the context path
Looks like WicketFilter is only available in 1.3. :-( something like this should be possible with extending/modifying WicketServlet as well I assume. But I really only assume. ;-) Actually, that's pretty much what I'm doing now, so... You must have mounted it on /*, right? yes. I suspect that I'll need to mount on /* for this to work. I'll somehow need to figure out how to make this work together with my other apps. Thanks again. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Caching the context path
You can use the header approach just fine on 1.2.x. If you were using 1.3.x then your pointing two paths at the same wicket app would work fine too, I think. If you're running behing mod_proxy I'd strongly recommend upgrading to 1.3.0-beta2 - it solves a bunch of issues with this by using relative URLs everywhere instead. Regards, Al David Leangen wrote: I'd suggest a better way of doing this... ... For the different inbound URLs, get Apache to add a header X-Branding with some appropriate String. ... Oh, that's interesting, too... I assume you're using 1.3.x for this? No... unfortunately, I'm stuck on 1.2.6 for now. Why? Won't this work on 1.2.6? Cheers, Dave -Original Message- From: Al Maw [mailto:[EMAIL PROTECTED] Sent: 16 August 2007 21:07 To: users@wicket.apache.org Subject: Re: Caching the context path David Leangen wrote: so what exactly are you doing? Well... the end goal is to use the URL as the controlling input for the branding of my application. So I have a BrandingService with something like: I'd suggest a better way of doing this... Run a single Wicket app. For the different inbound URLs, get Apache to add a header X-Branding with some appropriate String. Add a HeaderContributor in your base page which points to the appropriate CSS for that attribute, dug out of the WebRequest object. I assume you're using 1.3.x for this? Regards, -- Alastair Maw Wicket-biased blog at http://herebebeasties.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] !DSPAM:46c442b3323394576627205! -- Alastair Maw Wicket-biased blog at http://herebebeasties.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Caching the context path
If you're running behing mod_proxy I'd strongly recommend upgrading to 1.3.0-beta2 - it solves a bunch of issues with this by using relative URLs everywhere instead. Hmmm... that looks like it's going to take a lot of work... but I guess I'll need to do it sooner or later. :-/ Ok, thanks for the suggestions! Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Caching the context path
so what exactly are you doing? obviously you cant really share an app across
actual contexts because they are supposed to be isolated.
so what do you do? you have a single application object, but you map two
filters with two different paths and share the single instance of
application object via custom applicationfactory?
-igor
On 8/15/07, David Leangen [EMAIL PROTECTED] wrote:
Hmmm...
Very nasty things are happening in my forms. Because it's not resolving
the URLs properly, wicket thinks that my pages are expired.
Does this mean that I have no choice but to re-instantiate a new wicket
for each context?
In other words, is what I'm trying to do too much to ask of wicket
without some major changes?
Or is there a relatively simple way I could get this to work?
On Wed, 2007-08-15 at 12:57 +0900, David Leangen wrote:
I'm attempting to mount one instance of wicket on more than one context
path. However, something is not working as I expect it to from within
Wicket, due to some kind of caching going on.
Essentially, I have my servlet container setup so that both of the
following get routed to the same instance of wicket:
www.example.com/cxt1/
www.example.com/cxt2/
On the first run, both work as expected.
If I try to access directly either one of:
www.example.com/cxt1/somePage
www.example.com/cxt2/somePage
also no problem.
However, if I first access cxt1, then later try to access:
www.example.com/cxt2{/}
Wicket is forwarding me back to:
www.example.com/cxt1
And vice-versa when I first access cxt2 and later try to access cxt1
without a path.
Also, none of my links are working as expected. Once cxt1 is cached, all
my links now point to that context, which messes up what I'm trying to
do.
Is this a bug? If so, where should I look to fix this?
Thanks!
David
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Caching the context path
Is this a bug? If so, where should I look to fix this? Wicket 1.2 was gready in determining and using the path. I think what you want should work with Wicket 1.3. Didn't test it yet though. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
