You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@click.apache.org by "Andrew Fink (JIRA)" <ji...@apache.org> on 2010/09/23 14:33:33 UTC
[jira] Created: (CLK-719) Click Resources Deploying prevents rapid
development with container's (tomcat in my case) hot deploy
Click Resources Deploying prevents rapid development with container's (tomcat in my case) hot deploy
----------------------------------------------------------------------------------------------------
Key: CLK-719
URL: https://issues.apache.org/jira/browse/CLK-719
Project: Click
Issue Type: Improvement
Components: core
Affects Versions: 2.2.0, 2.1.0
Reporter: Andrew Fink
Example:
I have some template in "META-INF/resources", for ex: META-INF/resources/admin/blabla.ftl
I run tomcat under my IDE:
1) it deploys webapp - OK
2) click deploys META-INF/resources/admin/blabla.ftl to webroot/admin/blabla.ftl - OK
Then I see some mistake in blabla.ftl and bug fix it, build and deploy again.
1. Tomcat re-deploys webapp over existing webapp - OK!
2. Click doesn't deploy blabla.ftl because It already exists (tomcat/IDE doesn't clean folder).
It is a problem.
__ ClickUtils.deployFile checks only destinationFile.exists() __
I think in debug|trace mode, Click should:
- always overwrite (redeploy) files,
- or checks resource length (for example: skip all bytes from resource's inputStream to calculate it's length) and if destinationFile.length != resource.length then overwrite (redeploy)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CLK-719) Click Resources Deploying prevents
rapid development with container's (tomcat in my case) hot deploy
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915316#action_12915316 ]
Bob Schellink commented on CLK-719:
-----------------------------------
> Does Click support this servlet 3.0 feature (i.e. won't deploy resources)?
Not yet. It should be easy to fix, we need to check the major version -> ServletContext#getMajorVersion().
Tomcat 7 is still in beta though.
> Click Resources Deploying prevents rapid development with container's (tomcat in my case) hot deploy
> ----------------------------------------------------------------------------------------------------
>
> Key: CLK-719
> URL: https://issues.apache.org/jira/browse/CLK-719
> Project: Click
> Issue Type: Improvement
> Components: core
> Affects Versions: 2.2.0, 2.1.0
> Reporter: Andrew Fink
>
> Example:
> I have some template in "META-INF/resources", for ex: META-INF/resources/admin/blabla.ftl
> I run tomcat under my IDE:
> 1) it deploys webapp - OK
> 2) click deploys META-INF/resources/admin/blabla.ftl to webroot/admin/blabla.ftl - OK
> Then I see some mistake in blabla.ftl and bug fix it, build and deploy again.
> 1. Tomcat re-deploys webapp over existing webapp - OK!
> 2. Click doesn't deploy blabla.ftl because It already exists (tomcat/IDE doesn't clean folder).
> It is a problem.
> __ ClickUtils.deployFile checks only destinationFile.exists() __
> I think in debug|trace mode, Click should:
> - always overwrite (redeploy) files,
> - or checks resource length (for example: skip all bytes from resource's inputStream to calculate it's length) and if destinationFile.length != resource.length then overwrite (redeploy)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CLK-719) Click Resources Deploying prevents
rapid development with container's (tomcat in my case) hot deploy
Posted by "Andrew Fink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915281#action_12915281 ]
Andrew Fink commented on CLK-719:
---------------------------------
also better idea for ClickUtils.encodeUrl:
if (charset == null) {
return URLEncoder.encode(object.toString(), "UTF-8");//here!
} else {
return URLEncoder.encode(object.toString(), charset);
}
> Click Resources Deploying prevents rapid development with container's (tomcat in my case) hot deploy
> ----------------------------------------------------------------------------------------------------
>
> Key: CLK-719
> URL: https://issues.apache.org/jira/browse/CLK-719
> Project: Click
> Issue Type: Improvement
> Components: core
> Affects Versions: 2.2.0, 2.1.0
> Reporter: Andrew Fink
>
> Example:
> I have some template in "META-INF/resources", for ex: META-INF/resources/admin/blabla.ftl
> I run tomcat under my IDE:
> 1) it deploys webapp - OK
> 2) click deploys META-INF/resources/admin/blabla.ftl to webroot/admin/blabla.ftl - OK
> Then I see some mistake in blabla.ftl and bug fix it, build and deploy again.
> 1. Tomcat re-deploys webapp over existing webapp - OK!
> 2. Click doesn't deploy blabla.ftl because It already exists (tomcat/IDE doesn't clean folder).
> It is a problem.
> __ ClickUtils.deployFile checks only destinationFile.exists() __
> I think in debug|trace mode, Click should:
> - always overwrite (redeploy) files,
> - or checks resource length (for example: skip all bytes from resource's inputStream to calculate it's length) and if destinationFile.length != resource.length then overwrite (redeploy)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CLK-719) Click Resources Deploying prevents
rapid development with container's (tomcat in my case) hot deploy
Posted by "Andrew Fink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915293#action_12915293 ]
Andrew Fink commented on CLK-719:
---------------------------------
Hmm. Yes, It is dilemma.
Now If your resources in jar files - you have broken hot deploy.
After my patch resources in webroot will be under attack.
May be use this algorithm:
if (!destinationFile.exists()) {
// deploy as usual
} else if (ConfigService.MODE_TRACE.equals(getConfigService(servletContext).getApplicationMode()))
{ //trace mode = special case
calculate resource length and compare destinationFile length
if resource is longer then overwrite destinationFile
So usually all woks like now (production mode).
Only in trace mode (when you develop or debug special cases) you should care about your overriding versions in webroot: they should be bigger or equal than original jar version
> Click Resources Deploying prevents rapid development with container's (tomcat in my case) hot deploy
> ----------------------------------------------------------------------------------------------------
>
> Key: CLK-719
> URL: https://issues.apache.org/jira/browse/CLK-719
> Project: Click
> Issue Type: Improvement
> Components: core
> Affects Versions: 2.2.0, 2.1.0
> Reporter: Andrew Fink
>
> Example:
> I have some template in "META-INF/resources", for ex: META-INF/resources/admin/blabla.ftl
> I run tomcat under my IDE:
> 1) it deploys webapp - OK
> 2) click deploys META-INF/resources/admin/blabla.ftl to webroot/admin/blabla.ftl - OK
> Then I see some mistake in blabla.ftl and bug fix it, build and deploy again.
> 1. Tomcat re-deploys webapp over existing webapp - OK!
> 2. Click doesn't deploy blabla.ftl because It already exists (tomcat/IDE doesn't clean folder).
> It is a problem.
> __ ClickUtils.deployFile checks only destinationFile.exists() __
> I think in debug|trace mode, Click should:
> - always overwrite (redeploy) files,
> - or checks resource length (for example: skip all bytes from resource's inputStream to calculate it's length) and if destinationFile.length != resource.length then overwrite (redeploy)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CLK-719) Click Resources Deploying prevents
rapid development with container's (tomcat in my case) hot deploy
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914030#action_12914030 ]
Bob Schellink commented on CLK-719:
-----------------------------------
Unless I'm missing something, with this proposal it won't be possible to override resources deployed from jars.
> Click Resources Deploying prevents rapid development with container's (tomcat in my case) hot deploy
> ----------------------------------------------------------------------------------------------------
>
> Key: CLK-719
> URL: https://issues.apache.org/jira/browse/CLK-719
> Project: Click
> Issue Type: Improvement
> Components: core
> Affects Versions: 2.2.0, 2.1.0
> Reporter: Andrew Fink
>
> Example:
> I have some template in "META-INF/resources", for ex: META-INF/resources/admin/blabla.ftl
> I run tomcat under my IDE:
> 1) it deploys webapp - OK
> 2) click deploys META-INF/resources/admin/blabla.ftl to webroot/admin/blabla.ftl - OK
> Then I see some mistake in blabla.ftl and bug fix it, build and deploy again.
> 1. Tomcat re-deploys webapp over existing webapp - OK!
> 2. Click doesn't deploy blabla.ftl because It already exists (tomcat/IDE doesn't clean folder).
> It is a problem.
> __ ClickUtils.deployFile checks only destinationFile.exists() __
> I think in debug|trace mode, Click should:
> - always overwrite (redeploy) files,
> - or checks resource length (for example: skip all bytes from resource's inputStream to calculate it's length) and if destinationFile.length != resource.length then overwrite (redeploy)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CLK-719) Click Resources Deploying prevents
rapid development with container's (tomcat in my case) hot deploy
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915303#action_12915303 ]
Bob Schellink commented on CLK-719:
-----------------------------------
I'm worried about varying behavior between modes. It tends to confuse.
I can see two resolutions. We can add a new configuration or add support for Servlet 3 containers (is anybody using Tomcat7? :)
The nice thing about Servlet 3 is that Click doesn't have to deploy resources anymore, the container takes care of this step for us.
> Click Resources Deploying prevents rapid development with container's (tomcat in my case) hot deploy
> ----------------------------------------------------------------------------------------------------
>
> Key: CLK-719
> URL: https://issues.apache.org/jira/browse/CLK-719
> Project: Click
> Issue Type: Improvement
> Components: core
> Affects Versions: 2.2.0, 2.1.0
> Reporter: Andrew Fink
>
> Example:
> I have some template in "META-INF/resources", for ex: META-INF/resources/admin/blabla.ftl
> I run tomcat under my IDE:
> 1) it deploys webapp - OK
> 2) click deploys META-INF/resources/admin/blabla.ftl to webroot/admin/blabla.ftl - OK
> Then I see some mistake in blabla.ftl and bug fix it, build and deploy again.
> 1. Tomcat re-deploys webapp over existing webapp - OK!
> 2. Click doesn't deploy blabla.ftl because It already exists (tomcat/IDE doesn't clean folder).
> It is a problem.
> __ ClickUtils.deployFile checks only destinationFile.exists() __
> I think in debug|trace mode, Click should:
> - always overwrite (redeploy) files,
> - or checks resource length (for example: skip all bytes from resource's inputStream to calculate it's length) and if destinationFile.length != resource.length then overwrite (redeploy)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CLK-719) Click Resources Deploying prevents
rapid development with container's (tomcat in my case) hot deploy
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915290#action_12915290 ]
Bob Schellink commented on CLK-719:
-----------------------------------
To clarify my question: Click deploys resources as follows:
1: deploy all resources on the ServletPath -> ServletContext#getResourcePaths
2. deploy resources under WEB-INF
So if a developer wants to override a resource they can simply create a custom version and put it in their webapp. For example:
/click/control.js would override the control.js file deployed by Click itself.
With this change the control.js in the Click jar would be deployed over my changes.
Another thing to consider is IDE's. In Netbeans at least, it uses an exploded war and would immediately copy changes to J/CSS/HTM files to the output folder. If Click were to override these resources upon startup I'd loose my changes when the server hot-deploys.
Does this clarify my question?
> Click Resources Deploying prevents rapid development with container's (tomcat in my case) hot deploy
> ----------------------------------------------------------------------------------------------------
>
> Key: CLK-719
> URL: https://issues.apache.org/jira/browse/CLK-719
> Project: Click
> Issue Type: Improvement
> Components: core
> Affects Versions: 2.2.0, 2.1.0
> Reporter: Andrew Fink
>
> Example:
> I have some template in "META-INF/resources", for ex: META-INF/resources/admin/blabla.ftl
> I run tomcat under my IDE:
> 1) it deploys webapp - OK
> 2) click deploys META-INF/resources/admin/blabla.ftl to webroot/admin/blabla.ftl - OK
> Then I see some mistake in blabla.ftl and bug fix it, build and deploy again.
> 1. Tomcat re-deploys webapp over existing webapp - OK!
> 2. Click doesn't deploy blabla.ftl because It already exists (tomcat/IDE doesn't clean folder).
> It is a problem.
> __ ClickUtils.deployFile checks only destinationFile.exists() __
> I think in debug|trace mode, Click should:
> - always overwrite (redeploy) files,
> - or checks resource length (for example: skip all bytes from resource's inputStream to calculate it's length) and if destinationFile.length != resource.length then overwrite (redeploy)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CLK-719) Click Resources Deploying prevents
rapid development with container's (tomcat in my case) hot deploy
Posted by "Andrew Fink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915310#action_12915310 ]
Andrew Fink commented on CLK-719:
---------------------------------
I can try to use Tomcat 7 in my dev env.
Does Click support this servlet 3.0 feature (i.e. won't deploy resources)?
> Click Resources Deploying prevents rapid development with container's (tomcat in my case) hot deploy
> ----------------------------------------------------------------------------------------------------
>
> Key: CLK-719
> URL: https://issues.apache.org/jira/browse/CLK-719
> Project: Click
> Issue Type: Improvement
> Components: core
> Affects Versions: 2.2.0, 2.1.0
> Reporter: Andrew Fink
>
> Example:
> I have some template in "META-INF/resources", for ex: META-INF/resources/admin/blabla.ftl
> I run tomcat under my IDE:
> 1) it deploys webapp - OK
> 2) click deploys META-INF/resources/admin/blabla.ftl to webroot/admin/blabla.ftl - OK
> Then I see some mistake in blabla.ftl and bug fix it, build and deploy again.
> 1. Tomcat re-deploys webapp over existing webapp - OK!
> 2. Click doesn't deploy blabla.ftl because It already exists (tomcat/IDE doesn't clean folder).
> It is a problem.
> __ ClickUtils.deployFile checks only destinationFile.exists() __
> I think in debug|trace mode, Click should:
> - always overwrite (redeploy) files,
> - or checks resource length (for example: skip all bytes from resource's inputStream to calculate it's length) and if destinationFile.length != resource.length then overwrite (redeploy)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CLK-719) Click Resources Deploying prevents rapid
development with container's (tomcat in my case) hot deploy
Posted by "Bob Schellink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bob Schellink resolved CLK-719.
-------------------------------
Resolution: Duplicate
CLK-721
> Click Resources Deploying prevents rapid development with container's (tomcat in my case) hot deploy
> ----------------------------------------------------------------------------------------------------
>
> Key: CLK-719
> URL: https://issues.apache.org/jira/browse/CLK-719
> Project: Click
> Issue Type: Improvement
> Components: core
> Affects Versions: 2.2.0, 2.1.0
> Reporter: Andrew Fink
>
> Example:
> I have some template in "META-INF/resources", for ex: META-INF/resources/admin/blabla.ftl
> I run tomcat under my IDE:
> 1) it deploys webapp - OK
> 2) click deploys META-INF/resources/admin/blabla.ftl to webroot/admin/blabla.ftl - OK
> Then I see some mistake in blabla.ftl and bug fix it, build and deploy again.
> 1. Tomcat re-deploys webapp over existing webapp - OK!
> 2. Click doesn't deploy blabla.ftl because It already exists (tomcat/IDE doesn't clean folder).
> It is a problem.
> __ ClickUtils.deployFile checks only destinationFile.exists() __
> I think in debug|trace mode, Click should:
> - always overwrite (redeploy) files,
> - or checks resource length (for example: skip all bytes from resource's inputStream to calculate it's length) and if destinationFile.length != resource.length then overwrite (redeploy)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CLK-719) Click Resources Deploying prevents
rapid development with container's (tomcat in my case) hot deploy
Posted by "Andrew Fink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CLK-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915280#action_12915280 ]
Andrew Fink commented on CLK-719:
---------------------------------
Why?
I don't have any SecutityManager, so my web app can do anything.
It is Click itself who checks for file.exists() and if file exists doesn't overwrite it.
OK, here working patch for ClickUtils.java (with this patch all works fine):
@@ -1418,10 +1418,12 @@
File destinationFile = new File(destination);
- if (!destinationFile.exists()) {
- InputStream inputStream =
- getResourceAsStream(resource, ClickUtils.class);
+ final String curMode = getConfigService(servletContext).getApplicationMode();
+ final boolean traceOrDebug = ConfigService.MODE_TRACE.equals(curMode) || ConfigService.MODE_DEBUG.equals(curMode);
+ if (!destinationFile.exists() || traceOrDebug) {//file not exists or in-development
+ InputStream inputStream = getResourceAsStream(resource, ClickUtils.class);
+
if (inputStream != null) {
FileOutputStream fos = null;
try {
> Click Resources Deploying prevents rapid development with container's (tomcat in my case) hot deploy
> ----------------------------------------------------------------------------------------------------
>
> Key: CLK-719
> URL: https://issues.apache.org/jira/browse/CLK-719
> Project: Click
> Issue Type: Improvement
> Components: core
> Affects Versions: 2.2.0, 2.1.0
> Reporter: Andrew Fink
>
> Example:
> I have some template in "META-INF/resources", for ex: META-INF/resources/admin/blabla.ftl
> I run tomcat under my IDE:
> 1) it deploys webapp - OK
> 2) click deploys META-INF/resources/admin/blabla.ftl to webroot/admin/blabla.ftl - OK
> Then I see some mistake in blabla.ftl and bug fix it, build and deploy again.
> 1. Tomcat re-deploys webapp over existing webapp - OK!
> 2. Click doesn't deploy blabla.ftl because It already exists (tomcat/IDE doesn't clean folder).
> It is a problem.
> __ ClickUtils.deployFile checks only destinationFile.exists() __
> I think in debug|trace mode, Click should:
> - always overwrite (redeploy) files,
> - or checks resource length (for example: skip all bytes from resource's inputStream to calculate it's length) and if destinationFile.length != resource.length then overwrite (redeploy)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.