Not exactly, Bill. By default the mapping should just return the default mapping requested by the system. If and only if the user wants to run multiple copies of JBoss on a single machine, do they add a configuration mapping to the mapper.
I should be no more complex then what we currently have with the ability to centrally mange ports. This is the best of both worlds if you ask me. Anyway, GUIs need to run on top of JMX (configuration files), because not all hardware has a graphical display. -dain Bill Burke wrote: > 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 > _______________________________________________________________ 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
