All I'm saying is that this is just another configuration file in an already complicated system. Energies might be spent in a better direction. I'll shut up now...
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Scott > M Stark > Sent: Tuesday, May 21, 2002 11:56 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers > environment > > > Ok, and you will have that ready by? > xxxxxxxxxxxxxxxxxxxxxxxx > Scott Stark > Chief Technology Officer > JBoss Group, LLC > xxxxxxxxxxxxxxxxxxxxxxxx > ----- Original Message ----- > From: "Bill Burke" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, May 21, 2002 8:32 AM > Subject: RE: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers > environment > > > > Guys, > > > > I've been thinking about this. Wouldn't it be better/easier to create a > UI > > configuration tool than do this port mapper stuff? What I mean > is a JBoss > > configuration tool that for each component asks you what port you want > your > > JNDI server to run on, Web server, etc... as well as other config > > information. This tool could be smart enough to determine if > something is > > already running under a certain port and tell you so you have to decide > the > > new port to run under. This stuff would not only be usefull for a > multiple > > developer environment, but would be extremely useful in an Installer and > > management GUI, and IMHO, would be more reep more significant > benefits for > > the JBoss project. > > > > IMHO, what you're proposing would just create ugliness and > complication in > > the code base. But maybe I'm wrong here. I don't know. Do > whatever you > > want. > > > > Bill > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On > Behalf Of Mike > > > Finn > > > Sent: Tuesday, May 21, 2002 8:02 AM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers > > > environment > > > > > > > > > > > > Very basic question, but I have to ask it: how should the service > bindings > > > "service" be exposed? I assume as MBean? MBean with static > port manager > > > bound in JNDI (might have the chicken/egg problem here, since > > > JNDI would be > > > a dependency and JNDI would need to find what port on which > to run...)? > > > > > > #mike > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > > Juha-P Lindfors > > > Sent: Tuesday, May 21, 2002 6:36 AM > > > To: JBoss-dev > > > Subject: Re: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers > > > environment > > > > > > > > > On Mon, 20 May 2002, Dain Sundstrom wrote: > > > > > > > [I moved this to the dev list] > > > > > > > > I think the real power of JMX is you can have disparate components > that > > > > can all talk to a central object without becoming tightly coupled. > > > > > > > > Here is my idea: > > > > > > > > We have an optional port server MBean. Before a service > opens a port > it > > > > checks for the existence of the port server, and if (and only if) it > > > > exists, it asks the port server for a port passing the service name > and > > > > port name (both are just any string). If the port service doesn't > > > > exist, it follows the default code. > > > > > > > > This would require that the MBean wrappers for any serveice > that opens > a > > > > port to follow know about the possibility of a port service, but I > don't > > > > think that is a big deal. Most MBeans already know about many > services. > > > > > > another possibility would be to persist these attributes > containing port > > > numbers to a single location, e.g. config/ports.properties where all > ports > > > would be in a single file. > > > > > > This would not require the MBean developers to change their coding in > any > > > way (Jules point about simple contracts) but would just require us to > > > config the initial server setup for the MBeans in question to use the > same > > > location for these attributes. New user MBeans could also be > configured > to > > > use the same storage. Same approach would work for other system > resources > > > as well (whatever they might be) without having to impose yet another > > > contractual requirement for MBean developers. > > > > > > However, this requires that we convert to using persistent > mbeans, which > > > is a more long term project. Short term your solution is the > easier fix. > > > > > > my .02 > > > > > > -- Juha > > > > > > > > > > > > _______________________________________________________________ > > > > > > Don't miss the 2002 Sprint PCS Application Developer's Conference > > > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > > > > > _______________________________________________ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > _______________________________________________________________ > > > > > > Don't miss the 2002 Sprint PCS Application Developer's Conference > > > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > > > > > _______________________________________________ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > _______________________________________________________________ > > > > Don't miss the 2002 Sprint PCS Application Developer's Conference > > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > > > _______________________________________________ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
