Hi, Jason.
Yes, clearly the logic for this needs to be improved and generalized to
ask the known sniffers if they recognize each new file rather than using
a fixed list of file types.
We should keep the logic that handles slowly-copied files, at least in
some form, in the auto-deployer if we can. By the time a deployer is
running it would be best if the deployer could assume that the file or
directory is ready for processing, so ideally we would be able to avoid
even trying to run a deployer until the copy operation has completed.
Whether the autodeployer wait-until-copy-is-complete logic can be clever
enough to do that with the sniffer/deployer/archive handler architecture
remains to be seen. The old (and current) implementation would attempt
to open the file as a JAR file and, if that failed, assume that a slow
copy was in progress. It would then wait for the file to stabilize
before trying to deploy the app. In v3 we can no longer assume that all
deployable files will be JARs so this part of the logic would need to
use some other approach. I have some ideas but have not had a chance to
try them out yet. Soon, I hope.
(Earlier I opened this issue
<
https://glassfish.dev.java.net/issues/show_bug.cgi?id=4974> to track
the need to check on and clean up this logic.)
- Tim
Jason Lee wrote:
> Tim, if you're around this week, please feel free to bring this to the
> attention of the appropriate parties. :)
>
> At any rate, last week over Thai, we discussed the code in the
> autodeployer that makes sure the files found in the AD directory were
> Java archives of some sort. You wondered if that code was still in
> the execution path. I did some testing last night, and it indeed is.
> I haven't gotten to the bits that check to make sure an archive is
> able to be opened (to make sure the copy command has completed before
> trying to deploy the archive), but I'd guess that it, too, is still
> being executed. My question is this: does any of that need to be?
> If I understand the architecture correctly, the sniffer/container
> responsible for those archives should be doing the test and not this
> part of the code. If I'm right on that, then that bit of code can be
> excised.
>
> Thoughts/direction, anyone? I may try commenting out that code in the
> interim and see what happens...
>
> --
> Jason Lee, SCJP
> Software Architect -- Objectstream, Inc.
> Mojarra and Mojarra Scales Dev Team
> https://mojarra.dev.java.net
> https://scales.dev.java.net
> http://blogs.steeplesoft.com