I've studied the example, but I'm still not seeing how to make it work at the root. I'm trying to get URLs like this
http://localhost:8080/ - container should render index.html http://localhost:8080/foo - should render HomePage http://localhost:8080/bar - should render HomePage http://localhost:8080/foo/wicket/bookmarkable/com.example.OtherPage which don't have the /localized prefix (the example uses /localized/en_US/) So I tried replacing this: getRootRequestMapperAsCompound().add( new LocaleFirstMapper(new MountedMapper("/localized", LocalizedPage.class))); with this (because I don't have a prefix like "/localized") getRootRequestMapperAsCompound().add( new MyLocaleFirstMapper(getRootRequestMapper())); but then it goes into a loop "delegating to the chain". I feel like I'm missing something obvious... not too proud to ask for a bit more hand holding? Thanks very much, -- Jim. On Mon, Nov 22, 2010 at 1:13 PM, Igor Vaynberg <[email protected]>wrote: > this would indeed be much simpler with 1.5. wicket-examples in 1.5 > contains some request mapper examples you can take a look at. > basically, you can use the same idea as LocaleFirstMapper to always > prepend the client name into the first segment of the url - creating > virtual contexts in the url space of an app that runs as the root > context. > > -igor > > On Mon, Nov 22, 2010 at 9:58 AM, Jim Pinkham <[email protected]> wrote: > > I've got a wicket 1.3 app I'm refactoring to add security and more > scalable > > 'root contexts'. > > > > I think may involve going to wicket 1.5 but I haven't found any actual > > examples of this to study - seems like it would be a common need. > > > > Right now, I have a dozen different maven profiles that crank out nearly > > identical war files named for each profile (aka root-context aka > clients). > > I'll run out of memory soon with this approach so I'd really like to get > > back to just a single war file to deploy at root context and somehow pull > > the client names dynamically. > > > > It would be OK to redeploy to add client mappings at app.init since there > is > > some db config for each new one anyway, although it would be best to have > no > > outage for other clients when new one is added > > > > For the security, I found a great help > > here< > http://out-println.blogspot.com/2009/02/wicket-swarm-spring-security-how-to.html > >. > > Unfortunately, it doesn't work with Wicket 1.5. Anyone working on that? > I > > gave it a quick effort, but got stuck on the WaspWebApplication's > > newRequestCycle method which I just don't understand. The best I could > do > > was get it all working with: > > <wicket.version>1.4.13</wicket.version> > > <swarm.version>1.4.1</swarm.version> (and for this I had to > > declare and download manually: swarm,wasp,hive,wicomsec) > > <jetty.version>6.1.25</jetty.version> > > <spring-security.version>2.0.4</spring-security.version> > > > > I had thought to try spring-security's OpenID authentication so my users > > could use their existing gmail or flickr or whatever ids and not have to > > create a new one just for my sites... but now I'm thinking to keep it > > simpler and just use wicket-auth-roles in order to use wicket 1.5. > > > > Can anyone offer advice to help me make progress on either of these > issues? > > > > Thanks, > > -- Jim. > > > > http://togetherauction.com > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
