geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacek Laskowski <>
Subject Re: [jira] Created: (GERONIMO-132) Adds deployments based on their modification time
Date Tue, 23 Dec 2003 12:02:31 GMT
Hi Jeremy,

I like the comment. It seems it's not as easy as I initially thought. 
Let me take a few moments more to think about it. I'll try to get an 
overall picture of how the planners/scanner work.

In the meantime, do we close the issue in Jira with some status or leave 
it open?


Jeremy Boynes wrote:
> 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.

View raw message