I really hope I'm not throwing more fuel on any fires... If you have one scanner whose scanned directories can be ordered individually, you still get to specify the startup order of the directories by how they are listed in the single scanner.
With more than one scanner, this may be less deterministic, considering each scanner runs in a separate thread (is this true?). Maybe there's a way out, I haven't thought of it. david jencks On 2002.04.21 21:09:09 -0400 Jason Dillon wrote: > > I want a distinction between directories to be scanned, and URLs to be > > deployed. This goes back to an earlier patch (that I never checked in) > for > > URLDeploymentScanner. If you specify a URL that is the base of an > exploded > > archive, then currently the scanner scans that directory. It should, > > instead, deploy the directory. > > Right, so like I said before I think this should go into another scanner. > > > The solution you presented at the time was to create an alternate > scanner > > for this purpose. I don't like that since it violates the concept of > > exploded archives being treated just like their packaged counterparts. > > What? No it does not at all. It is just the same, it is just a matter > of > which scanner it came from. > > For example, if using a cache in between UDS and MD it now has to know > how to > handle a directory... blah, screw that. > > Make a seperate scanner, perhaps if you must bring > DirectoryDeploymentScanner > back to life and put in all of your directory specific stuff. It has no > business in UDS, perhaps even the bit for scanning a directory url for > files > has no business in there. > > Please do not complicate UDS when you can create a simple alternative DS > which > can be used in replacement or in conjunction with the UDS. > > The system is designed to take more than one DS for just this reason... > to > allow for different scanning behavior. This is why I seperated the > common > scanning loop code into ADS. > > We do not want to get back into the monolithic component business again. > > Design with plugablility then make use of it when you need new > functionality. > If required refactor the existing components to better seperate the > plugability... but don't go making simple components complicated when you > > could have easily created a replacment or peer to gain the same result. > > *sigh* > > --jason > > > ------------------------------------------------- > This mail sent through IMP: http://horde.org/imp/ > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
