I am on integrating the suggestions. But there is one point I need help: Robert gave a complete new source [1] as attachement to the RFE [2]. Do we need a CLA?
Jan [1] http://issues.apache.org/bugzilla/showattachment.cgi?attach_id=11932 [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=29743 > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Gesendet am: Mittwoch, 23. Juni 2004 13:18 > An: [EMAIL PROTECTED] > Betreff: AW: Issues with <modified /> selector. > > I´ll have a deeper look into that > (but now I have to ensure that my new computer is able to run > - the old was > damaged :( > > > Jan > > > > -----Ursprüngliche Nachricht----- > > Von: Robert Rice [mailto:[EMAIL PROTECTED] > > Gesendet am: Dienstag, 22. Juni 2004 20:23 > > An: [EMAIL PROTECTED] > > Betreff: Issues with <modified /> selector. > > > > Recently, I submitted two bugs related to the modified selector. > > > > Bug 29742 addresses the issue that the Modified selector > > doesn't allow > > algorithm or comparator selection. Only the default choices > > of "digest" > > and "equal" respectively are allowed. > > > > I have created a bug fix for the modified selector that > > addresses this > > issue. > > In the bug fix, the algorithm and comparator initialization > > logic has been > > changed to allow choosing away from default. > > > > At the same time, I have created another algorithm type, > > "checksum", that > > makes > > use of the java.util.zip.Checksum interface. It is chosen by > > setting the > > alogrithm attribute to "checksum" ( <modified > > algorithm="checksum" /> ). > > > > This checksum allows the choice of CRC32 or Alder32, which utilize > > java.util.zip.CRC32 and java.util.zip.Adler32 respectively. > > This choice > > is made > > by setting the algorithm.algorithm parameter to "CRC" or > > "ADLER", with the > > default being "CRC" ( <modified algorithm="checksum"><param > > name="algorithm.algorithm" value="ADLER" /></modified> ) > > > > How do I submit such changes for evaluation and possible inclusion? > > > > Bug 29743 addresses a bigger issue in that the modified > > selector has poor > > cachefile save performance. The architecture of the selector > > framework > > dictates that the selector is notified of files, one at a > > time, through > > the isSelected method. It is at this method call, that the cache > > properties file is saved. This properties file is saved > every time a > > file modification is found, possibly as many times as there > > are files in > > the fileset. This leads to poor performance when process > > large filesets > > with multiple changes, in my case around 15000. > > > > I would like to delay the saving of the file until we are > > finished with > > the fileset or finished with the selector. It looks to me, > like this > > requires the addition of one of more methods to the selector > > framework, > > likely to BaseSelector. > > > > In the case of the modified selector, we may be able to get > away with > > knowing we are finished with the selector through some method > > call like > > "tearDown". At this point, the modified selector could save its > > properites file. > > > > Another option is to add filesetListener type of behavior to > > the BaseSelector. > > This would notify a selector when a fileset selection has > started and > > ended. With this option, the modified selector could save its > > properties > > file at the end of fileset selection. > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > >
