hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David J. M. Karlsen" <>
Subject Re: Obtaining the registry
Date Thu, 11 Nov 2004 20:50:23 GMT
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 = 
        theInstance = new HiveMindRegistrySingleton();

    static final Registry getRegistry(){
        return registry;

    private HiveMindRegistrySingleton(URLResource urlresource){
        String URL = System.getProperty("hivemind.configfile", 
       URLResource urlresource = new URLResource(url);
        RegistryBuilder regBuilder = new RegistryBuilder();
        ClassResolver resolver = new DefaultClassResolver();
        regBuilder.processModules( resolver );"Config-URL for HiveMind: " + urlresource.toString());
        regBuilder.processModule( resolver, urlresource );
        registry = regBuilder.constructRegistry(Locale.getDefault());"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
><> wrote:
>>i feel this should be a safe and one-liner operation.
>>But referring to:
>>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
>>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:
For additional commands, e-mail:

View raw message