Why not setup up an example (or some other name) configuration and put the stuff that shouldn't be in default there? This will keep things simple (small number of configs to maintain in the release dist). I would expect that most first time users will want to see the basics (aka default config), then once they get a handle on the greatness of JBoss they will want to roll there own configuration.
--jason Bill Burke wrote: >Somebody make a decision, and I'll do it. But I agree clustering should not >be in the default configuration. > >>-----Original Message----- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED]]On Behalf Of Sacha >>Labourey >>Sent: Thursday, February 28, 2002 3:12 AM >>To: marc fleury; Andreas Schaefer; Scott M Stark; >>[EMAIL PROTECTED] >>Subject: RE: [JBoss-dev] Fw: [JBoss-user] Multiple JBOSS 3.0 developers >>and clustering >> >> >>Hello, >> >>I also think that clustering shouldn't be deployed by default. >>Nevertheless, >>the problem was to have, in the official distribution, a place >>where to put >>optional service.xml, sar, ... so that any user can pick one and >>deploy it. >>In the first alpha, cluster-service.xml wasn't present in the distribution >>and this was a problem for users just downloading the dist. Which >>is why it >>was put in deploy. >> >>Either we can make a specific config folder for clustering (as Marc >>suggests) or, at least, we provide a "plugins" or "optional" package where >>we can put xml/xAR that shouldn't be deployed by default. >> >>Cheers, >> >> >> Sacha >> >> >>>-----Message d'origine----- >>>De : [EMAIL PROTECTED] >>>[mailto:[EMAIL PROTECTED]]De la part de marc >>>fleury >>>Envoyé : jeudi, 28 février 2002 10:31 >>>À : Andreas Schaefer; Scott M Stark; >>>[EMAIL PROTECTED] >>>Objet : RE: [JBoss-dev] Fw: [JBoss-user] Multiple JBOSS 3.0 developers >>>and clustering >>> >>> >>>which brings us to the configuration story going around the list for the >>>past month or so... >>> >>>oka, I will just do a summary since I haven't really sat down >>> >>and thought, >> >>>just sat here on my ass going "nonono" at Jason and David on the "all in >>>deploy" proposal. >>> >>>OK >>> >>>What I don't like, really, is the SAR format. Having the files in >>>there is a >>>pain in the ass, there is no way to get at the configuration >>>simply. End of >>>story. It is the same nightmare with the JAR in EJB, dumb >>> >>packaging. Sure >> >>>packaging is nice in some cases (I drop everything) but really having to >>>open the SAR is just too big pain, a bigger pain than the nice >>>stuff, in my >>>mind the tradeoff is clear. SAR no, *service.xml yes. >>> >>>Don't go apeshit on me now, we will still support the SAR, and >>>even provide >>>one of them in the default config, but we should NOT make it >>> >>pervasive in >> >>>our distributions. >>> >>>The classes should go under a "classes" directory (today >>>/lib/ext/) which is >>>centralized and will make central downloading of files simple. >>> >>>Then the question was "multiple service.xml vs one service.xml". I am >>>actually thinking that David was right on that one. It is nice >>> >>to remove >> >>>just the service.xml file from a given config. The only problem is that >>>once the file is removed you need a copy of it to make it work again (as >>>opposed to comments in the configuration, but I *kinda* like the idea of >>>looking at a "deploy" directory and seeing all the files there >>>and each one >>>represents a my-name-that-means-something-service.xml and the >>>admin gets an >>>idea about what is deployed. So David, please accept my >>>apologies, the dumb >>>idea is the "SAR" stuff not the breaking, breaking is ok. >>> >>>The final idea floating around is that of multiple configurations. I am >>>thinking that there are many deploy directories in the >>>MainDeployer now (it >>>is capable of scanning many directories not just the /deploy one) and we >>>should take advantage of this. Maybe we could have >>>/conf/default/<bare>-service.xml >>>/conf/medium/<more>-service.xml >>>/conf/nineyards/<everything>-service.xml >>> >>>like we have today but *watched* by the main deployer. >>> >>>I think it is pretty close to a proposal that was already out. >>> >>>And that is pretty much it imho. If you want to add something do it... >>> >>>marcf >>> >>>PS: so in the case below it would mean >>> >>>the clustering classes are in lib/ext (or /classes/) as is today, >>>forget SAR >>>by default. >>>in conf/default we have a breakdown of bla-bla-service.xml that >>> >>get picked >> >>>up by the auto-deployer on first run (boot), this David can (and maybe >>>should) be as broken down as possible. Removing a service does mean >>>removing the file. >>> >>>in conf/clustering/ we copy the configuration and we add the >>>clustering-service.xml file that contains the configuration for >>> >>this guy. >> >>>voila. Running it says sh run.sh clustering >>> >>>something like that >>> >>> >>> >>> >>>|-----Original Message----- >>>|From: [EMAIL PROTECTED] >>>|[mailto:[EMAIL PROTECTED]]On Behalf Of >>>|Andreas Schaefer >>>|Sent: Wednesday, February 27, 2002 9:57 PM >>>|To: Scott M Stark; [EMAIL PROTECTED] >>>|Subject: Re: [JBoss-dev] Fw: [JBoss-user] Multiple JBOSS 3.0 developers >>>|and clustering >>>| >>>| >>>|Hi >>>| >>>|If you running a laptop without the network card and therefore >>>|network services are down the start of the cluster will hang >>>|JBoss forever. >>>| >>>|I think clustering should not be part of the default configuration >>>|because it should used on purpose (for distribution). >>>|On the other hand maybe clustering should be part of CVS to >>>|let it run as a test. >>>| >>>|Andy >>>| >>>|----- Original Message ----- >>>|From: "Scott M Stark" <[EMAIL PROTECTED]> >>>|To: <[EMAIL PROTECTED]> >>>|Sent: Wednesday, February 27, 2002 9:36 PM >>>|Subject: [JBoss-dev] Fw: [JBoss-user] Multiple JBOSS 3.0 developers and >>>|clustering >>>| >>>| >>>|> This is a good comment. Should clustering really be enabled >>>|> as part of the default configuration? >>>|> >>>|> xxxxxxxxxxxxxxxxxxxxxxxx >>>|> Scott Stark >>>|> Chief Technology Officer >>>|> JBoss Group, LLC >>>|> xxxxxxxxxxxxxxxxxxxxxxxx >>>|> ----- Original Message ----- >>>|> From: "Stephen Coy" <[EMAIL PROTECTED]> >>>|> To: <[EMAIL PROTECTED]> >>>|> Sent: Wednesday, February 27, 2002 7:38 PM >>>|> Subject: [JBoss-user] Multiple JBOSS 3.0 developers and clustering >>>|> >>>|> >>>|> > Hi, >>>|> > >>>|> > We have found that if you have multiple developers on the >>>same network >>>|> > trying to run the 3.0 beta or later at the same time, the default >>>|> > configuration causes them to try and cluster with each other >>>(I think). >>>|> > >>>|> > Anyway, removing the "cluster-service.xml" file from the deploy >>>|> > directory certainly fixes the problem. >>>|> > >>>|> > To be more specific, jboss startup would hang while trying >>> >>to deploy >> >>>|> > cluster-service.xml if someone else already has one running. >>>|> > >>>|> > Steve Coy >>>|> > Whitesmiths Australia >>> >> >>_______________________________________________ >>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 > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
