[EMAIL PROTECTED] 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
