Security
When serving packaged resources from a JAR, extra care must be taken not to make Java class files or other sensitive information accessible by URL. In desktop Java applications, resource files are often stored in a sub-package called "resources" underneath the Java implementation classes that use the resource files. The same strategy is also appropriate for packaged resources in JavaServer Faces component libraries, and has the security benefit of ensuring that only the resource files are accessible by URL. All other contents of the JAR file, including Java implementation classes, are not URL accessible because no Java classes exist in either the "resources" package or in any sub-package of "resources."

Weblets Protocol
Having covered how to configure Weblets, it's time to look at how we can reference resources defined by the Weblet in our renderer. The syntax, defined by the Weblet contract, for returning a proper URL to the JSF page is as follows:

<prefix><weblet name><resource>

The prefix indicates that this is a Weblet-managed resource, and this is followed by the Weblet name and the resource requested.

Previously, in our Renderer class, we passed the URL /myresources/myScript.js as an argument to the ViewHandler's getResourceURL() method. In the code sample below, we amend this to use the Weblet protocol instead.

ViewHandler handler = context.getApplication().getViewHandler();
String resourceURL = handler.getResourceURL(context, "weblet://org.myapp.html/myScript.js");
out.startElement("script", null);
out.writeAttribute("type", "text/javascript", null);
out.writeAttribute("src", resourceURL, null);
out.endElement("script");

The Weblet protocol-like syntax is convenient and easy to understand. The syntax starts with weblet://, followed by the Weblet name, e.g., org.myapp.html, and finally the path info or resource file, e.g., /myScript.js. Notice that neither the URL mapping nor the version number are included in the Weblet resource syntax. The Weblet URL mapping and version number are used by the WebletsViewHandler to create a resource URL that the Weblet will service.

When the component writer is not using Weblets, he would not be using the weblet:// resource path syntax and would distribute a separate installables zip. When the component writer moves to Weblets, he would start using weblet:// resource path syntax in the Renderer, and include the resources in the JAR. There is no benefit to using a mixture of these approaches for resources in the same version of the same component library.

Using Weblets in a JSF Application
In order to simplify setup for the application developer, component writers should select a default URL mapping for their component libraries. There is no need for the application developer to add any Weblet-specific configuration to the web.xml file, since the WebletsPhaseListener will be invoked automatically to service incoming requests for Weblet-managed resources.

Summary
As a new open source project, Weblets has tremendous possibilities to provide a defacto generic and configurable resource loading facility for Web clients and the JSF component community. The key differentiators are simplified packaging of JSF components and their resources, and a minimized overhead of installing and setting up JSF component libraries for a particular Web application project.

This article has explored a new way of packaging resources with JSF components. You should now be able to leverage Weblets in your own component library by including a suitable weblets-config.xml file and using the weblet:// protocol-style syntax to reference Weblet-managed resources.

In our next article in this series of building "Rich Internet Components with JavaServer Faces," we are going to look at how we can design JSF components using AJAX and Weblets.

• AjaxWorld Special: Creating AJAX and Rich Internet Components with JSF
• AJAX & J2EE Expert and Author Jonas Jacobi Joins "Real-World AJAX" Conference Faculty