You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "John Crim (JIRA)" <ji...@apache.org> on 2009/05/15 06:55:47 UTC

[jira] Created: (TAP5-704) Tapestry webapp locks files in WEB-INF/lib, preventing clean re-deploy without restarting Tomcat.

Tapestry webapp locks files in WEB-INF/lib, preventing clean re-deploy without restarting Tomcat.
-------------------------------------------------------------------------------------------------

                 Key: TAP5-704
                 URL: https://issues.apache.org/jira/browse/TAP5-704
             Project: Tapestry 5
          Issue Type: Bug
          Components: quickstart, tapestry-core
    Affects Versions: 5.1.0.5
            Reporter: John Crim


Repro steps:
1. Run the Tapestry quickstart archetype (v 5.1.0.5)
2. Build it (mvn package) and deploy the WAR to the latest version of Tomcat (6.0.18).
3. View the site in a browser (to start Tapestry)
4. Undeploy the webapp (either using /manager/html or an external command)
5. Rebuild the webapp and try to deploy it.

In short, this flaw adds significant time to each iteration during development.  And, if a developer doesn't understand that Tapestry webapps don't undeploy properly, they can easily waste time with bugs that arise because old code is still running in tomcat.

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


[jira] Commented: (TAP5-704) Tapestry webapp locks files in WEB-INF/lib, preventing clean re-deploy without restarting Tomcat.

Posted by "John Crim (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/TAP5-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710050#action_12710050 ] 

John Crim commented on TAP5-704:
--------------------------------

I think there's a cut and paste error in your comment - search for ??

Thanks for the info.  To clarify for anyone else who looks at this issue, this issue is (most likely) Windows specific, b/c Java gets file locking wrong.  The "fix" is to add antiResourceLocking to META-INF/context.xml or tomcat/conf/context.xml:

<Context path="/myWebApp" antiResourceLocking="true" />

This allows redeploying a Tomcat webapp without shutting down Tomcat, manually deleting the webapp, and re-starting Tomcat.

Note 2 things:
* antiResourceLocking is not compatible with Tapestry's template and code reloading feature, b/c Tomcat implements it by copying the webapp files to a temp directory
* You probably don't want antiResourceLocking enabled in a production webapp

> Tapestry webapp locks files in WEB-INF/lib, preventing clean re-deploy without restarting Tomcat.
> -------------------------------------------------------------------------------------------------
>
>                 Key: TAP5-704
>                 URL: https://issues.apache.org/jira/browse/TAP5-704
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: quickstart, tapestry-core
>    Affects Versions: 5.1.0.5
>            Reporter: John Crim
>
> Repro steps:
> 1. Run the Tapestry quickstart archetype (v 5.1.0.5) in NetBeans
> 2. Run it in the latest version of Tomcat (6.0.18). (note that NetBeans does the equivalent of running the exploded WAR in the /target dir directly within Tomcat)
> 3. View the site in a browser (to start Tapestry)
> 4. Undeploy the webapp in the Server window
> 5. Rebuild the webapp (mvn clean package) and try to deploy it. - the clean will fail with an error like:
> Failed to delete directory: C:\dev\tapestry\webAppB\target. Reason: Unable to delete file C:\dev\tapestry\webAppB\target\webAppB\WEB-INF\lib\antlr-runtime-3.1.1.jar
> In short, this flaw adds significant time to each iteration during development.  And, if a developer doesn't understand that Tapestry webapps don't undeploy properly, they can easily waste time with bugs that arise because old code is still running in tomcat.
> The workaround is to shutdown tomcat before rebuilding the webapp (mvn clean) each time.

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


[jira] Updated: (TAP5-704) Tapestry webapp locks files in WEB-INF/lib, preventing clean re-deploy without restarting Tomcat.

Posted by "John Crim (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/TAP5-704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Crim updated TAP5-704:
---------------------------

    Description: 
Repro steps:
1. Run the Tapestry quickstart archetype (v 5.1.0.5) in NetBeans
2. Run it in the latest version of Tomcat (6.0.18). (note that NetBeans does the equivalent of running the exploded WAR in the /target dir directly within Tomcat)
3. View the site in a browser (to start Tapestry)
4. Undeploy the webapp in the Server window
5. Rebuild the webapp (mvn clean package) and try to deploy it. - the clean will fail with an error like:
Failed to delete directory: C:\dev\tapestry\webAppB\target. Reason: Unable to delete file C:\dev\tapestry\webAppB\target\webAppB\WEB-INF\lib\antlr-runtime-3.1.1.jar

In short, this flaw adds significant time to each iteration during development.  And, if a developer doesn't understand that Tapestry webapps don't undeploy properly, they can easily waste time with bugs that arise because old code is still running in tomcat.

The workaround is to shutdown tomcat before rebuilding the webapp (mvn clean) each time.

  was:
Repro steps:
1. Run the Tapestry quickstart archetype (v 5.1.0.5)
2. Build it (mvn package) and deploy the WAR to the latest version of Tomcat (6.0.18).
3. View the site in a browser (to start Tapestry)
4. Undeploy the webapp (either using /manager/html or an external command)
5. Rebuild the webapp and try to deploy it.

In short, this flaw adds significant time to each iteration during development.  And, if a developer doesn't understand that Tapestry webapps don't undeploy properly, they can easily waste time with bugs that arise because old code is still running in tomcat.


> Tapestry webapp locks files in WEB-INF/lib, preventing clean re-deploy without restarting Tomcat.
> -------------------------------------------------------------------------------------------------
>
>                 Key: TAP5-704
>                 URL: https://issues.apache.org/jira/browse/TAP5-704
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: quickstart, tapestry-core
>    Affects Versions: 5.1.0.5
>            Reporter: John Crim
>
> Repro steps:
> 1. Run the Tapestry quickstart archetype (v 5.1.0.5) in NetBeans
> 2. Run it in the latest version of Tomcat (6.0.18). (note that NetBeans does the equivalent of running the exploded WAR in the /target dir directly within Tomcat)
> 3. View the site in a browser (to start Tapestry)
> 4. Undeploy the webapp in the Server window
> 5. Rebuild the webapp (mvn clean package) and try to deploy it. - the clean will fail with an error like:
> Failed to delete directory: C:\dev\tapestry\webAppB\target. Reason: Unable to delete file C:\dev\tapestry\webAppB\target\webAppB\WEB-INF\lib\antlr-runtime-3.1.1.jar
> In short, this flaw adds significant time to each iteration during development.  And, if a developer doesn't understand that Tapestry webapps don't undeploy properly, they can easily waste time with bugs that arise because old code is still running in tomcat.
> The workaround is to shutdown tomcat before rebuilding the webapp (mvn clean) each time.

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


[jira] Updated: (TAP5-704) Tapestry webapp locks files in WEB-INF/lib, preventing clean re-deploy without restarting Tomcat.

Posted by "John Crim (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/TAP5-704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Crim updated TAP5-704:
---------------------------

    Description: 
Repro steps:
1. Run the Tapestry quickstart archetype (v 5.1.0.5) in NetBeans
2. Run it in the latest version of Tomcat (6.0.18). (note that NetBeans does the equivalent of running the exploded WAR in the /target dir directly within Tomcat)
3. View the site in a browser (to start Tapestry)
4. Undeploy the webapp in the Server window
5. Rebuild the webapp (mvn clean package) and try to deploy it. - the clean will fail with an error like:
Failed to delete directory: C:\dev\tapestry\webAppB\target. Reason: Unable to delete file C:\dev\tapestry\webAppB\target\webAppB\WEB-INF\lib\antlr-runtime-3.1.1.jar

In short, this flaw adds significant time to each iteration during development.  And, if a developer doesn't understand that Tapestry webapps don't undeploy properly, they can easily waste time with bugs that arise because old code is still running in tomcat.

The workaround is to shutdown tomcat before rebuilding the webapp (mvn clean) each time.

  was:
Repro steps:
1. Run the Tapestry quickstart archetype (v 5.1.0.5)
2. Build it (mvn package) and deploy the WAR to the latest version of Tomcat (6.0.18).
3. View the site in a browser (to start Tapestry)
4. Undeploy the webapp (either using /manager/html or an external command)
5. Rebuild the webapp and try to deploy it.

In short, this flaw adds significant time to each iteration during development.  And, if a developer doesn't understand that Tapestry webapps don't undeploy properly, they can easily waste time with bugs that arise because old code is still running in tomcat.


> Tapestry webapp locks files in WEB-INF/lib, preventing clean re-deploy without restarting Tomcat.
> -------------------------------------------------------------------------------------------------
>
>                 Key: TAP5-704
>                 URL: https://issues.apache.org/jira/browse/TAP5-704
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: quickstart, tapestry-core
>    Affects Versions: 5.1.0.5
>            Reporter: John Crim
>
> Repro steps:
> 1. Run the Tapestry quickstart archetype (v 5.1.0.5) in NetBeans
> 2. Run it in the latest version of Tomcat (6.0.18). (note that NetBeans does the equivalent of running the exploded WAR in the /target dir directly within Tomcat)
> 3. View the site in a browser (to start Tapestry)
> 4. Undeploy the webapp in the Server window
> 5. Rebuild the webapp (mvn clean package) and try to deploy it. - the clean will fail with an error like:
> Failed to delete directory: C:\dev\tapestry\webAppB\target. Reason: Unable to delete file C:\dev\tapestry\webAppB\target\webAppB\WEB-INF\lib\antlr-runtime-3.1.1.jar
> In short, this flaw adds significant time to each iteration during development.  And, if a developer doesn't understand that Tapestry webapps don't undeploy properly, they can easily waste time with bugs that arise because old code is still running in tomcat.
> The workaround is to shutdown tomcat before rebuilding the webapp (mvn clean) each time.

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


[jira] Commented: (TAP5-704) Tapestry webapp locks files in WEB-INF/lib, preventing clean re-deploy without restarting Tomcat.

Posted by "John Crim (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/TAP5-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710050#action_12710050 ] 

John Crim commented on TAP5-704:
--------------------------------

I think there's a cut and paste error in your comment - search for ??

Thanks for the info.  To clarify for anyone else who looks at this issue, this issue is (most likely) Windows specific, b/c Java gets file locking wrong.  The "fix" is to add antiResourceLocking to META-INF/context.xml or tomcat/conf/context.xml:

<Context path="/myWebApp" antiResourceLocking="true" />

This allows redeploying a Tomcat webapp without shutting down Tomcat, manually deleting the webapp, and re-starting Tomcat.

Note 2 things:
* antiResourceLocking is not compatible with Tapestry's template and code reloading feature, b/c Tomcat implements it by copying the webapp files to a temp directory
* You probably don't want antiResourceLocking enabled in a production webapp

> Tapestry webapp locks files in WEB-INF/lib, preventing clean re-deploy without restarting Tomcat.
> -------------------------------------------------------------------------------------------------
>
>                 Key: TAP5-704
>                 URL: https://issues.apache.org/jira/browse/TAP5-704
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: quickstart, tapestry-core
>    Affects Versions: 5.1.0.5
>            Reporter: John Crim
>
> Repro steps:
> 1. Run the Tapestry quickstart archetype (v 5.1.0.5) in NetBeans
> 2. Run it in the latest version of Tomcat (6.0.18). (note that NetBeans does the equivalent of running the exploded WAR in the /target dir directly within Tomcat)
> 3. View the site in a browser (to start Tapestry)
> 4. Undeploy the webapp in the Server window
> 5. Rebuild the webapp (mvn clean package) and try to deploy it. - the clean will fail with an error like:
> Failed to delete directory: C:\dev\tapestry\webAppB\target. Reason: Unable to delete file C:\dev\tapestry\webAppB\target\webAppB\WEB-INF\lib\antlr-runtime-3.1.1.jar
> In short, this flaw adds significant time to each iteration during development.  And, if a developer doesn't understand that Tapestry webapps don't undeploy properly, they can easily waste time with bugs that arise because old code is still running in tomcat.
> The workaround is to shutdown tomcat before rebuilding the webapp (mvn clean) each time.

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


[jira] Closed: (TAP5-704) Tapestry webapp locks files in WEB-INF/lib, preventing clean re-deploy without restarting Tomcat.

Posted by "Thiago H. de Paula Figueiredo (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/TAP5-704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thiago H. de Paula Figueiredo closed TAP5-704.
----------------------------------------------

    Resolution: Invalid

Tomcat is locking the JAR files, not Tapestry, so it's not a Tapestry issue. Take a look at http://tomcat.apache.org/tomcat-6.0-doc/config/context.html and search for http://tomcat.apache.org/tomcat-6.0-doc/config/context.html.

> Tapestry webapp locks files in WEB-INF/lib, preventing clean re-deploy without restarting Tomcat.
> -------------------------------------------------------------------------------------------------
>
>                 Key: TAP5-704
>                 URL: https://issues.apache.org/jira/browse/TAP5-704
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: quickstart, tapestry-core
>    Affects Versions: 5.1.0.5
>            Reporter: John Crim
>
> Repro steps:
> 1. Run the Tapestry quickstart archetype (v 5.1.0.5) in NetBeans
> 2. Run it in the latest version of Tomcat (6.0.18). (note that NetBeans does the equivalent of running the exploded WAR in the /target dir directly within Tomcat)
> 3. View the site in a browser (to start Tapestry)
> 4. Undeploy the webapp in the Server window
> 5. Rebuild the webapp (mvn clean package) and try to deploy it. - the clean will fail with an error like:
> Failed to delete directory: C:\dev\tapestry\webAppB\target. Reason: Unable to delete file C:\dev\tapestry\webAppB\target\webAppB\WEB-INF\lib\antlr-runtime-3.1.1.jar
> In short, this flaw adds significant time to each iteration during development.  And, if a developer doesn't understand that Tapestry webapps don't undeploy properly, they can easily waste time with bugs that arise because old code is still running in tomcat.
> The workaround is to shutdown tomcat before rebuilding the webapp (mvn clean) each time.

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


[jira] Closed: (TAP5-704) Tapestry webapp locks files in WEB-INF/lib, preventing clean re-deploy without restarting Tomcat.

Posted by "Thiago H. de Paula Figueiredo (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/TAP5-704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thiago H. de Paula Figueiredo closed TAP5-704.
----------------------------------------------

    Resolution: Invalid

Tomcat is locking the JAR files, not Tapestry, so it's not a Tapestry issue. Take a look at http://tomcat.apache.org/tomcat-6.0-doc/config/context.html and search for http://tomcat.apache.org/tomcat-6.0-doc/config/context.html.

> Tapestry webapp locks files in WEB-INF/lib, preventing clean re-deploy without restarting Tomcat.
> -------------------------------------------------------------------------------------------------
>
>                 Key: TAP5-704
>                 URL: https://issues.apache.org/jira/browse/TAP5-704
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: quickstart, tapestry-core
>    Affects Versions: 5.1.0.5
>            Reporter: John Crim
>
> Repro steps:
> 1. Run the Tapestry quickstart archetype (v 5.1.0.5) in NetBeans
> 2. Run it in the latest version of Tomcat (6.0.18). (note that NetBeans does the equivalent of running the exploded WAR in the /target dir directly within Tomcat)
> 3. View the site in a browser (to start Tapestry)
> 4. Undeploy the webapp in the Server window
> 5. Rebuild the webapp (mvn clean package) and try to deploy it. - the clean will fail with an error like:
> Failed to delete directory: C:\dev\tapestry\webAppB\target. Reason: Unable to delete file C:\dev\tapestry\webAppB\target\webAppB\WEB-INF\lib\antlr-runtime-3.1.1.jar
> In short, this flaw adds significant time to each iteration during development.  And, if a developer doesn't understand that Tapestry webapps don't undeploy properly, they can easily waste time with bugs that arise because old code is still running in tomcat.
> The workaround is to shutdown tomcat before rebuilding the webapp (mvn clean) each time.

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