We have already seen how these attributes can be specified in a JNLP file. But without proper
server-side support, they would be ignored or—even worse—cause a blocking error.
At this point, it could be useful to distinguish between physical resources (concrete files) and
logical ones (that is, requests that clients solicit to the server, as follows) :
• Logical Resource . An abstract, sometimes vague resource definition, issued by the
client. The server job is to transform a client request in a file to be sent back to the client.
If there were no attributes to be specified for a resource, there would be no difference
between logical and physical resources, and a simple Web server would suffice.
• Physical Resource . A physical file present on the server repository. Such a file may have
attached a number of attribute values that define its exact version, the lists of supported
OS, hardware architectures and locales, whereas an abstract resource may indicate them
name=”file.jar”, version-id=”1.2+”, OS=”Windows”
is a logical resource, expressed for instance by the following client HTTP request:
that can be matched by the file (physical resource):
Note that the server is able to associate some attributes values to a physical file in a given
directory (presumably in a given WAR file). The way this association is created depends on the
server, and it is the focus of the next section.
Specifying Attribute Values for Server Files
Sun proposed two mechanisms for defining attribute values for resource files to be managed by
servers. One is a simple naming convention for files. All the attributes are encoded in the file-
name, as follows.
There are four possible attributes to be specified:
• Locales. Appending many times as needed the “__L” + locale strings to the resource file-
•Versions. Using (one time only per resource) the “ __V ”+ version id to the resource file-
•Os. Appending the “ __O ”+ os names to the resource filename.
•Architectures. Appending the “ __A ”+ architecture names to the resource filename.