[Wicket-user] Removal of the final attribute for WebRequestCodingStrategy.urlPrefix(RequestCycle)
Hi there. I'd like to vote/ask for the change in my subject: WebRequestCodingStrategy.urlPrefix() should be non-final. It would help me a lot in my current setup. For all those that are interested in the background story: I'm running wicket in an OSGI environment which provides the OSGI http bundle/service. I can registerServlet(/path, myservlet), but I cannot explicitly specify a context. At first I registered the wicket app at /somePath - but that doesn't work out too well, because all relative links are mangled to include a leading / by wicket, so image/some.gif ends up as /image/some.gif. This means that the setup given above only works if I register a static file handler at / - which I'd love not to do. Trying to trick wicket into understanding my setup involved mounting the wicket servlet at /somePath/app and the static file handler at /somePath/. This failed again, because all files still had the wrong prefix and ended up at /. Using getApplicationSettings().setContextPath(/somePath) seemed to work: All static files are now prepended with /somePath and work. Unfortunately dynamic resources won't work anymore. The links to a dynamic image resource are now /somePath/somePath/app?wicket:interface... Basically the /somePath/ is twice in there and I tracked the problem back to the aforementioned urlPrefix method, which computes and caches the prefix for resources as getApplicationSettings().getContextPath() and request.getServletPath() - the former is now set to /somePath for me, the latter evaluates to /somePath/app. I could fix that rather easily by extending WebRequestCodingStrategy and overriding urlPrefix(..), but since that method is final I'd need to copy the complete implementation. Which is error-prone again. So - is there any reason why this method has to be final? Regards, Ben - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Removal of the final attribute for WebRequestCodingStrategy.urlPrefix(RequestCycle)
Only my 2c. OSGI is a framework which we want to support out-of-the-box. IMO we should rather check whether I our current implementation make sense or whether it is inconsistent. I want to remove final from urlPrefix only if realy necessary. Removing final sound to me like a workaround for an isue rather than solving the real problem. Juergen On 10/30/06, Benjamin Podszun [EMAIL PROTECTED] wrote: Hi there. I'd like to vote/ask for the change in my subject: WebRequestCodingStrategy.urlPrefix() should be non-final. It would help me a lot in my current setup. For all those that are interested in the background story: I'm running wicket in an OSGI environment which provides the OSGI http bundle/service. I can registerServlet(/path, myservlet), but I cannot explicitly specify a context. At first I registered the wicket app at /somePath - but that doesn't work out too well, because all relative links are mangled to include a leading / by wicket, so image/some.gif ends up as /image/some.gif. This means that the setup given above only works if I register a static file handler at / - which I'd love not to do. Trying to trick wicket into understanding my setup involved mounting the wicket servlet at /somePath/app and the static file handler at /somePath/. This failed again, because all files still had the wrong prefix and ended up at /. Using getApplicationSettings().setContextPath(/somePath) seemed to work: All static files are now prepended with /somePath and work. Unfortunately dynamic resources won't work anymore. The links to a dynamic image resource are now /somePath/somePath/app?wicket:interface... Basically the /somePath/ is twice in there and I tracked the problem back to the aforementioned urlPrefix method, which computes and caches the prefix for resources as getApplicationSettings().getContextPath() and request.getServletPath() - the former is now set to /somePath for me, the latter evaluates to /somePath/app. I could fix that rather easily by extending WebRequestCodingStrategy and overriding urlPrefix(..), but since that method is final I'd need to copy the complete implementation. Which is error-prone again. So - is there any reason why this method has to be final? Regards, Ben - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Removal of the final attribute for WebRequestCodingStrategy.urlPrefix(RequestCycle)
I agree with that, if there is a good solution. Any takers? If there is no good one soon, I'd be +1 for removing final as it at least provides a break out for the moment. Eelco On 10/30/06, Juergen Donnerstag [EMAIL PROTECTED] wrote: Only my 2c. OSGI is a framework which we want to support out-of-the-box. IMO we should rather check whether I our current implementation make sense or whether it is inconsistent. I want to remove final from urlPrefix only if realy necessary. Removing final sound to me like a workaround for an isue rather than solving the real problem. Juergen On 10/30/06, Benjamin Podszun [EMAIL PROTECTED] wrote: Hi there. I'd like to vote/ask for the change in my subject: WebRequestCodingStrategy.urlPrefix() should be non-final. It would help me a lot in my current setup. For all those that are interested in the background story: I'm running wicket in an OSGI environment which provides the OSGI http bundle/service. I can registerServlet(/path, myservlet), but I cannot explicitly specify a context. At first I registered the wicket app at /somePath - but that doesn't work out too well, because all relative links are mangled to include a leading / by wicket, so image/some.gif ends up as /image/some.gif. This means that the setup given above only works if I register a static file handler at / - which I'd love not to do. Trying to trick wicket into understanding my setup involved mounting the wicket servlet at /somePath/app and the static file handler at /somePath/. This failed again, because all files still had the wrong prefix and ended up at /. Using getApplicationSettings().setContextPath(/somePath) seemed to work: All static files are now prepended with /somePath and work. Unfortunately dynamic resources won't work anymore. The links to a dynamic image resource are now /somePath/somePath/app?wicket:interface... Basically the /somePath/ is twice in there and I tracked the problem back to the aforementioned urlPrefix method, which computes and caches the prefix for resources as getApplicationSettings().getContextPath() and request.getServletPath() - the former is now set to /somePath for me, the latter evaluates to /somePath/app. I could fix that rather easily by extending WebRequestCodingStrategy and overriding urlPrefix(..), but since that method is final I'd need to copy the complete implementation. Which is error-prone again. So - is there any reason why this method has to be final? Regards, Ben - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Removal of the final attribute for WebRequestCodingStrategy.urlPrefix(RequestCycle)
Please first debug why it adds 2 times that path.that is just strange.What is for example your fix? What do you do then?johanOn 10/30/06, Benjamin Podszun [EMAIL PROTECTED] wrote: Hi there.I'd like to vote/ask for the change in my subject:WebRequestCodingStrategy.urlPrefix() should be non-final.It would help me a lot in my current setup. For all those that areinterested in the background story: I'm running wicket in an OSGI environment which provides the OSGI httpbundle/service. I can registerServlet(/path, myservlet), but I cannotexplicitly specify a context.At first I registered the wicket app at /somePath - but that doesn't work out too well, because all relative links are mangled to include aleading / by wicket, so image/some.gif ends up as /image/some.gif.This means that the setup given above only works if I register a static file handler at / - which I'd love not to do.Trying to trick wicket into understanding my setup involved mounting thewicket servlet at /somePath/app and the static file handler at/somePath/. This failed again, because all files still had the wrong prefix and ended up at /. UsinggetApplicationSettings().setContextPath(/somePath) seemed to work: Allstatic files are now prepended with /somePath and work. Unfortunatelydynamic resources won't work anymore. The links to a dynamic image resource are now /somePath/somePath/app?wicket:interface...Basically the /somePath/ is twice in there and I tracked the problemback to the aforementioned urlPrefix method, which computes and cachesthe prefix for resources as getApplicationSettings().getContextPath() and request.getServletPath() - the former is now set to /somePath forme, the latter evaluates to /somePath/app.I could fix that rather easily by extending WebRequestCodingStrategy and overriding urlPrefix(..), but since that method is final I'd need tocopy the complete implementation. Which is error-prone again.So - is there any reason why this method has to be final?Regards, Ben-Using Tomcat but need to do more? Need to support web services, security?Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimohttp://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
