Steve Shucker wrote: > Unless I'm really screwing up, my check works with friendly URLs. I'm > using them. They way I understand the pipeline is that service > encoders take the original http request and do some preprocessing > before you end up with a WebRequest. Look at RequestCycleFactoryImpl > and AssetEncoder to see where this happens. The short version is > that the WebRequest should have a parameter set that identifies the > tapestry service being called.
What version of Tapestry? In 4.0.2, the pipeline calls the WebRequestServicerFilter's before the RequestCycleFactory and the encoders have done their work. With friendly URLs, a typical path for an asset is something like: /assets/031a6b16419c47ad157a817021baa2d6/class/path/file This is still the form it is in when it hits the filter. getParameterNames() returns an empty list, getParameterValue(ServiceConstants.SERVICE) returns null. I'm currently using the following to recognize an asset request: "/assets".equals(request.getActivationPath()) You can verify this in the debugger by setting a breakpoint in both the filter and line 81 of RequestCycleFactoryImpl (where decodeParameters() is called), and then issuing a request for an asset. The filter will be reached first. The problem with this too, is that it's not immediately obvious that something is wrong. The filter will still do its job, namely synchronizing the requests, but it will do it unnecessarily in the case of the asset requests. If you're on a different version where things have changed, please disregard. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
