Re: Caching the context path
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: [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
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
> > 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
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Caching the context path
Damn!
Looks like WicketFilter is only available in 1.3. :-(
> -Original Message-
> From: David Leangen [mailto:[EMAIL PROTECTED]
> 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:[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]
>
>
-
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
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
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
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
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
David Leangen 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Caching the context path
> 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: [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]
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
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]
