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
><david@davidkarlsen.com> 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/impl/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(ConfigurationPoint),
>>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: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
|