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/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
