I agree with David.
If we wanted to aproach SysV runlevels, our conf directories would have to be the ones that would be called level1,...,level6 I also want to make a quick point on something that has bothered me since the begining. I use multiple conf's in a single JBoss installation. This forces me to also create multiple deploy directories since I don't want the same deployments for all the configurations. My beef is that it seems natural to me to have a different set of deployments for different configurations, but the way the directory structure is right now does not lend itself too well for that type of organization. Am I just smoking crack or something?? Hiram >From: David Budworth <[EMAIL PROTECTED]> >To: Jason Dillon <[EMAIL PROTECTED]> >CC: David Jencks <[EMAIL PROTECTED]>, jboss-dev ><[EMAIL PROTECTED]> >Subject: Re: [JBoss-dev] (rh) startup levels proposal and questions. >Date: Mon, 10 Dec 2001 19:16:43 -0800 > >I would also like to make sure that any docs, don't refer to this >(assuming it gets implemented) as being like SysV runlevels (like >Linux,Solaris,etc..) > >runlevels aren't even remotely working like this. Each runlevel in a >SysV init style is a self contained state. > >Meaning, "init 5" does not do init 1,2,3,4,5. Runlevel 5, contains >every thing that should/should not be running when at level 5. > >That's why they have >S01xxx >S02yyy >K01zzz > >The K??* scripts run first, then all S??* run, in sorted order. > >I do wonder though, will splitting the directories up make >administration more difficult? > >If you want guaranteed deployment order, you could always name all the >items in deploy/* with numbers at the start. > >ie: >00hsqldb-service.xml >00blah-service.xml >01cluster-service.xml > >Then just have the deployer always ensure to sort the dir list, and >process in order. > >That way, in Bill's case, he could just call his SAR (or whatever), >99Bill.sar > >Guaranteed to deploy after the ones that sort first. > >Having the whole runlevel type thing might just confuse people >(especially unix admins, if you don't give them SysV type runlevels) > >Just a thought, > >-David > > >On Mon, 10 Dec 2001, Jason Dillon wrote: > > > > Everything in level1 will be deployed, then everything in level2, etc. > I > > > think this will give enough control over deployment order for almost >all > > > circumstances. (I'd like examples of anything it won't work for). > > > > I think we might want to use different names, as level1-6 might get a >little > > confusing. Perhaps we could assign these levels meaningful names: > > > > bootstrap > > system > > user > > > > Could also nest the structure for better naming too: > > > > system/ > > bootstrap/ > > core/ > > db/ > > cluster/ > > jms/ > > user/ > > whatever/ > > samesame/ > > > > > Now, in Linux you can init 3 or init 6. So far you can't do this >here. Is > > > that a valuable feature for jboss? (i.e. being able to say "deploy >levels > > > 1,2,3. Now deploy 4,5,6. Now undeploy 6, 5, 4, 3) How would it be >used? > > > > Yikes, I hope there aren't any Linux systems that will init 6 and do > > anything short of boot... I hope you mean init 5 (X11). > > > > > Would this be more or less convenient to use than a deployment script > > > facility where each script basically had a list of what is in one of >these > > > level directories? > > > > I don't think that the actual notion of levels makes sence for the AD, >but > > seperating things for ordering certainly does. > > > > --jason > > > > > > _______________________________________________ > > 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 _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
