I thought I'd bring this up again, just in case...

> > how old is the snapshot you are using? do you have the source
> > attached? if so take a look at sourcecode for MarkupParserFactory, do
> > you see the prepender added in the constructors?
> 
> I'm using 20060227-0200.
> 
> Yes, I did notice the PrependContextPathHandler class added to the
> filters.

I finally figured out the reason for the problem I was having concerning
prepending the context path to resources. Turns out that you were right:
it was related to OSGi.

Rather, to be more precise, the difference is that because I am using
OSGi, the context path is not set in web.xml, which is, I believe, where
Wicket expects to find it. My assumption is therefore that Wicket
considered the path to be null, so ended up translating it as "/".


Now, I did notice something odd, that I wanted to point out just in
case. Due to the above, I am now injecting the root context into my
Wicket app by explicitly setting the root context. This effectively
solves my problems for resources, but apparently creates another for my
links. This may be a bug.

What now happens is that links are rendered as:

  /contextRoot/contextRoot/link

In other words, the context root is now being prepended twice to the
links, ever since I explicitly set the context root in my application.

I don't understand why links are treated one way, and resources another.

I looked at the Wicket code, but nothing jumped out at me.


Cheers,
Dave





-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to