geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jer...@coredevelopers.net>
Subject Re: [jira] Created: (GERONIMO-132) Adds deployments based on their modification time
Date Mon, 22 Dec 2003 01:11:09 GMT
jira@codehaus.org wrote:


> Description: The coming patch modifies
> o.a.g.kernel.deployment.scanner.FileSystemScanner so that it only
> adds a file or directory when its modification time equals to or is
> greater then the time of the last scan
> 

I had concerns with this approach during the initial implementation and 
felt that this was really the job of the Planners rather than the 
scanner - that the scanner should really just report all the currently 
located URLs.

The first was ensuring this worked the same for all scanners, for all 
archive formats, and for packed/unpacked archives.

To meet this requirement, this functionality would need to be 
implemented by all scanners - no only the File scanner this patch 
addresses, but also ones like the WebDAV URL scanner. This may be 
possible but does rely on the web server returning an accurate 
modification time; this could be worse if the webdav scanner tried to 
use the timestamp returned in the PROPFIND request. This might work, but 
was a concern.

There is the question of just when the archive was modified. For a 
packed the modification of the archive itself might be good enough. For 
an unpacked archive though, the modification time of the root directory 
is not a good indicator - for example, adding a new JSP page to the root 
of a WAR would change the modification time of the directory triggering 
redeployment (which is not the desired effect). Also, as multiple files 
get copied into an unpacked archive then it may be inconsistent. I think 
a better solution is to watch the modification time of a specific file 
such as web.xml for a WAR or ejb-jar.xml for an EJB-JAR; however, this 
file will vary depending on the archive type.

Some systems try to provide this by using two URLs - a deployment URL 
and a watch URL. I don't think building this into the scanner is a good 
solution - it is better performed by the planners.

There is also the issue of dependencies between URLs - for example, a 
WAR may depend on an EJB-JAR so even though the WAR's URL has not been 
modified we need to redeploy it to allow for the new EJB-JAR version. 
Resolving these dependencies is the job of the Controller and planners.

Given all that, my belief was that the job of the scanner should be kept 
real simple - return a list of currently known URLs and allow the 
Controller/Planners come up with a deployment plan.

I look forward to other opinions but for now I would -1 this change.

-- 
Jeremy

Mime
View raw message