Maybe I am getting pedantic as I was thinking in terms of speed of
operation for a server that's getting hammered with thousands of hits
per hour.

It's quicker to test the first few chars of a URL string for a match
with 'startsWith' than it is to iterate through to almost the end of
each URL string to see if it 'contains' a substring. Any URL will fail
to match on comparison of the first character if they don't have a 'w'
at the beginning which makes startsWith a 'fast fail' test for most URLs
it processes.

I think that's probably why the Servlet Spec chooses to do filter and
servlet path matching via a 'starts with' strategy without support for
wildcards except at the very end of a pattern.

Many of the URLs requested are very long and I try to avoid string
parsing of lots of thousands of long strings wherever I can - there's
already enough of that going on without adding to the work load.

>-----Original Message-----
>From: Martin Grigorov [mailto:[email protected]]
>Sent: Tuesday, 17 January 2012 7:08 PM
>To: [email protected]
>Subject: Re: Controlling URL of static cacheable resources
>
>Hi Chris,
>
>With IResourceCachingStrategy you can pre/suf-fix the resource name
with
>"my.namespace.static", for example.
>This way your filter will be able to recognize it. It is the same as
adding
>the /static/ segment. Just at different place.
>
>On Mon, Jan 16, 2012 at 10:49 PM, Chris Colman
><[email protected]
>> wrote:
>
>> ** **
>>
>> I'm trying to make static resources have a distinguishable part of
their
>> URL near the beginning of the URL to enable easy configuration of
third
>> party filters that need to ignore requests for static resources and
just
>> proceed along the filter chain.****
>>
>> ** **
>>
>> I've looked up the operation of
>>
>org.apache.wicket.request.resource.caching.IResourceCachingStrategy#dec
orat
>eUrl
>> but it appears that it only has the ability to make changes near the
end
>of
>> the resource URL after all the major segments of the URL have already
>been
>> set ie., after this part****
>>
>> ** **
>>
>> /wicket/resource/org.apache.wicket.... rest of pathname.ClassName****
>>
>> ** **
>>
>> What I am trying to do is get all static resources to end up with a
>> distinguishable URL that starts off something like:****
>>
>> ** **
>>
>> /wicket/resource/static/pathname.ClassName****
>>
>> ** **
>>
>> so I can configure a filter to ignore /wicket/resource/static/*****
>>
>> ** **
>>
>> In BasicResourceReferenceHandler.mapHandler() perhaps after adding
the
>> resource identifier segment:****
>>
>> ** **
>>
>> segments.add(getContext().getResourceIdentifier());****
>>
>> ** **
>>
>> it could append an extra segment for static resources:****
>>
>> ** **
>>
>> final IResource resource = reference.getResource();****
>>
>> ** **
>>
>> // if static resource****
>>
>> if (resource instanceof IStaticCacheableResource)****
>>
>> {****
>>
>> segments.add("static");****
>>
>> }****
>>
>> ** **
>>
>> And so end up with /wicket/resource/static/org.apache.wicket ...****
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> I also observed that Wicketstuff resources don't use the /wicket
>> namespace prefix. They just start out at ****
>>
>> ** **
>>
>> /resources/org.name.project.MyClass.script.js****
>>
>> ** **
>>
>> So they'd need a separate ignore entry in the filter.****
>>
>> ** **
>>
>> ** **
>>
>> Yours sincerely,****
>>
>> ** **
>>
>> Chris Colman****
>>
>>  ****
>>
>> Pagebloom Team Leader,****
>>
>> Step Ahead Software
>>
>> ****
>>
>> pagebloom - your business & your website growing together****
>>
>> ** **
>>
>> **Sydney**: (+61 2) 9656 1278     ****Canberra****: (+61 2) 6100 2120
>> ****
>>
>> Email: [email protected] <//[email protected]>****
>>
>> Website:****
>>
>> http://www.pagebloom.com****
>>
>> http://develop.stepaheadsoftware.com****
>>
>>  ****
>>
>> ** **
>>
>
>
>
>--
>Martin Grigorov
>jWeekend
>Training, Consulting, Development
>http://jWeekend.com <http://jweekend.com/>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to