[
https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730810#action_12730810
]
Bob Schellink commented on CLK-564:
-----------------------------------
> You have static resources in a JAR which you want served in a GAE or
> restricted environment.
Yep in the case of ClickClick the url-pattern mapping would be: /clickclick/*.
> Should we load any resources excluding *.htm ?
I'm leaning towards lazy loading using a ConcurrentHashMap. Startup is faster
and the penalty is paid only by the first request, after which the resource is
served from the cache.
> Should we consider using the template service to render *.css and *.js files,
> adding the usual things to the model $request and $context
I might have explained the *.css and *.js template thing incorrectly. I think
static *.css and *.js files (JsImport and CssImport) should be served and
cached on the browser. Rendering them through the TemplateService wouldn't add
much value as they will be cached in the browser after the first request. In
dynamic Pages this creates a problem because the associated JS or CSS template
isn't rendered together with the page.
What I meant with files ending with *.css and *.js is the scenario where these
files are either a CssStyle or JsInclude. These files are really Velocity
templates and not static resources and will be included in the Page template
markup. For every request these resources will be rendered and included in the
server response. One could argue that these files should be named
'xyz.css.htm', however the IDE won't recognize them as CSS or JS which is why I
normally just keep their extension as is.
The problem is that the dynamic CSS and JS files (CssStyle and JsInclude)
should not be cached by ResourceService since they are already cached by
Velocity. This is my main reason for using lazy loading. Since these resources
aren't static, they won't be requested by the browser and we never have to
serve them directly.
What do you think of using a Filter instead of serving resources through
ClickServlet? This might complicate matters though but it could make the
mapping a bit easier because if we cannot handle the request we pass it further
down to the default servlet:
<filter-mapping>
<filter-name>resourceFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
One advantage here is that the mapping can be generic and any Click JAR would
be served. Using ClickServlet we will need to map each path separately e.g:
<servlet-mapping>
<servlet-name>ClickServlet</servlet-name>
<url-pattern>/click/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>ClickServlet</servlet-name>
<url-pattern>/clickclick/*</url-pattern>
</servlet-mapping>
> Add ResourceService for serving static resources
> ------------------------------------------------
>
> Key: CLK-564
> URL: https://issues.apache.org/jira/browse/CLK-564
> 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.
