click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bob Schellink (JIRA)" <>
Subject [jira] Commented: (CLK-564) Add ResourceService for serving static resources
Date Tue, 30 Jun 2009 23:38:49 GMT


Bob Schellink commented on CLK-564:

I assume this feature will check if getRealPath returns null and if it does, use ResourceService
to serve static resources. One thing I've noticed from GAE is that getRealPath does return
a value, but trying to deploy the files leads to exceptions. Perhaps a try/catch is necessary
to cater for GAE.

Interestingly I've just tested the new Servlet3.0 spec as provided by Glassfish 3.0 preview.
As mentioned before Servlet 3.0 supports serving resources from the web app folder as well
as jars under WEB-INF/lib. As long as the resources in jars are provided under the folder
META-INF/resources, they can be accessed. I made a small change locally and copied all resources
from META-INF/web to META-INF/resources. Then I turned off Click's deployment mechanism so
no resources were deployed. From the URL I could still access all Click's resources that were
under META-INF/resources. We should probably look at moving our resources from META-INF/web
to META-INF/resources to align with Servlet 3.0 spec.

> Add ResourceService for serving static resources
> ------------------------------------------------
>                 Key: CLK-564
>                 URL:
>             Project: Click
>          Issue Type: New Feature
>          Components: core
>    Affects Versions: 2.1.0
>            Reporter: Malcolm Edgar
> The Click static resource deployment strategy of writing *.htm, *.css and image files
to the web application /click/ directory does not work on all application servers. In particular
WebLogic and WebSphere have security restrictions which prevent this from occuring. In these
scenarios users are have to deploy these applications to the WAR file at build time.  Google
GAE also does not support this deployment mode.
> A solution to this problem is to use the ClickServlet to serve these resources. By adding
an additional web.xml mapping:
> 	<servlet-mapping>
> 		<servlet-name>ClickServlet</servlet-name>
> 		<url-pattern>/click/*</url-pattern>
> 	</servlet-mapping>
> The ClickServlet could use a ResourceService interface obtained from the ConfigService
which returns the resource data. A default ClickResourceService would be provided which loads
all the resources at application initialization time. This service would scan all the JAR
files for resources in META-INF/web as is currently done in XmlConfigService and would cache
them in memory. The service would also scan all the resources under the WAR /click/ directory.
These resources would override any defined in the application JAR files.
> This could be a good feature for 2.1.0, we should possibly delay the 2.1.0 RC release
to include this feature.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message