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
