You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@hivemind.apache.org by "David J. M. Karlsen" <da...@davidkarlsen.com> on 2004/11/11 14:45:28 UTC
Obtaining the registry
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.
David J. M. Karlsen - +47 90 68 22 43
http://www.davidkarlsen.com
http://mp3.davidkarlsen.com
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
RE: Obtaining the registry
Posted by James Carman <ja...@carmanconsulting.com>.
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:david@davidkarlsen.com]
Sent: Thursday, November 11, 2004 3:50 PM
To: hivemind-user@jakarta.apache.org
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
><da...@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/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: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
Re: Obtaining the registry
Posted by "David J. M. Karlsen" <da...@davidkarlsen.com>.
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
><da...@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
Re: Obtaining the registry
Posted by Howard Lewis Ship <hl...@gmail.com>.
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
<da...@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.
>
> David J. M. Karlsen - +47 90 68 22 43
> http://www.davidkarlsen.com
> http://mp3.davidkarlsen.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org