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
