You're right and now I feel stupid. I'm actually using tapestry 4.1.1,
but I fired up the debugger to double check. Sure enough, it was
applying my filter to asset requests. I could swear this worked at one
point. Anyway, I had the code lying around to decode manually (needed
it in a regular servlet filter once), so here's a version that works:
private ServiceEncoder[] serviceEncoders;
public void service(WebRequest request, WebResponse response,
WebRequestServicer servicer)
throws IOException {
// don't filter asset requests
ServiceEncodingImpl encoding = new
ServiceEncodingImpl(request.getActivationPath(),request.getPathInfo(),extractParameters(request));
for(ServiceEncoder serviceEncoder: serviceEncoders){
serviceEncoder.decode(encoding);
if(encoding.isModified()){
break;
}
}
if
(Tapestry.ASSET_SERVICE.equals(encoding.getParameterValue(ServiceConstants.SERVICE)))
{
servicer.service(request, response);
} else {
filterRequest(request, response, servicer);
}
}
// copied from somewhere in tapestry
private QueryParameterMap extractParameters(WebRequest request) {
QueryParameterMap result = new QueryParameterMap();
Iterator i = request.getParameterNames().iterator();
while (i.hasNext()) {
String name = (String) i.next();
String[] values = request.getParameterValues(name);
if (values.length == 1) {
result.setParameterValue(name, values[0]);
} else {
result.setParameterValues(name, values);
}
}
return result;
}
Here's the hivemind config to inject the encoders:
<construct
class="com.vms.infrastructure.websession.TapestrySessionTxFilter">
<set-object property="serviceEncoders"
value="service-property:tapestry.url.LinkFactory:serviceEncoders"/>
</construct>
Thanks for catching my bug!
-Steve
Michael Sims wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
