On 2002.04.22 01:06:14 -0400 Jason Dillon wrote: > I am not sure what you mean. Can you explain more? > > --jason
scanner1 looks at dir1 with jar1, jar2....jar 100 in it scanner 2 looks at dir2 with jar101...jar200 in it. I haven't checked recently but I thought scanning happened in its own thread. scanner1 starts, new thread deploys jar1... scanner2 starts, new thread deploys jar101,jar102,jar103 thread 1 deploys jar2,jar3. thread2 finishes jar200 thread1 is still on jar50. If you have one scanner, they will be deployed in order 1...200. Maybe I am wrong about the threads. david jencks > > > 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
