I am not sure what you mean. Can you explain more? --jason
Quoting David Jencks <[EMAIL PROTECTED]>: > 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 > > > > > ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
