Patrick, ATM, I think you could create a subclass of the FileAlterationObserver and re-implement FileAlterationObserver.checkAndNotify(). You'll have to decide what to do in the case of file trees. Do you want to sort by timestamp for all files in the tree or just sort files in the current folder being processed. At least, that's the consideration needed for a general solution. You'll notice that any solution will likely need a second file comparator that sorts files for presentation to listeners in the customized order. The current comparator is needed as is since it is used for event and event type detection.
Let me know what you think and you are considering providing a PR on GitHub. TY! Gary On 2024/01/29 23:15:17 Gary Gregory wrote: > YW. I think you could sort files if I refactor the monitor a bit such that > you can plug in a custom comparator (it's already there internally)... > > Gary > > On Mon, Jan 29, 2024, 5:19 PM Thomas, Patrick R > <patrick.r.tho...@questdiagnostics.com.invalid> wrote: > > > Thanks for the quick response. I will need to test its behavior for lost > > connections. > > > > Based on what I have discovered so far, I will have to create my own > > monitor. I need to create a list of new files from all of the monitored > > folders during each pass and then sort them by date/time to make sure they > > are processed in the correct order. > > > > It doesn't seem to notify about files that already exist. I will have to > > add this as well, although it is optional because it doesn't work correctly > > in my current system. > > > > Thank you, > > > > Patrick R. Thomas > > > > -----Original Message----- > > From: Gary Gregory <garydgreg...@gmail.com> > > Sent: Monday, January 29, 2024 2:05 PM > > To: Commons Users List <user@commons.apache.org> > > Subject: Re: Evaluating FileAlterationMonitor > > > > CAUTION! This email originated outside of Quest Diagnostics. DO NOT click > > links or open attachments unless you recognize the sender and know the > > content is safe. Please report suspicious emails to: > > ph...@questdiagnostics.com > > > > > > The documentation we have is on the site and the Java document. If you > > have improvements on the code or documentation, we welcome them as PRs on > > GitHub. > > > > The monitor thread wakes up, looks around, and fires events. If a file is > > not there because a network connection is broken, this will show up as a > > deleted file. > > > > YYMV since we do not test this use case in unit tests. > > > > Gary > > > > > > On Mon, Jan 29, 2024, 1:45 PM Thomas, Patrick R > > <patrick.r.tho...@questdiagnostics.com.invalid> wrote: > > > > > Hello, > > > > > > Our application monitors multiple folders for new files to import. > > > Once a new file is detected, it is moved to a working folder where it > > > is processed and then moved to an archive folder. Files are never > > > updated, and ones that are deleted before processing are skipped. The > > > current implementation has the folders on the same server as the > > > application. We are using Java's WatchService to do the monitoring. > > > For security reasons, we have to move to a new design where the > > > folders will be on a different server. My understanding is that > > > WatchService will not work well for this. I am evaluating > > > FileAlterationMonitor as an alternative. I have several questions. Is > > > there additional documentation I can reference? If the folder being > > > monitored is on a mapped network drive and the connection is lost, > > > what happens? Can the monitor detect files that already exist when it > > > starts? It is also important that the files remain in the order they > > were created to be imported. > > > > > > Any help would be greatly appreciated. > > > > > > Thank you, > > > > > > Patrick R. Thomas > > > Software Engineer > > > > > > > > > ______________________________________________________________________ > > > The contents of this message, together with any attachments, are > > > intended only for the use of the person(s) to which they are addressed > > > and may contain confidential and/or privileged information. Further, > > > any medical information herein is confidential and protected by law. > > > It is unlawful for unauthorized persons to use, review, copy, > > > disclose, or disseminate confidential medical information. If you are > > > not the intended recipient, immediately advise the sender and delete > > this message and any attachments. > > > Any distribution, or copying of this message, or any attachment, is > > > prohibited. > > > > ______________________________________________________________________ > > The contents of this message, together with any attachments, are intended > > only for the use of the person(s) to which they are addressed and may > > contain confidential and/or privileged information. Further, any medical > > information herein is confidential and protected by law. It is unlawful for > > unauthorized persons to use, review, copy, disclose, or disseminate > > confidential medical information. If you are not the intended recipient, > > immediately advise the sender and delete this message and any attachments. > > Any distribution, or copying of this message, or any attachment, is > > prohibited. > > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
