geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan (Created) (JIRA)" <>
Subject [jira] [Created] (GERONIMO-6318) Provide a fastdeploy option to avoid copying the application file in the deployment process
Date Tue, 03 Apr 2012 05:56:33 GMT
Provide a fastdeploy option to avoid copying the application file in the deployment process

                 Key: GERONIMO-6318
             Project: Geronimo
          Issue Type: Improvement
      Security Level: public (Regular issues)
          Components: deployment
    Affects Versions: 3.0-beta-1
            Reporter: Ivan
            Assignee: Ivan
             Fix For: 3.0-beta-2

while deploying one common application in the Geronimo server, now we copy the files for three
a. Copy the deployed application file to a temp directory, there are some comments in the file :

 // todo jar url handling with Sun's VM on Windows leaves a lock on the module file preventing
            // to address this we use a gross hack and copy the file to a temporary directory
            // the lock on the file will prevent that being deleted properly until the URLJarFile
            // been GC'ed.

b. Extract the application file to a temp directory
c. Copy the extracted application files to the corresponding repository directory.

I am thinking that we may only do one time copying action, which is to extract the application
file to the repository directory directly.
For #a, after checking the svn log, it is added long long ago, I am not sure whether we still
have this issue, in my environment, it looks to me that the file is not locked, may be this
only occurs in some special scenarios.
For #b, since we also keep the application extracted in the repository directory, think that
it is possible to skip that.

My idea is to introduce a 'fast.deploy' system property, and it is enabled by default, with
this property configured, the deployer will skip the step #a and #b.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message