You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@click.apache.org by "Malcolm Edgar (JIRA)" <ji...@apache.org> on 2009/06/30 14:52:47 UTC
[jira] Created: (CLK-564) Add ResourceService for serving static
resources
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.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.
[jira] Issue Comment Edited: (CLK-564) Add ResourceService for
serving static resources
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12774278#action_12774278 ]
Bob Schellink edited comment on CLK-564 at 1/18/10 11:17 AM:
-------------------------------------------------------------
Hi Malcolm,
I've checked in a change to the ClickResourceService to serve resources lazily. This has some advantages over eager loading:
- resources won't be loaded if they are not requested. This resolves the issue with eager loading where all resources from jars are loaded, even if some of those resources aren't valid static resources, for example Velocity templates with extensions other than .htm.
- removed all duplicate code shared with XmlConfigService
- with lazy loading it was easy to add the ability to only cache resources in production modes
The only feature still outstanding is how to handle the case where Velocity attempts to render a template contained under META-INF/resources. Currently the VelocityTemplateService caters for two built in templates (error.htm and not-found.htm), but won't handle custom templates. I suppose we can cross that bridge when we get there.
was (Author: sabob):
Hi Malcolm,
I've checked in a change to the ClickResourceService to serve resources lazily. This has some advantages over eager loading:
- resources won't be loaded if they are not requested. This resolves the issue with eager loading where all resources from jars are loaded, even if some of those resources aren't valid static resources, for example Velocity templates with extensions other than .htm.
- removed all duplicate code shared with XmlConfigService
- with lazy loading it was easy to add the ability to only cache resources in production modes
The only feature still outstanding is how to handle the case where Velocity attempts to render a template contained under META-INF/resources. Currently the VelocityTemplateService caters for two built in templates, but won't handle custom templates. I suppose we can cross that bridge when we get there.
> 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.1.0 RC1
> Reporter: Malcolm Edgar
> Assignee: Malcolm Edgar
> Fix For: 2.1.0
>
> Attachments: report_1.html, report_2.html, report_3.html
>
>
> 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.
[jira] Commented: (CLK-564) Add ResourceService for serving static
resources
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12728923#action_12728923 ]
Bob Schellink commented on CLK-564:
-----------------------------------
Another useful feature of a build time solution is we can compare the deployed file to the jar'ed file (using MD5 hashing for example) and print a message if a new version of the file is available from the jar. Users can then remove the deployed file and let Click deploy the new version, or if they customized the deployed file, perform a merge.
> 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.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.
[jira] Commented: (CLK-564) Add ResourceService for serving static
resources
Posted by "Malcolm Edgar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732260#action_12732260 ]
Malcolm Edgar commented on CLK-564:
-----------------------------------
Very happy to have this handle just static content, as I have my doubts about this being used for dynamic content.
Also happy to have a documented JAR instead of adding a new source tree.
> 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
>
> Attachments: report_1.html, report_2.html, report_3.html
>
>
> 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.
[jira] Commented: (CLK-564) Add ResourceService for serving static
resources
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12728567#action_12728567 ]
Bob Schellink commented on CLK-564:
-----------------------------------
Great work on the implementation Malcolm.
Some comments:
- Testing Click examples on Tomcat and setting the context.xml property, unpackWAR="false", gives error when accessing the ExceptionDemo. Velocity complains that it cannot find error.htm. Problem is that error.htm should be looked up from "META-INF/resources/click/error.htm". One solution could be to enhance Velocity/FreemarkerTemplateService with the following:
public void renderTemplate(Page page, Map model, Writer writer) throws Exception {
...
String templatePath = page.getTemplate();
boolean canDeploy = canDeploy();
if (!canDeploy) {
templatePath = "META-INF/web" + templatePath;
}
...
- Currently the solution only caters for resources under the "/click/" folder. It would be nice if all mapped resources would be served
- The caching solution might end up caching Velocity resources. Consider the following:
my-page.htm
my-page.css
my-page.js
"my-page.htm" and "my-page-js" are Velocity templates and should not be cached as it won't be requested by the browser.
One solution is a lazy on-demand cache. Instead of loading resources upfront, we only load resources when requested. It would mean
switching the cache to a ConcurrentHashMap though.
> 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.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.
[jira] Updated: (CLK-564) Add ResourceService for serving static
resources
Posted by "Malcolm Edgar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Malcolm Edgar updated CLK-564:
------------------------------
Affects Version/s: (was: 2.1.0)
2.0.2
Fix Version/s: 2.1.0 RC1
> 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 RC1
>
>
> 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.
[jira] Commented: (CLK-564) Add ResourceService for serving static
resources
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730251#action_12730251 ]
Bob Schellink commented on CLK-564:
-----------------------------------
Ok, so this feature is targeted only at Click resources available under the "/click/" folder? At least the method ClickServlet#isResourceRequest only recognizes resources under "/click/". If the idea is to only support "/click/" resources, should we expose the ResourceService interface? I attempted a more generic ResourceService implementation but this doesn't work without changing ClickServlet as well.
> 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.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.
[jira] Commented: (CLK-564) Add ResourceService for serving static
resources
Posted by "Malcolm Edgar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730277#action_12730277 ]
Malcolm Edgar commented on CLK-564:
-----------------------------------
Yeah /click/* resources are the current problem we have on WebLogic and WebSphere (and GAE) which is what this is trying to address.
With regard to exposing it as a interface, well this design works pretty well with the current architecture, as the ResourceService gets an initialization event at the right time, and we minimise the size of ClickServlet. However its hard to imagine why you would want to subclass this.
With the ResourceService interface we could add a method isResourceRequest, moving it out of ClickServlet and making the service a bit more flexible.
> 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.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.
[jira] Commented: (CLK-564) Add ResourceService for serving static
resources
Posted by "Malcolm Edgar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12725902#action_12725902 ]
Malcolm Edgar commented on CLK-564:
-----------------------------------
I was thinking that the ResourceService would cache the resources internally with the realpath overriding any JAR resources.
Glassfish 3.0 sounds nice.
Presumably on the Servlet 3.0, this service wouldn't be needed used so we simply would not map the ClickServlet to handle /click/* requests.
What do you think about migrating our the META-INF/web to META-INF/resources, we could have the XmlConfigService and ResourceService also support META-INF/web for backward compatibility.
> 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.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.
[jira] Commented: (CLK-564) Add ResourceService for serving static
resources
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731169#action_12731169 ]
Bob Schellink commented on CLK-564:
-----------------------------------
> 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.
Not sure I follow. The only reason I mentioned CssStyle and JsInclude templates is when using eager loading we will end up caching the JsScript and JsInclude scripts in the ResourceService because these files have *.js or *.css extensions. So ResourceService will think they are static resources where in reality they are Velocity templates. When Velocity renders these templates they are cached by Velocity as well and so we end up caching these resources twice.
If we only cater for /click/* resources there is no worries because we don't have any *.js or *.css templates. If we try and cater for things such as /clickclick/* we would have this issue because clickclick uses quite a number of these templates.
With lazy loading this problem goes away because we will only load resources that are requested by the browser. Since the templates are not static resources, the browser won't request them and ResourceService won't cache them.
I'm quite happy with the ResourceService as it stands now and will test it out in the next couple of days on GAE.
> 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.
[jira] Assigned: (CLK-564) Add ResourceService for serving static
resources
Posted by "Malcolm Edgar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Malcolm Edgar reassigned CLK-564:
---------------------------------
Assignee: Malcolm Edgar
> 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.1.0
> Reporter: Malcolm Edgar
> Assignee: 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.
[jira] Commented: (CLK-564) Add ResourceService for serving static
resources
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (CLK-564) Add ResourceService for serving static
resources
Posted by "Malcolm Edgar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731392#action_12731392 ]
Malcolm Edgar commented on CLK-564:
-----------------------------------
The reports look very nice.
I think a build tools source tree would be very good, could be the start of some project generation tools and lint as well. I don't think we should include it click-extras as its not code you want to deploy, and I think it will be confusing. Mind you its more build.xml and documentation work if we have a new source tree.
Maven can run Ant tasks as well:
http://maven.apache.org/plugins/maven-antrun-plugin/
Regarding the ResourceService we can avoid having it cache *.css or *.js files leaving the template engine to cache them on demand. We would just put a marker value in the cache so that the ResourceService knows that a file exists.
> 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
>
> Attachments: report_1.html, report_2.html, report_3.html
>
>
> 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.
[jira] Commented: (CLK-564) Add ResourceService for serving static
resources
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12727078#action_12727078 ]
Bob Schellink commented on CLK-564:
-----------------------------------
There was an attempt at solving this issue before. Here is the revision: http://fisheye3.atlassian.com/changelog/click?cs=3335
Another issue to ponder is that Velocity also caches htm templates. So we need to ensure we don't cache it a second time. Velocity can load resources from jars so we could probably look at prefixing htm resources with "META-INF/resources" and Velocity should load them just fine.
We still need to deal with other file extensions though.
> 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.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.
[jira] Commented: (CLK-564) Add ResourceService for serving static
resources
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12725849#action_12725849 ]
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: https://issues.apache.org/jira/browse/CLK-564
> 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.
[jira] Updated: (CLK-564) Add ResourceService for serving static
resources
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bob Schellink updated CLK-564:
------------------------------
Attachment: report_3.html
report_2.html
report_1.html
I've put together an Ant task to tackle this issue during build time.
The task deploys resources from a WEB-INF folder to a target web application folder. It will generate a report describing which resources were deployed and which resources are outdated and needs to be manually replaced or merged. Example usage:
<target name="deploy" description="Deploy tests" depends="build">
<taskdef name="deploy" classname="org.apache.click.tools.devtasks.DeployTask"
classpath="classpath"/>
<deploy dir="src/war/WEB-INF" todir="src/war"/>
</target>
I've attached a couple of the reports generated by this task:
report_1.html - on first run it deployed all resources
report_2.html - on second run nothing new was deployed and all resources was up to date
report_3.html - after changing some of the deployed resources, the third run prints the outdated resources
Could be a useful tool addition or part of extras. Not sure if this will work with maven though. Can maven invoke Ant tasks?
> 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
>
> Attachments: report_1.html, report_2.html, report_3.html
>
>
> 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.
[jira] Updated: (CLK-564) Add ResourceService for serving static
resources
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bob Schellink updated CLK-564:
------------------------------
Fix Version/s: (was: 2.1.0 RC2)
2.1.0
> 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.1.0 RC1
> Reporter: Malcolm Edgar
> Assignee: Malcolm Edgar
> Fix For: 2.1.0
>
> Attachments: report_1.html, report_2.html, report_3.html
>
>
> 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.
[jira] Commented: (CLK-564) Add ResourceService for serving static
resources
Posted by "Malcolm Edgar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729223#action_12729223 ]
Malcolm Edgar commented on CLK-564:
-----------------------------------
Thanks for the review and feedback.
I have implemented your suggested fix for the /click/error.htm and /click/not-found.htm resources in the VelocityTemplateService. I have yet to do this for the FreemarkerTemplateService, but logically very similar.
I will think some about your other comments regarding resources. This could be handy having a velocity template for dynamically rendering JS and CSS content. However this is a broader issue than the current problem with deployment onto WebLogic / WebSphere
Regarding build time, yes that is the current solution for WebLogic / WebSphere but it gives people a pretty bad initial experience until they figure it out. We could provide an Ant task to do what you described.
> 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.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.
[jira] Commented: (CLK-564) Add ResourceService for serving static
resources
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12735426#action_12735426 ]
Bob Schellink commented on CLK-564:
-----------------------------------
I've noticed in the examples that the Cayenne DataContextFilter mapping in web.xml references ClickServlet. The logs show that Cayenne creates a new DataContext not only for the Page request, but also for each resource request.
I'm going to update the example web.xml to map DataContextFilter to <url-pattern>*.htm</url-pattern> instead.
> 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.1.0 RC1
> Reporter: Malcolm Edgar
> Assignee: Malcolm Edgar
> Fix For: 2.1.0
>
> Attachments: report_1.html, report_2.html, report_3.html
>
>
> 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.
[jira] Commented: (CLK-564) Add ResourceService for serving static
resources
Posted by "Malcolm Edgar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12725946#action_12725946 ]
Malcolm Edgar commented on CLK-564:
-----------------------------------
Yes that is a good point, not sure what we could do about that however.
> 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.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.
[jira] Commented: (CLK-564) Add ResourceService for serving static
resources
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732125#action_12732125 ]
Bob Schellink commented on CLK-564:
-----------------------------------
The latest version of ResourceService looks good.
I'd suggest we don't support the dynamic *.js and *.css templates in the service though. What makes this feature awkward is its only supported for packaged non-deployed *.js and *.css. If the resource is deployed then it doesn't work anymore. I think if dynamic *.js and *.css is needed a better place to handle them would be through a Page using JsScript and CssStyle.
Another issue is that of caching in non-production mode. I did a small test with the examples but forgot that /click/* was mapped for static resources. Changing the control.css on the file system didn't result in a change on the browser. Then I remembered that the resources was cached by ResourceService and I had to restart the server to view the change. For the examples we might want to comment out the mapping in web.xml.
Other than that I think this is good to go.
Regarding the build time tools I'm leaning towards including this in the click-dev-tools.jar which is already included in the distribution lib folder. I'm not that keen on adding another source tree for this feature alone. I'd rather document the tool in GAE Javadoc and FAQ/Best Practice. If we add fancy code generation we could expose another source tree.
> 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
>
> Attachments: report_1.html, report_2.html, report_3.html
>
>
> 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.
[jira] Commented: (CLK-564) Add ResourceService for serving static
resources
Posted by "Malcolm Edgar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730784#action_12730784 ]
Malcolm Edgar commented on CLK-564:
-----------------------------------
OK would it be more useful to make this more generic to support GAE. I just want to outline the scenario below so I have it straight.
You have static resources in a JAR which you want served in a GAE or restricted environment. You would application would then have ClickServlet mapping for these directories:
<servlet-mapping>
<servlet-name>ClickServlet</servlet-name>
<url-pattern>/assets/*</url-pattern>
</servlet-mapping>
The ClickServlet would then render these using the ResourceService. Should we load any resources excluding *.htm ? Should we consider using the template service to render *.css and *.js files, adding the usual things to the model $request and $context
> 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.
[jira] Commented: (CLK-564) Add ResourceService for serving static
resources
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12728572#action_12728572 ]
Bob Schellink commented on CLK-564:
-----------------------------------
I've also been thinking of solving the resource issue at build time instead of runtime. For example we can ship a command line/Ant task that can be integrated into the application build to copy the resources to the webapp src structure. It is useful to have access to Click's resources in order to tweak the look and feel or menu rendering. ClickIDE could be enhanced with a menu item to copy the resources.
> 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.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.
[jira] Updated: (CLK-564) Add ResourceService for serving static
resources
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bob Schellink updated CLK-564:
------------------------------
Affects Version/s: (was: 2.0.2)
2.1.0 RC1
updated affected version
> 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.1.0 RC1
> Reporter: Malcolm Edgar
> Assignee: Malcolm Edgar
> Fix For: 2.1.0 RC2
>
> Attachments: report_1.html, report_2.html, report_3.html
>
>
> 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.
[jira] Commented: (CLK-564) Add ResourceService for serving static
resources
Posted by "Malcolm Edgar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730845#action_12730845 ]
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 mapping.
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: 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.
[jira] Commented: (CLK-564) Add ResourceService for serving static
resources
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12725940#action_12725940 ]
Bob Schellink commented on CLK-564:
-----------------------------------
Agreed META-INF/web should still be supported still.
Another thing to keep in mind is in a non Servlet3.0 environment, if we move to META-INF/resources and copy all resources to the web app folder we might very well copy non-Click resources out as well. Not sure if this poses a real problem though. I guess it would be fine.
> 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.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.
[jira] Updated: (CLK-564) Add ResourceService for serving static
resources
Posted by "Malcolm Edgar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Malcolm Edgar updated CLK-564:
------------------------------
Fix Version/s: (was: 2.1.0 RC1)
2.1.0 RC2
> 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.
[jira] Commented: (CLK-564) Add ResourceService for serving static
resources
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12774278#action_12774278 ]
Bob Schellink commented on CLK-564:
-----------------------------------
Hi Malcolm,
I've checked in a change to the ClickResourceService to serve resources lazily. This has some advantages over eager loading:
- resources won't be loaded if they are not requested. This resolves the issue with eager loading where all resources from jars are loaded, even if some of those resources aren't valid static resources, for example Velocity templates with extensions other than .htm.
- removed all duplicate code shared with XmlConfigService
- with lazy loading it was easy to add the ability to only cache resources in production modes
The only feature still outstanding is how to handle the case where Velocity attempts to render a template contained under META-INF/resources. Currently the VelocityTemplateService caters for two built in templates, but won't handle custom templates. I suppose we can cross that bridge when we get there.
> 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.1.0 RC1
> Reporter: Malcolm Edgar
> Assignee: Malcolm Edgar
> Fix For: 2.1.0
>
> Attachments: report_1.html, report_2.html, report_3.html
>
>
> 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.
[jira] Commented: (CLK-564) Add ResourceService for serving static
resources
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730332#action_12730332 ]
Bob Schellink commented on CLK-564:
-----------------------------------
Currently the ClickClick examples are hosted on GAE. But ClickClick places its resources under /clickclick/* instead of /click/*, thus I need to manually make the /clickclick/* resources available at build time. So I wanted to subclass ResourceService to provide a more generic implementation to serve any resource.
I implemented a quick hack (won't check it in) to generify the ResourceService implementation so any resource can be served, however changes had to be made to ClickServlet and VelocityTemplateService. ClickClick also makes heavy use of CSS and JS template resources which is why I mentioned the lazy loading approach in one of the comments above. This lead to me to ask if the scope of this feature is limited to only /click/* resources, which it is.
I'll implement an Ant task to copy the resources and report back here how it worked out :)
> 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.