click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Malcolm Edgar (JIRA)" <>
Subject [jira] Commented: (CLK-564) Add ResourceService for serving static resources
Date Tue, 14 Jul 2009 13:54:15 GMT


Malcolm Edgar commented on CLK-564:

OK - I have checked in some revisions to this stuff. The check in does not really address
your issues, but is more of a work in progress.

I agree on the point we have two types of resources in click:
 * static resources: images, CSS and JS files
 * dynamic resources: mainly JS but also potentially CSS files

I have been avoiding using a Filter as I have wanted to keep the configuration simple, but
I think in reality works well if we try and address /click/* resources. If we want to address
other resources and dynamic resources then I agree a filter can be better because of the simpler

With the CssStyle and JsInclude you are already using the TemplateService to dynamically render
the content. I am not sure what the value add here would be.

With the lazy startup, I have a bias towards eager loading at startup, but maybe the compromise
would be to eager load when in production/profile mode and lazy load otherwise.

> Add ResourceService for serving static resources
> ------------------------------------------------
>                 Key: CLK-564
>                 URL:
>             Project: Click
>          Issue Type: New Feature
>          Components: core
>    Affects Versions: 2.0.2
>            Reporter: Malcolm Edgar
>            Assignee: Malcolm Edgar
>             Fix For:  2.1.0 RC2
> 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