The RegistryBuilder.constructDefaultRegistry() method does not return the same instance each time. It actually constructs a new registry each time it is called. So, if you call that method multiple times in multiple threads, you will get multiple copies of the same registry.
-----Original Message----- From: David J. M. Karlsen [mailto:[EMAIL PROTECTED] Sent: Thursday, November 11, 2004 3:50 PM To: [email protected] Subject: Re: Obtaining the registry Howard Lewis Ship wrote: So to answer mye question: calling this code: Registry registry = RegistryBuilder.constructDefaultRegistry() simultaineously in a multi-threaded environment from different execution paths imply no threading-problems as long as the registry has been initialized for the first time already? Anyway, I've put this into a utilityClass: public class HiveMindRegistrySingleton { static private final Log log; static private final String defaultSystemProperty; static private final HiveMindRegistrySingleton theInstance; static private Registry registry; static { log = LogFactory.getLog(HiveMindRegistrySingleton.class); //defaultSystemProperty = "file:/META-INF/hivemind.xml"; defaultSystemProperty = "file:/some/standard/configpath/i/live/under/hivemodule.xml"; theInstance = new HiveMindRegistrySingleton(); } static final Registry getRegistry(){ return registry; } private HiveMindRegistrySingleton(URLResource urlresource){ String URL = System.getProperty("hivemind.configfile", defaultSystemProperty) URLResource urlresource = new URLResource(url); RegistryBuilder regBuilder = new RegistryBuilder(); ClassResolver resolver = new DefaultClassResolver(); regBuilder.processModules( resolver ); log.info("Config-URL for HiveMind: " + urlresource.toString()); regBuilder.processModule( resolver, urlresource ); registry = regBuilder.constructRegistry(Locale.getDefault()); log.info("Registry bootstrapped"); } } So that I can have my hivemodule.xml outside the EAR. And reference to different versions by setting system-properties on the server, or choose not to to get the default version. I want to keep it outside the EAR because administrators may have to edit it due to change in infrastructure - and I have to deliver several different versions for different environments. >The general use case for HiveMind is either part of a GUI, or part of >a servlet container. > >In the former, you control the code paths leading up to and beyond the >construction of the Registry, just as you control the code paths for >creating your GUI (which also has thread safety implications). > >In a servlet container, the HiveMindFilter is the sole object that >should be creating the Registry. HiveMind's approach is compatible >with the startup semantics of a servlet container. > >I think you are making a problem out of a non-problem. > >On Thu, 11 Nov 2004 14:45:28 +0100 (CET), David J. M. Karlsen ><[EMAIL PROTECTED]> wrote: > > >>i feel this should be a safe and one-liner operation. >> >>But referring to: >>http://jakarta.apache.org/hivemind/hivemind/apidocs/org/apache/hivemind/im pl/RegistryBuilder.html >> >>Stating that: >> >>A note about threadsafety: The assumption is that a single thread will >>access the RegistryBuilder at one time (typically, a startup class within >>some form of server or application). Code here and in many of the related >>classes is divided into construction-time logic and runtime logic. Runtime >>logic is synchronized and threadsafe. Construction-time logic is not >>threadsafe. Methods such as >>org.apache.hivemind.impl.RegistryInfrastructureImpl#addModule(Module), >>org.apache.hivemind.impl.ModuleImpl#addConfigurationPoint(ConfigurationPoi nt), >>ConfigurationPointImpl.addContribution(Contribution)and the like are >>construction-time. Once the registry is fully constructed, it is not >>allowed to invoke those methods (though, at this time, no checks occur). >> >>I wonder if this is true for >> >>Registry registry = RegistryBuilder.constructDefaultRegistry(); too? >> >>If so I will make a singletonwrapper around this - and it should probably >>be imported into one of the future releases. >> >>Another thing: >> >>HiveMind doesn't accept the hivemodule.xml filepath to be resolved through >>a systemproperty defining a URL? I'd like to add this feature into the >>same component as well. >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
