Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (athena.apache.org: domain of xhhsld@gmail.com designates
 74.125.82.50 as permitted sender)
MIME-Version: 1.0
Date: Sun, 1 Apr 2012 09:29:13 +0800
Message-ID: 
 <CALS1ypDA3FryseEFDmBTsoTQ4HDsTAHg9_61O4c8Nn9WArjH7Q@mail.gmail.com>
Subject: Reduce the file copying in the application deployment
From: Ivan <xhhsld@gmail.com>
To: dev@geronimo.apache.org
Content-Type: multipart/alternative; boundary=f46d041825585835a604bc94002d

--f46d041825585835a604bc94002d
Content-Type: text/plain; charset=ISO-8859-1

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

 // todo jar url handling with Sun's VM on Windows leaves a lock on the
module file preventing rebuilds
            // 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 has
            // 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. Thoughts ?
-- 
Ivan

--f46d041825585835a604bc94002d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi, while deploying one common application in the Geronimo server, now we c=
opy the files for three times,=A0<div>a. Copy the deployed application file=
 to a temp directory, there are some comments in the Deployer.java file :</=
div>

<div><br></div><div><div>=A0// todo jar url handling with Sun&#39;s VM on W=
indows leaves a lock on the module file preventing rebuilds</div><div>=A0 =
=A0 =A0 =A0 =A0 =A0 // to address this we use a gross hack and copy the fil=
e to a temporary directory</div>

<div>=A0 =A0 =A0 =A0 =A0 =A0 // the lock on the file will prevent that bein=
g deleted properly until the URLJarFile has</div><div>=A0 =A0 =A0 =A0 =A0 =
=A0 // been GC&#39;ed.</div></div><div><br></div><div>b. Extract the applic=
ation file to a temp directory</div>

<div>c. Copy the extracted application files to the corresponding repositor=
y directory.</div><div><br></div><div>I am thinking that we may only do one=
 time copying action, which is to extract the application file to the repos=
itory directory directly.</div>

<div>For #a, after checking the svn log, it is added long long ago, I am no=
t 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 scenar=
ios.</div>

<div>For #b, since we also keep the application extracted in the repository=
 directory, think that it is possible to skip that.</div><div><br></div><di=
v>My idea is to introduce a &#39;fast.deploy&#39; system property, and it i=
s enabled by default, with this property configured, the deployer will skip=
 the step #a and #b. Thoughts ?</div>
<div><div>-- <br>Ivan<br>
</div></div>

--f46d041825585835a604bc94002d--