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
