Skip to site navigation (Press enter)

[CONF] Apache Tapestry > Assets

confluence Fri, 03 Sep 2010 15:35:44 -0700

     Assets
    Page edited by             Howard M. Lewis Ship
    
        

                         Changes (33)
                                 
    

            
            ...

            Tapestry will also make files stored _on the classpath_, with your Java class files, visible to the web browser. 
 

            Assets are exposed to your code as instances of the [Asset|../apidocs/org/apache/tapestry5/Asset.html] Asset interface. 

             

            h12. Injecting Assets 

             

            Components learn about assets via injection. The [Inject|#inject.html] Inject annotation allows Assets to be injected into components as read-only properties. The path to the resource is specified using the [Path|../apidocs/org/apache/tapestry5/annotations/Path.html] Path annotation. 

             
{code:java} 

            ...

            Unlike elsewhere in Tapestry, _case matters_. This is because Tapestry is dependenent on the Servlet API and the Java runtime to access the underlying files, and those APIs, unlike Tapestry, are case sensitive. Be aware that some _operating systems_ (such as Windows) are case insenitive, which may mask errors that will be revealed at deployment (if the deployment operating system is case sensitive, such as Linux). 
 

            h12. Assets in Templates 

             
Assets can also be referenced directly in templates. Two binding prefixes exist for this: "asset:" and "context:". The "asset:" prefix can obtain assets from the classpath (the default) or from the web context (by specifying the "context:" domain explicitly): 
 
{code:java} 

            <img src="" class="diff-added-chars"style="background-color: #dfd;">${asset:context:image/tapestry_banner.gif}" alt="Banner"/> 

            {code} 
 

            {info}This is an example of using a _template expansion_ inside an ordinary element (rather than a component).{info} 
 

            Because accessing context assets is so common, the "context:" binding prefix was introduced: 
 
{code:java} 

            <img src="" class="diff-added-chars"style="background-color: #dfd;">${context:image/tapestry_banner.gif}" alt="Banner"/> 

            {code} 
 

            h12. Relative Assets 

             
You can use relative paths with domains (if you omit the prefix): 

            ...

            Since you must omit the prefix, this only makes sense for components packaged in a library for reuse. 
 

            h12. Symbols For Assets 

             

            [Symbols|../../tapestry-ioc/symbols.html] Symbols inside the annotation value are expanded. This allows you to define a symbol and reference it as part of the path. For example, you could contribute a symbol named "skin.root" as "context:/skins/basic" and then reference an asset from within it: 

             
{code:java} 

            ...

            {code} 
 

            {note}The use of the {{$\{...\}}} syntax here is a _symbol expansion_ (because it occurs in an annotation in Java code), rather than a _template expansion_ (which occurs only in Tapestry template files).{note} 
 

            An override of the skin.root symbol would affect all references to the named asset. 
 

            h12. Localization of Assets 

             

            Assets are [localized|#localization.html]; localized; Tapestry will search for a variation of the file appropriate to the effective locale for the request. In the previous example, a German user of the application may see a file named {{edit_de.png}} (if such a file exists). 

             

            h12. New Asset Domains 

             

            If you wish to create new domains for assets, for example to allow assets to be stored on the file system or in a database, you may define a new [AssetFactory|../apidocs/org/apache/tapestry5/services/AssetFactory.html] AssetFactory and contribute it to the AssetSource service configuration. 

             

            h1. Simplified Paths 

            h2. Asset URLs 

             

            Private assets (assets on the classpath) normally have the form: {{/assets/foo/bar/Baz.css}} where {{Baz.css}} is a file inside the {{foo.bar}} Java package. In other words, the package name is converted into a path underneath the virtual folder, {{/assets/}}. 

            Tapestry creates a new URL for assets (whether context or classpath). The URL is of the form {{/assets/}}_application version number_{{/}}_folder_{{/}}_path_. 

             

            You are given some control over this, allowing for shorter paths. The ClasspathAssetAliasManager service has a mapped configuration. The map keys are logical folder names, and the map values are the complete classpath. For example, Tapestry itself makes a contribution similar to the following: 

            * application version number: Defined by symbol {{tapestry.application-version}}, the default value is a random hex number.  

             

            {code:java} 
    public static void contributeClasspathAssetAliasManager( 
            MappedConfiguration<String, String> configuration) 
    { 
        configuration.add("tapestry/5.1", "org/apache/tapestry5"); 
    } 
{code} 

            * folder: Identifies the library containing the asset, or "ctx" for a context asset, or "stack" (used when combining multiple _javascript_ files into a single virtual asset). 

             

            Thus, the generated URLs may say {{/assets/tapestry/5.1/Foo.gif}} but the underlying file will be {{/org/apache/tapestry5/Foo.gif}} (within the classpath). 

            * path: The path below the root package of the library to the specific asset file. 

             

            There are built-in contributions for: 

            h2. Performance Notes 

             

            * tapestry/_version_ 
* scriptaculous/_version_ 
* datepicker/_version_ 
* app/_app-version_ (for assets obtained at or beneath the application package) 
* classpath/_app-version_ (for assets obtained from any otherwise unmapped package) 
Where _version_ is the Tapestry framework version, and _app-version_ is the application version (which will be a random string if not explicitly [configured|#conf.html]). 

            Assets are expected to be entirely static (not changing while the application is deployed). When Tapestry generates a URL for an asset, either on the classpath or from the context, the URL includes a version number. Further, the asset will get a _far future expires header_, which will encourage the client browser to cache the asset. 

             

            If you give your application a version number, it is important to change the version number for each deployment. Assets within the application (whether in the context, or the classpath) will be given a far-future expires header and therefore will be aggresively cached in the client browser. Changing the version number changes the path the browser sees, which forces the browser to load the new and changed version of the asset. 

            In addition, Tapestry will GZIP compress the content of _all_ assets (if the asset is compressable, and the client supports it). 

             

            In addition, context assets will use the URL prefix {{/assets/ctx/}}_app-version_{{/}}. 
 
h1. Securing Assets 
 
Securing assets is an important consideration for any web application. Many assets, such as hibernate configuration files, sit in the classpath and are exposable via the Asset service, which is not desirable. To protect these and other sensitive assets, Tapestry provides the [AssetProtectionDispatcher|../apidocs/org/apache/tapestry5/internal/services/AssetProtectionDispatcher.html]. This dispatcher sits in front of the AssetDispatcher, the service responsible for streaming assets to the client, and watches for Asset requests. When an asset request comes in, the protection dispatcher checks for authorization to view the file against a contributed list of [AssetPathAuthorizer|../apidocs/org/apache/tapestry5/services/AssetPathAuthorizer.html] implementations. Determination of whether the client can view the requested resource is then made based on whether any of the contributed AssetPathAuthorizer implementations explicitly allowed or denied access to the resource. 
 
Tapestry provides two AssetPathAuthorizer implemenations "out of the box" to which users may contribute: [RegexAuthorizer|../apidocs/org/apache/tapestry5/internal/services/RegexAuthorizer.html] and [WhitelistAuthorizer|../apidocs/org/apache/tapestry5/internal/services/WhitelistAuthorizer.html]. RegexAuthorizer uses regular expressions to determine assets which are viewable by the client; any assets that match one of its (contributed) regular expressions are authorized. Anything not matched is passed through to the WhitelistAuthorizer. WhitelistAuthorizer uses an exact-matching whitelist. Anything matching exactly one its contributions is allowed; all other asset requests are denied. The default tapestry configuration contributes nothing to WhitelistAuthorizer (access will be denied to all asset requests passed through to it), and explicitly allows access to css, jpg, jpeg, js, png, and gif files associated with tapestry (tapestry.js, blackbird files, date picker files, etc.). The default contribution also enables access to the css, jpg, jpeg, js, png, and gif files inside any subpackage of the configured app package. The default configuration denies access to all other assets. To enable access to your application's assets, either contribute a custom AssetPathAnalyzer, or contribute appropriate regular _expression_ or exact path contributions to RegexAuthorizer or WhitelistAuthorizer, respectively. See TapestryModule.contribteRegexAuthorizer for examples. 
 
Imagine you wish to allow access to resources outside the app package. Let 'org.example' be your app package and 'org.resources' the package where your assets are located. To allow access to the 'styles.css' file inside 'org.resources' package you need to contribute to WhitelistAuthorizer. 
 
{code:java} 
    public class AppModule 
    {         
        public void contributeWhitelistAuthorizer(final Configuration<String> configuration)  
        { 
            configuration.add("org/resources/styles.css"); 
        } 
    } 
{code} 
 
If you wish to allow access to several resources then a contribution to RegexAuthorizer is a better alternative. 
 
{code:java} 
    public class AppModule 
    {         
        public void contributeRegexAuthorizer(final Configuration<String> configuration)  
        { 
                String pattern = "([^/.]+/)*[^/.]+\\.((css)|(js)|(jpg)|(jpeg)|(png)|(gif))$"; 
 
                configuration.add("^org/resources/" + pattern); 
        } 
    } 
{code} 
 
And finally if you wish to blacklist a path that is allowed by Tapestry you should write your own AssetPathAuthorizer. The following one denies access to all configured paths. Note that [AssetPathAuthorizer.html#order()|../apidocs/org/apache/tapestry5/services/AssetPathAuthorizer.html#order] defines the order in which methods [AssetPathAuthorizer.html#accessAllowed|../apidocs/org/apache/tapestry5/services/AssetPathAuthorizer.html#accessAllowedjava.lang.String] and [AssetPathAuthorizer.html#accessDenied|../apidocs/org/apache/tapestry5/services/AssetPathAuthorizer.html#accessDeniedjava.lang.String] are invoked. In this example the method 'AssetPathAuthorizer#accessDenied' is invoked first. If the current path is to be blacklisted 'AssetPathAuthorizer#accessDenied' returns the value 'true' and 'AssetPathAuthorizer#accessAllowed' is not invoked. That's why 'AssetPathAuthorizer#accessAllowed' returns true. 
 
{code:java} 
    public class BlacklistAuthorizer implements AssetPathAuthorizer  
    { 
 
        private final Collection<String> configuration; 
 
        public DenyAssetPathAuthorizer(final Collection<String> configuration)  
        { 
            this.configuration = configuration; 
        } 
 
        public boolean accessAllowed(final String someResourcePath)  
        { 
            return true; 
        } 
 
        public boolean accessDenied(final String someResourcePath)  
        { 
            return this.configuration.contains(someResourcePath); 
        } 
 
        public List<Order> order()  
        { 
            return Arrays.asList(Order.DENY, Order.ALLOW); 
        } 
    } 
{code} 
 
Then contribute the BlacklistAuthorizer and place it before all other AssetPathAuthorizer. 
 
{code:java} 
    public class AppModule 
    { 
 
        public static void bind(final ServiceBinder binder)  
        { 
            binder.bind(AssetPathAuthorizer.class, BlacklistAuthorizer.class).withId("BlacklistAuthorizer"); 
        } 
 
        public void contributeBlacklistAuthorizer(final Configuration<String> configuration)  
        { 
            configuration.add("org/example/pages/secret.jpg"); 
        } 
 
        public static void contributeAssetProtectionDispatcher( 
                OrderedConfiguration<AssetPathAuthorizer> configuration, 
 
                @InjectService("BlacklistAuthorizer") AssetPathAuthorizer blacklist) 
        { 
                configuration.add("blacklist",blacklist,"before:*"); 
        } 
    } 
{code} 
 
h1. Performance Notes 
 
Assets are expected to be entirely static (not changing while the application is deployed). When Tapestry generates a URL for an asset, either on the classpath or from the context, the URL includes a version number (as discussed in the previous section). Further, the asset will get a _far future expires header_, which will encourage the client browser to cache the asset. 
 
In addition, Tapestry will [GZIP compress|#compress.html] the content of _all_ assets (if the asset is compressable, and the client supports it). 

            You should have an explicit application version number for any production application.  Client browsers will aggressively cache downloaded assets; they will usually not even send a request to see if the asset has changed once the asset is downloaded the first time. Because of this is is very important that each new deployment of your application get a new version number: this will force existing clients to re-download all files. 

        
                            Full Content
                    
        Assets

Assets are any kind of file that may be downloaded to a client web browser in addition to the dynamically generated HTML.

Assets are most often images, stylesheets, and _javascript_ libraries.

Normal assets are stored in the web application's context folder ... stored inside the web application WAR file in the ordinary way.

Tapestry will also make files stored on the classpath, with your Java class files, visible to the web browser.

Assets are exposed to your code as instances of the Asset interface.

Injecting Assets

Components learn about assets via injection. The Inject annotation allows Assets to be injected into components as read-only properties. The path to the resource is specified using the Path annotation.


  @Inject
  @Path("context:images/tapestry_banner.gif")
  private Asset banner;


Assets are located within domains; these domains are identified by the prefix on the Path annotation's value.

If the prefix is omitted, the value will be interpreted as a path relative to the Java class file itself, within the "classpath:" domain. This is often used when creating component libraries, where the assets used by the components are packaged in the JAR with the components themselves.

Unlike elsewhere in Tapestry, case matters. This is because Tapestry is dependenent on the Servlet API and the Java runtime to access the underlying files, and those APIs, unlike Tapestry, are case sensitive. Be aware that some operating systems (such as Windows) are case insenitive, which may mask errors that will be revealed at deployment (if the deployment operating system is case sensitive, such as Linux).

Assets in Templates

Assets can also be referenced directly in templates. Two binding prefixes exist for this: "asset:" and "context:". The "asset:" prefix can obtain assets from the classpath (the default) or from the web context (by specifying the "context:" domain explicitly):


  <img src="" class="code-quote">"${asset:context:image/tapestry_banner.gif}" alt="Banner"/>



This is an example of using a template expansion inside an ordinary element (rather than a component).

Because accessing context assets is so common, the "context:" binding prefix was introduced:


  <img src="" class="code-quote">"${context:image/tapestry_banner.gif}" alt="Banner"/>



Relative Assets

You can use relative paths with domains (if you omit the prefix):


  @Inject
  @Path("../edit.png")
  private Asset icon;



Since you must omit the prefix, this only makes sense for components packaged in a library for reuse.

Symbols For Assets

Symbols inside the annotation value are expanded. This allows you to define a symbol and reference it as part of the path. For example, you could contribute a symbol named "skin.root" as "context:skins/basic" and then reference an asset from within it:


  @Inject
  @Path("${skin.root}/style.css")
  private Asset style;



The use of the ${...} syntax here is a symbol expansion (because it occurs in an annotation in Java code), rather than a template expansion (which occurs only in Tapestry template files).

An override of the skin.root symbol would affect all references to the named asset.

Localization of Assets

Assets are localized; Tapestry will search for a variation of the file appropriate to the effective locale for the request. In the previous example, a German user of the application may see a file named edit_de.png (if such a file exists).

New Asset Domains

If you wish to create new domains for assets, for example to allow assets to be stored on the file system or in a database, you may define a new AssetFactory and contribute it to the AssetSource service configuration.

Asset URLs

Tapestry creates a new URL for assets (whether context or classpath). The URL is of the form /assets/application version number/folder/path.


	application version number: Defined by symbol tapestry.application-version, the default value is a random hex number.




	folder: Identifies the library containing the asset, or "ctx" for a context asset, or "stack" (used when combining multiple _javascript_ files into a single virtual asset).




	path: The path below the root package of the library to the specific asset file.



Performance Notes

Assets are expected to be entirely static (not changing while the application is deployed). When Tapestry generates a URL for an asset, either on the classpath or from the context, the URL includes a version number. Further, the asset will get a far future expires header, which will encourage the client browser to cache the asset.

In addition, Tapestry will GZIP compress the content of all assets (if the asset is compressable, and the client supports it).

You should have an explicit application version number for any production application.  Client browsers will aggressively cache downloaded assets; they will usually not even send a request to see if the asset has changed once the asset is downloaded the first time. Because of this is is very important that each new deployment of your application get a new version number: this will force existing clients to re-download all files.
    
        
        
            Change Notification Preferences
        
        View Online
        |
        View Changes
 ...
 Tapestry will also make files stored _on the classpath_, with your Java class files, visible to the web browser.
 Assets are exposed to your code as instances of the [Asset|../apidocs/org/apache/tapestry5/Asset.html] Asset interface.
 h12. Injecting Assets
 Components learn about assets via injection. The [Inject|#inject.html] Inject annotation allows Assets to be injected into components as read-only properties. The path to the resource is specified using the [Path|../apidocs/org/apache/tapestry5/annotations/Path.html] Path annotation.
 {code:java}
 ...
 Unlike elsewhere in Tapestry, _case matters_. This is because Tapestry is dependenent on the Servlet API and the Java runtime to access the underlying files, and those APIs, unlike Tapestry, are case sensitive. Be aware that some _operating systems_ (such as Windows) are case insenitive, which may mask errors that will be revealed at deployment (if the deployment operating system is case sensitive, such as Linux).
 h12. Assets in Templates
 Assets can also be referenced directly in templates. Two binding prefixes exist for this: "asset:" and "context:". The "asset:" prefix can obtain assets from the classpath (the default) or from the web context (by specifying the "context:" domain explicitly): 
 
{code:java}
 <img src="" class="diff-added-chars"style="background-color: #dfd;">${asset:context:image/tapestry_banner.gif}" alt="Banner"/>
 {code}
+{info}This is an example of using a _template expansion_ inside an ordinary element (rather than a component).{info}
 Because accessing context assets is so common, the "context:" binding prefix was introduced: 
 
{code:java}
 <img src="" class="diff-added-chars"style="background-color: #dfd;">${context:image/tapestry_banner.gif}" alt="Banner"/>
 {code}
 h12. Relative Assets
 You can use relative paths with domains (if you omit the prefix):
 ...
 Since you must omit the prefix, this only makes sense for components packaged in a library for reuse.
 h12. Symbols For Assets
 [Symbols|../../tapestry-ioc/symbols.html] Symbols inside the annotation value are expanded. This allows you to define a symbol and reference it as part of the path. For example, you could contribute a symbol named "skin.root" as "context:/skins/basic" and then reference an asset from within it:
 {code:java}
 ...
 {code}
+{note}The use of the {{$\{...\}}} syntax here is a _symbol expansion_ (because it occurs in an annotation in Java code), rather than a _template expansion_ (which occurs only in Tapestry template files).{note}
 An override of the skin.root symbol would affect all references to the named asset.
 h12. Localization of Assets
 Assets are [localized|#localization.html]; localized; Tapestry will search for a variation of the file appropriate to the effective locale for the request. In the previous example, a German user of the application may see a file named {{edit_de.png}} (if such a file exists).
 h12. New Asset Domains
 If you wish to create new domains for assets, for example to allow assets to be stored on the file system or in a database, you may define a new [AssetFactory|../apidocs/org/apache/tapestry5/services/AssetFactory.html] AssetFactory and contribute it to the AssetSource service configuration.
-h1. Simplified Paths
+h2. Asset URLs
-Private assets (assets on the classpath) normally have the form: {{/assets/foo/bar/Baz.css}} where {{Baz.css}} is a file inside the {{foo.bar}} Java package. In other words, the package name is converted into a path underneath the virtual folder, {{/assets/}}.
+Tapestry creates a new URL for assets (whether context or classpath). The URL is of the form {{/assets/}}_application version number_{{/}}_folder_{{/}}_path_.
-You are given some control over this, allowing for shorter paths. The ClasspathAssetAliasManager service has a mapped configuration. The map keys are logical folder names, and the map values are the complete classpath. For example, Tapestry itself makes a contribution similar to the following:
+* application version number: Defined by symbol {{tapestry.application-version}}, the default value is a random hex number.
-{code:java} 
    public static void contributeClasspathAssetAliasManager( 
            MappedConfiguration<String, String> configuration) 
    { 
        configuration.add("tapestry/5.1", "org/apache/tapestry5"); 
    } 
{code}
+* folder: Identifies the library containing the asset, or "ctx" for a context asset, or "stack" (used when combining multiple _javascript_ files into a single virtual asset).
-Thus, the generated URLs may say {{/assets/tapestry/5.1/Foo.gif}} but the underlying file will be {{/org/apache/tapestry5/Foo.gif}} (within the classpath).
+* path: The path below the root package of the library to the specific asset file.
-There are built-in contributions for:
+h2. Performance Notes
-* tapestry/_version_ 
* scriptaculous/_version_ 
* datepicker/_version_ 
* app/_app-version_ (for assets obtained at or beneath the application package) 
* classpath/_app-version_ (for assets obtained from any otherwise unmapped package) 
Where _version_ is the Tapestry framework version, and _app-version_ is the application version (which will be a random string if not explicitly [configured|#conf.html]).
+Assets are expected to be entirely static (not changing while the application is deployed). When Tapestry generates a URL for an asset, either on the classpath or from the context, the URL includes a version number. Further, the asset will get a _far future expires header_, which will encourage the client browser to cache the asset.
-If you give your application a version number, it is important to change the version number for each deployment. Assets within the application (whether in the context, or the classpath) will be given a far-future expires header and therefore will be aggresively cached in the client browser. Changing the version number changes the path the browser sees, which forces the browser to load the new and changed version of the asset.
+In addition, Tapestry will GZIP compress the content of _all_ assets (if the asset is compressable, and the client supports it).
-In addition, context assets will use the URL prefix {{/assets/ctx/}}_app-version_{{/}}. 
 
h1. Securing Assets 
 
Securing assets is an important consideration for any web application. Many assets, such as hibernate configuration files, sit in the classpath and are exposable via the Asset service, which is not desirable. To protect these and other sensitive assets, Tapestry provides the [AssetProtectionDispatcher|../apidocs/org/apache/tapestry5/internal/services/AssetProtectionDispatcher.html]. This dispatcher sits in front of the AssetDispatcher, the service responsible for streaming assets to the client, and watches for Asset requests. When an asset request comes in, the protection dispatcher checks for authorization to view the file against a contributed list of [AssetPathAuthorizer|../apidocs/org/apache/tapestry5/services/AssetPathAuthorizer.html] implementations. Determination of whether the client can view the requested resource is then made based on whether any of the contributed AssetPathAuthorizer implementations explicitly allowed or denied access to the resource. 
 
Tapestry provides two AssetPathAuthorizer implemenations "out of the box" to which users may contribute: [RegexAuthorizer|../apidocs/org/apache/tapestry5/internal/services/RegexAuthorizer.html] and [WhitelistAuthorizer|../apidocs/org/apache/tapestry5/internal/services/WhitelistAuthorizer.html]. RegexAuthorizer uses regular expressions to determine assets which are viewable by the client; any assets that match one of its (contributed) regular expressions are authorized. Anything not matched is passed through to the WhitelistAuthorizer. WhitelistAuthorizer uses an exact-matching whitelist. Anything matching exactly one its contributions is allowed; all other asset requests are denied. The default tapestry configuration contributes nothing to WhitelistAuthorizer (access will be denied to all asset requests passed through to it), and explicitly allows access to css, jpg, jpeg, js, png, and gif files associated with tapestry (tapestry.js, blackbird files, date picker files, etc.). The default contribution also enables access to the css, jpg, jpeg, js, png, and gif files inside any subpackage of the configured app package. The default configuration denies access to all other assets. To enable access to your application's assets, either contribute a custom AssetPathAnalyzer, or contribute appropriate regular _expression_ or exact path contributions to RegexAuthorizer or WhitelistAuthorizer, respectively. See TapestryModule.contribteRegexAuthorizer for examples. 
 
Imagine you wish to allow access to resources outside the app package. Let 'org.example' be your app package and 'org.resources' the package where your assets are located. To allow access to the 'styles.css' file inside 'org.resources' package you need to contribute to WhitelistAuthorizer. 
 
{code:java} 
    public class AppModule 
    {         
        public void contributeWhitelistAuthorizer(final Configuration<String> configuration)  
        { 
            configuration.add("org/resources/styles.css"); 
        } 
    } 
{code} 
 
If you wish to allow access to several resources then a contribution to RegexAuthorizer is a better alternative. 
 
{code:java} 
    public class AppModule 
    {         
        public void contributeRegexAuthorizer(final Configuration<String> configuration)  
        { 
                String pattern = "([^/.]+/)*[^/.]+\\.((css)|(js)|(jpg)|(jpeg)|(png)|(gif))$"; 
 
                configuration.add("^org/resources/" + pattern); 
        } 
    } 
{code} 
 
And finally if you wish to blacklist a path that is allowed by Tapestry you should write your own AssetPathAuthorizer. The following one denies access to all configured paths. Note that [AssetPathAuthorizer.html#order()|../apidocs/org/apache/tapestry5/services/AssetPathAuthorizer.html#order] defines the order in which methods [AssetPathAuthorizer.html#accessAllowed|../apidocs/org/apache/tapestry5/services/AssetPathAuthorizer.html#accessAllowedjava.lang.String] and [AssetPathAuthorizer.html#accessDenied|../apidocs/org/apache/tapestry5/services/AssetPathAuthorizer.html#accessDeniedjava.lang.String] are invoked. In this example the method 'AssetPathAuthorizer#accessDenied' is invoked first. If the current path is to be blacklisted 'AssetPathAuthorizer#accessDenied' returns the value 'true' and 'AssetPathAuthorizer#accessAllowed' is not invoked. That's why 'AssetPathAuthorizer#accessAllowed' returns true. 
 
{code:java} 
    public class BlacklistAuthorizer implements AssetPathAuthorizer  
    { 
 
        private final Collection<String> configuration; 
 
        public DenyAssetPathAuthorizer(final Collection<String> configuration)  
        { 
            this.configuration = configuration; 
        } 
 
        public boolean accessAllowed(final String someResourcePath)  
        { 
            return true; 
        } 
 
        public boolean accessDenied(final String someResourcePath)  
        { 
            return this.configuration.contains(someResourcePath); 
        } 
 
        public List<Order> order()  
        { 
            return Arrays.asList(Order.DENY, Order.ALLOW); 
        } 
    } 
{code} 
 
Then contribute the BlacklistAuthorizer and place it before all other AssetPathAuthorizer. 
 
{code:java} 
    public class AppModule 
    { 
 
        public static void bind(final ServiceBinder binder)  
        { 
            binder.bind(AssetPathAuthorizer.class, BlacklistAuthorizer.class).withId("BlacklistAuthorizer"); 
        } 
 
        public void contributeBlacklistAuthorizer(final Configuration<String> configuration)  
        { 
            configuration.add("org/example/pages/secret.jpg"); 
        } 
 
        public static void contributeAssetProtectionDispatcher( 
                OrderedConfiguration<AssetPathAuthorizer> configuration, 
 
                @InjectService("BlacklistAuthorizer") AssetPathAuthorizer blacklist) 
        { 
                configuration.add("blacklist",blacklist,"before:*"); 
        } 
    } 
{code} 
 
h1. Performance Notes 
 
Assets are expected to be entirely static (not changing while the application is deployed). When Tapestry generates a URL for an asset, either on the classpath or from the context, the URL includes a version number (as discussed in the previous section). Further, the asset will get a _far future expires header_, which will encourage the client browser to cache the asset. 
 
In addition, Tapestry will [GZIP compress|#compress.html] the content of _all_ assets (if the asset is compressable, and the client supports it).
+You should have an explicit application version number for any production application.  Client browsers will aggressively cache downloaded assets; they will usually not even send a request to see if the asset has changed once the asset is downloaded the first time. Because of this is is very important that each new deployment of your application get a new version number: this will force existing clients to re-download all files.
 This is an example of using a template expansion inside an ordinary element (rather than a component).
 The use of the ${...} syntax here is a symbol expansion (because it occurs in an annotation in Java code), rather than a template expansion (which occurs only in Tapestry template files).