Page History

...

Assets are most commonly stored in can be in one of three places within a Tapestry app:

1. In the web application's context folder

...

1. , stored inside the web application WAR file in the usual JEE fashion. In a project following Maven's directory layout conventions, this would be src/main/webapp or a subdirectory of it (but not under src/main/webapp/WEB-INF)

...

1. .
2. For Tapestry 5.4 and later: under META-INF, with JavaScript modules under META-INF/modules and other assets under META-INF/assets. This would be src/main/resources/META-INF/modules and src/main/resources/META-INF/assets if following Maven directory conventions.
3. On

...

1. the classpath, with your Java class files

...

1. . This is deprecated in Tapestry 5.4 and later (with a warning). If following Maven directory conventions, this would correspond to a package-named subdirectory under src/main/resources/, such as src/main/resources/com/example/myapp/pages).

Referencing Assets from Templates

For referencing assets from templates, two binding prefixes exist: "context:" and "asset

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

Assets in Templates

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

<img src="${asset:context:imageimages/tapestry_banner.gif}" alt="Banner"/>

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

...

...

Note that in older code you may occasionally see ${asset:context:...}. That means the same thing as ${context:...}.

Assets in Component Classes

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

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

...

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

META-INF/assets

Support for storing assets under META-INF/assets was added in Tapestry 5.4.

For security reasons (detailed below), it is best to have the assets that will be exposed to the client segregated from compiled Java classes. For that reason, classpath assets must be stored in META-INF/assets or a subfolder.

For an application asset, the assets can be stored directly in META-INF/assets.

For a library asset, Tapestry uses the library's name (from its LibraryMapping) (such as "core" for the Tapestry core library);  The library name becomes a folder under META-INF/assets; for example, Tapestry stores its component-related assets under META-INF/assets/core.

Classpath Assets 

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.

...

In Tapestry 5.5, support for classpath assets not under META-INF/assets will may be removed.

...

Support for storing assets under META-INF/assets was added in Tapestry 5.4.

For security reasons (detailed below), it is best to have the assets that will be exposed to the client segregated from compiled Java classes. For that reason, classpath assets must be stored in META-INF/assets or a subfolder.

For an application asset, the assets can be stored directly in META-INF/assets.

For a library asset, Tapestry uses the library's name (from its LibraryMapping) (such as "core" for the Tapestry core library);  The library name becomes a folder under META-INF/assets; for example, Tapestry stores its component-related assets under META-INF/assets/core.

Relative Assets

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

...

It is frequently the case that CSS files will include links to other files, such as background images, using the url() value syntax. Under 5.4, the URL for the CSS file and the targeted file would be broken, due to the inclusions of the CSS file's content hash fingerprint. To fix this, Tapestry parses CSS files, locates the url() directives, and rewrites the URLs to be absolute (including the targeted file's content hash fingerprint).

...

...

Because Tapestry directly exposes files on the classpath to the clients, some thought has gone into ensuring that malicious clients are not able to download assets that should not be visible to them.

...

Minimizing Assets

...