SF mailing lists suck ass. I am not seeing email that I wrote like 3 days ago... this blows.
* * * If references use home objects to recover there linkage then can't they use JNDI port? --jason Bill Burke wrote: >Maybe the invokers should run on a hard-coded port. With a hard-coded port, >I think references can live beyond the life of the server. Or maybe I don't >know what I'm talking about :) > >>-----Original Message----- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED]]On Behalf Of Jason >>Dillon >>Sent: Wednesday, April 03, 2002 4:49 PM >>To: marc fleury >>Cc: Jboss-Development@Lists. Sourceforge. Net >>Subject: Re: [JBoss-dev] Todo: multiple instances detection >> >> >>Not sure that an external component is the best choice for this... but I >>have not really thought it through. >> >>On a related note, I sent mail a while ago asking about the web service >>for class loading wtr having it use an anonymous port. If we set the >>default RMI port to anonymous too, then we only have naming, >>jmx-html-adapter and web ports to deal with. Once the jmx-html-adapter >>is a .war, then we only have naming and web. >> >>Does anyone know if it is possible to setup on public port, which then >>attaches to other anonymous/random ports, switching based on the >>content. This would make it look to clients like there was only one >>port, but really there could be many, but the actual numer would >>not matter. >> >>Something like this could (assuming it is possible) would make it easy >>to integrate thirdparty plugins into the single port scheme which simply >>need a port, with out them having to know about a special component or >>conform to a specific api to select a random port or whatever... >> >>--jason >> >> >>marc fleury wrote: >> >>>there should be a service that is part of the first services >>> >>coming up and >> >>>that detects if other JBoss systems are running on the same physical >>>machines, this is to avoid port conflict as some services are >>> >>holding on to >> >>>some ports (e.g. naming on 1099, detached RMI, clustered RMI). >>> >>>We would then not start the naming as a duplicate nor the >>> >>detached RMI but >> >>>we would use the clustered RMI by increasing the connection port. >>> >>>This will enable people to run multiple instances of JBoss >>> >>without having to >> >>>manually change the stuff all the time. At least on the >>> >>services we provide >> >>>we should show how these behave. >>> >>>marcf >>> >>> >>>_______________________________________________ >>>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 >> _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
