You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by David Leangen <wi...@leangen.net> on 2007/08/15 05:57:12 UTC
Caching the context path
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Caching the context path
Posted by Eelco Hillenius <ee...@gmail.com>.
> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Caching the context path
Posted by David Leangen <wi...@leangen.net>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Caching the context path
Posted by Kent Tong <ke...@cpttm.org.mo>.
David Leangen <wicket <at> leangen.net> writes:
> 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:
>
> Branding getBranding( String url );
Have you considered using mod_rewrite (in Apache) to convert the one
URL to the other? Your app can still retrieve the requested URL to
determine the branding.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Caching the context path
Posted by David Leangen <wi...@leangen.net>.
> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Caching the context path
Posted by Al Maw <wi...@almaw.com>.
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:wicket@almaw.com]
>> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
> !DSPAM:46c442b3323394576627205!
>
--
Alastair Maw
Wicket-biased blog at http://herebebeasties.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Caching the context path
Posted by David Leangen <wi...@leangen.net>.
> 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:wicket@almaw.com]
> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Caching the context path
Posted by Al Maw <wi...@almaw.com>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Caching the context path
Posted by Jan Kriesten <ja...@renitence.de>.
hi david,
>>> 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.
actually, with filter i could have mounted it anywhere else, too.
best regards, --- jan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Caching the context path
Posted by David Leangen <wi...@leangen.net>.
> > 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Caching the context path
Posted by Jan Kriesten <ja...@renitence.de>.
Hi David,
>> Can I ask: on what context path did you mount your wicket? You must have
>> mounted it on "/*", right?
yes.
> Damn!
> 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. ;-)
Best regards, --- Jan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Caching the context path
Posted by David Leangen <wi...@leangen.net>.
Damn!
Looks like WicketFilter is only available in 1.3. :-(
> -----Original Message-----
> From: David Leangen [mailto:wicket@leangen.net]
> Sent: 16 August 2007 20:56
> To: users@wicket.apache.org
> Subject: 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:jan.kriesten@renitence.de]
> > 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: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Caching the context path
Posted by David Leangen <wi...@leangen.net>.
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:jan.kriesten@renitence.de]
> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Caching the context path
Posted by Jan Kriesten <ja...@renitence.de>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Caching the context path
Posted by David Leangen <wi...@leangen.net>.
> 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:
Branding getBranding( String url );
For the case of:
www.something.com --> SomethingBranding
www.somethingelse.com --> SomeOtherBranding
that's easy, since I don't care what the context is.
What I'm having trouble with is when the difference is based on the context
(which is also a requirement), so:
www.something.com/someApp --> SomeBranding
www.something.com/someOtherApp --> SomeOtherBranding
I was able to mount the same instance of Wicket on more than one contexts by
using a delegate servlet, so like so:
public class ServletDelegator extends HttpServlet
{
private HttpServlet delegate;
public ServletDelegator( HttpServlet delegate )
{
this.delegate = delegate;
}
public void init()
{
delegate.init();
}
public void service( HttpServletRequest req, HttpServletResponse resp )
{
delegate.service( req, resp )
}
:
}
So, requests on the different context paths are routed to the same instance
of wicket.
> obviously you cant really share an app across actual contexts
> because they are supposed to be isolated.
Well, I guess it's obvious if Wicket was designed with that principle in
mind, which now I know it is. So, that answers my question: I guess it's not
really feasible to do it the way I'm trying to do it.
> 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?
Essentially, that sounds about right. I figured that this way, wicket just
needs to deal with different paths, and should "know" what it's dealing
with.
Don't know if this is a good idea or not, but maybe I could map the URL
requests through some kind of proxy or mapping service, so:
www.something.com/someApp --> www.something.com/app/someApp
www.something.com/someOtherApp --> www.something.com/app/someOtherApp
I don't really see what that changes and why this should be necessary, but
from wicket's point of view, would that make things easier for me?
> > 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.
Hmmm... Ok, it's sounding more and more like I need an upgrade !
Thanks again for all the help!
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Caching the context path
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <wi...@leangen.net> 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: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Caching the context path
Posted by David Leangen <wi...@leangen.net>.
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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org