You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hivemind.apache.org by Knut Wannheden <kn...@gmail.com> on 2007/01/24 16:59:31 UTC
mutability in hivemind 2 registry construction api
Hi all,
I just took a look at the new registry construction API in the 2.0
proposal. I think it looks very good but one thing I'd like to discuss
is the mutability requirements. I'm talking about the various addXxx()
methods and the fact that some Collection objects returned by some
getters must be mutable. Specifically I'd like to discuss if the
mutability in the API is needed and / or desired.
>From what I can work out the mutability of the module definitions is
used by HiveMind for the following things:
1. Module definition construction -- The actual implementations of the
API can use the addXxx() methods to construct the actual module
definition.
2. Merging "hivemind" module definition -- If the user is using the
optional XML support in HiveMind then HiveMind will during registry
construction merge definitions for the "hivemind" module from the
hivemodule.xml file in the XML module with the plain Java definitions
in the framework module. (Note that this is a specific case of the
former usage described.)
3. Extension resolving -- During registry construction HiveMind will
"move" any extensions (service implementations, service interceptors,
contributions, and the new configuration parsers) which have been
registered at the module level to the appropriate extension point by
removing it from the respective module's collection (returned by a
getXxx() method) and add it to the extension using an addXxx() method.
I hope I didn't miss anything now.
IMHO it would be great if we could drop the mutability requirements
and thus both simplify the API and make it easier to write an
implementation for it. One use case I had in mind is something James
mentioned: mapping a Spring application context to a HiveMind module.
Any other opinions on this one?
Regards,
--knut
Re: mutability in hivemind 2 registry construction api
Posted by Paul Cooley <pe...@gmail.com>.
I assume this would mean that jmx styled applications or configuration apps
would then have to restart hivemind or manually dump their new
configurations to disk in order for any mutable changes to take place? My
current client, a very large, very French oil service industry company, has
an existing Avalon-based framework that allows these changes to be made
dynamically, but essentially does nothing more than store them until the
container is restarted. Only then do the changes become live.
A built-in mechanism for doing so would be greatly appreciated (as I'm
attempting to move for replacing their "homegrown" solution with HM 2.0).
:)
On 1/24/07, Knut Wannheden <kn...@gmail.com> wrote:
>
> Juliano,
>
> As currently envisioned modifications to the registry after
> construction time, i.e. at runtime, would still not be possible. The
> new API is somewhat misleading in that respect which I think is
> another good reason to change it.
>
> --knut
>
> On 1/24/07, Juliano Viana <ju...@logicstyle.com> wrote:
> > Hello,
> >
> > A while ago I started working on an extension to Hivemind that would
> > provide a web-based GUI for editing service properties and
> > configurations at runtime. At the time i figured out that it would be
> > difficult to do so because of the static nature of the registry. I
> > managed to produce something that worked by advising the registry using
> > aspects, but I decided to wait until 2.0 was developed in order to try
> > doing this again. Having a mutable registry can be something very useful
> > in some applications (like implemented the concept of a "distributed"
> > registry) but I understand that it can become overly complex.
> >
> > - Juliano.
> > Knut Wannheden wrote:
> > > Hi all,
> > >
> > > I just took a look at the new registry construction API in the 2.0
> > > proposal. I think it looks very good but one thing I'd like to discuss
> > > is the mutability requirements. I'm talking about the various addXxx()
> > > methods and the fact that some Collection objects returned by some
> > > getters must be mutable. Specifically I'd like to discuss if the
> > > mutability in the API is needed and / or desired.
> > >
> > > From what I can work out the mutability of the module definitions is
> > > used by HiveMind for the following things:
> > >
> > > 1. Module definition construction -- The actual implementations of the
> > > API can use the addXxx() methods to construct the actual module
> > > definition.
> > >
> > > 2. Merging "hivemind" module definition -- If the user is using the
> > > optional XML support in HiveMind then HiveMind will during registry
> > > construction merge definitions for the "hivemind" module from the
> > > hivemodule.xml file in the XML module with the plain Java definitions
> > > in the framework module. (Note that this is a specific case of the
> > > former usage described.)
> > >
> > > 3. Extension resolving -- During registry construction HiveMind will
> > > "move" any extensions (service implementations, service interceptors,
> > > contributions, and the new configuration parsers) which have been
> > > registered at the module level to the appropriate extension point by
> > > removing it from the respective module's collection (returned by a
> > > getXxx() method) and add it to the extension using an addXxx() method.
> > >
> > > I hope I didn't miss anything now.
> > >
> > > IMHO it would be great if we could drop the mutability requirements
> > > and thus both simplify the API and make it easier to write an
> > > implementation for it. One use case I had in mind is something James
> > > mentioned: mapping a Spring application context to a HiveMind module.
> > >
> > > Any other opinions on this one?
> > >
> > > Regards,
> > >
> > > --knut
> >
> >
>
--
Gotta find my destiny, before it gets too late.-- Ian Curtis
Re: mutability in hivemind 2 registry construction api
Posted by Knut Wannheden <kn...@gmail.com>.
Juliano,
What you describe as changeable service factory parameters sounds
interesting. It seems like this should be possible without making the
module definitions mutable. You would have to create your own service
model which knows when the CSI has to be reconstructed (i.e. when the
parameters change). Further you'd need a reference to the factory
parameters you want to change.
Note that this split of service factory and factory parameters will
not exist in the same form in HiveMind 2 anymore. There will simply be
a service implementation constructor (see http://tinyurl.com/ytox2o)
which given a service point constructs a CSI for it. You'll be able to
provide your own implementations for this interface. Of course as part
of the XML support there will still be an implementation of this
interface supporting service factories with parameters.
Regards,
--knut
On 1/25/07, Juliano Viana <ju...@logicstyle.com> wrote:
> That is misleading indeed...
> What I wanted to do (and missed the support for ) was to be able to
> change service factory parameters and configurations at runtime.
> Of course, once you change the parameters of a service point's factory
> then the service has to be reconstructed. That is not s big problem for
> the singleton service model - since the service is lazily constructed,
> it can be reconstructed at any time anyway.
>
> In the end I think it is possible to do all this without a fully
> writable registry api - but as I said, it will involve advising some
> parts of the registry and producing an "enhanced" version of hivemind.
>
> - Juliano.
>
>
> Knut Wannheden wrote:
> > Juliano,
> >
> > As currently envisioned modifications to the registry after
> > construction time, i.e. at runtime, would still not be possible. The
> > new API is somewhat misleading in that respect which I think is
> > another good reason to change it.
> >
> > --knut
>
>
Re: mutability in hivemind 2 registry construction api
Posted by Juliano Viana <ju...@logicstyle.com>.
That is misleading indeed...
What I wanted to do (and missed the support for ) was to be able to
change service factory parameters and configurations at runtime.
Of course, once you change the parameters of a service point's factory
then the service has to be reconstructed. That is not s big problem for
the singleton service model - since the service is lazily constructed,
it can be reconstructed at any time anyway.
In the end I think it is possible to do all this without a fully
writable registry api - but as I said, it will involve advising some
parts of the registry and producing an "enhanced" version of hivemind.
- Juliano.
Knut Wannheden wrote:
> Juliano,
>
> As currently envisioned modifications to the registry after
> construction time, i.e. at runtime, would still not be possible. The
> new API is somewhat misleading in that respect which I think is
> another good reason to change it.
>
> --knut
Re: mutability in hivemind 2 registry construction api
Posted by Knut Wannheden <kn...@gmail.com>.
Juliano,
As currently envisioned modifications to the registry after
construction time, i.e. at runtime, would still not be possible. The
new API is somewhat misleading in that respect which I think is
another good reason to change it.
--knut
On 1/24/07, Juliano Viana <ju...@logicstyle.com> wrote:
> Hello,
>
> A while ago I started working on an extension to Hivemind that would
> provide a web-based GUI for editing service properties and
> configurations at runtime. At the time i figured out that it would be
> difficult to do so because of the static nature of the registry. I
> managed to produce something that worked by advising the registry using
> aspects, but I decided to wait until 2.0 was developed in order to try
> doing this again. Having a mutable registry can be something very useful
> in some applications (like implemented the concept of a "distributed"
> registry) but I understand that it can become overly complex.
>
> - Juliano.
> Knut Wannheden wrote:
> > Hi all,
> >
> > I just took a look at the new registry construction API in the 2.0
> > proposal. I think it looks very good but one thing I'd like to discuss
> > is the mutability requirements. I'm talking about the various addXxx()
> > methods and the fact that some Collection objects returned by some
> > getters must be mutable. Specifically I'd like to discuss if the
> > mutability in the API is needed and / or desired.
> >
> > From what I can work out the mutability of the module definitions is
> > used by HiveMind for the following things:
> >
> > 1. Module definition construction -- The actual implementations of the
> > API can use the addXxx() methods to construct the actual module
> > definition.
> >
> > 2. Merging "hivemind" module definition -- If the user is using the
> > optional XML support in HiveMind then HiveMind will during registry
> > construction merge definitions for the "hivemind" module from the
> > hivemodule.xml file in the XML module with the plain Java definitions
> > in the framework module. (Note that this is a specific case of the
> > former usage described.)
> >
> > 3. Extension resolving -- During registry construction HiveMind will
> > "move" any extensions (service implementations, service interceptors,
> > contributions, and the new configuration parsers) which have been
> > registered at the module level to the appropriate extension point by
> > removing it from the respective module's collection (returned by a
> > getXxx() method) and add it to the extension using an addXxx() method.
> >
> > I hope I didn't miss anything now.
> >
> > IMHO it would be great if we could drop the mutability requirements
> > and thus both simplify the API and make it easier to write an
> > implementation for it. One use case I had in mind is something James
> > mentioned: mapping a Spring application context to a HiveMind module.
> >
> > Any other opinions on this one?
> >
> > Regards,
> >
> > --knut
>
>
Re: mutability in hivemind 2 registry construction api
Posted by Juliano Viana <ju...@logicstyle.com>.
Hello,
A while ago I started working on an extension to Hivemind that would
provide a web-based GUI for editing service properties and
configurations at runtime. At the time i figured out that it would be
difficult to do so because of the static nature of the registry. I
managed to produce something that worked by advising the registry using
aspects, but I decided to wait until 2.0 was developed in order to try
doing this again. Having a mutable registry can be something very useful
in some applications (like implemented the concept of a "distributed"
registry) but I understand that it can become overly complex.
- Juliano.
Knut Wannheden wrote:
> Hi all,
>
> I just took a look at the new registry construction API in the 2.0
> proposal. I think it looks very good but one thing I'd like to discuss
> is the mutability requirements. I'm talking about the various addXxx()
> methods and the fact that some Collection objects returned by some
> getters must be mutable. Specifically I'd like to discuss if the
> mutability in the API is needed and / or desired.
>
> From what I can work out the mutability of the module definitions is
> used by HiveMind for the following things:
>
> 1. Module definition construction -- The actual implementations of the
> API can use the addXxx() methods to construct the actual module
> definition.
>
> 2. Merging "hivemind" module definition -- If the user is using the
> optional XML support in HiveMind then HiveMind will during registry
> construction merge definitions for the "hivemind" module from the
> hivemodule.xml file in the XML module with the plain Java definitions
> in the framework module. (Note that this is a specific case of the
> former usage described.)
>
> 3. Extension resolving -- During registry construction HiveMind will
> "move" any extensions (service implementations, service interceptors,
> contributions, and the new configuration parsers) which have been
> registered at the module level to the appropriate extension point by
> removing it from the respective module's collection (returned by a
> getXxx() method) and add it to the extension using an addXxx() method.
>
> I hope I didn't miss anything now.
>
> IMHO it would be great if we could drop the mutability requirements
> and thus both simplify the API and make it easier to write an
> implementation for it. One use case I had in mind is something James
> mentioned: mapping a Spring application context to a HiveMind module.
>
> Any other opinions on this one?
>
> Regards,
>
> --knut
Re: mutability in hivemind 2 registry construction api
Posted by Knut Wannheden <kn...@gmail.com>.
Achim,
On 2/9/07, Achim Hügen <ac...@gmx.de> wrote:
> Knut,
>
> Knut Wannheden schrieb:
> > Hi Achim,
> >
> > On 1/25/07, Achim Hügen <ac...@gmx.de> wrote:
> >> I agree that it is desirable to reduce mutability.
> >>
> >> Most of the collections returned from any definition
> >> class could be made immutable.
> >> A call to Collections.unmodifiableCollection() would solve this.
> >>
> >> Regarding the addXxx methods I find it very helpful to use
> >> the definition classes for construction and extension resolving.
> >> Otherwise one would need an additional structure that represents
> >> the assocations between extension points and extensions and which
> >> is used during construction for resolving and constraint checking.
> >> To my mind it feels like the most natural fit to add and retrieve
> >> the associated objects directly from their source.
> >>
> >
> > When *defining* a module using Java code I agree that using the
> > addXxx() methods may feel more natural so it might make sense to have
> > those in implementation classes. But I don't agree with that this is
> > required for the extension resolving. You say that an additional
> > structure would be required. As I see it this additional structure is
> > already present, it's HiveMind internal counterpart to the definition
> > structure. I.e. the objects Module, ServicePoint, etc. created during
> > the registry construction. And that's also how it worked in HiveMind
> The problem is that those objects are generic (and should stay generic)
> and doesn't know anything about specific implementations of the
> definition api (xml, annotations).
> The ServicePoint class would have to store a schema for a xml service point
> because the schema is assigned during the extension resolving phase.
>
I don't quite see how schemas relate to this. After all they are not
part of the definition API either. Rather this seems to tie in more
with my remark about the internal objects keeping a reference to the
respective definition object after registry construction time. See
below.
> Moreover the hivedoc generation needs a resolved registry definition
> too and can't operate on the internal objects.
>
A HiveDoc report should IMHO reflect the structure of an unresolved
registry. That's IIRC what it has done up until now. And that should
certainly be easier with an unresolved definition structure as a
starting point.
> > 1.
> >
> >> These add methods are defined in the public interfaces.
> >> RegistryDefinition#addModule
> >> RegistryDefinition#addPostProcessor
> >> RegistryDefinition#addRegistryInitializationListener
> >> ModuleDefinition#addServicePoint
> >> ModuleDefinition#addConfigurationPoint
> >> ...
> >> ConfigurationPointDefinition#addContribution
> >> ConfigurationPointDefinition#addParser
> >> ServicePointDefinition#addImplementation
> >> ServicePointDefinition#addInterceptor
> >>
> >> Although it might be possible to shift some of them to the
> >> the implementation classes, at least
> >> the add-methods of RegistryDefinition and ModuleDefinition must remain.
> >>
> >
> > Why must the add methods on these two interfaces remain?
> I was wrong for ModuleDefinition and already moved them to the impl class.
> So it is no longer possible to add extension points to another module.
> It is still possible to add extensions and that is what they are
> designed for.
> > I can see
> > that we need those on RegistryDefinition unless we change the
> > RegistryProvider (should we move that to the definition package?) to
> > something like:
> >
> > public interface RegistryProvider
> > {
> > Collection getModules();
> > Collection getPostProcessors();
> > Collection getRegistryInitializationListeners();
> > }
> >
> > Of course the latter two could arguably also be moved to the
> > ModuleDefinition.
> >
> > As far as I can understand the add methods on ModuleDefintion are
> > currently used so that a RegistryProvider can augment any other module
> > by first retrieving it from the RegistryDefinition. Also a
> > RegistryPostProcessor can do that. I think that seems a little bit
> > dangerous. I'd like to think of a module definition as sealed! I know
> > that this is used in the case of the "hivemind" module but that case
> > could be treated separately.
> Let us not be too restrictive here. Thats more a chance but a threat.
> For example you could iterate over all services and add an interceptor
> to all services that match certain criterias.
That means that a user can add interceptors to private services and
contributions to private configurations. Of course marking an
extension as private is often just about hiding complexity.
I am not saying I am against this but I was not aware of this
difference to HiveMind 1. Any other opinions on this?
> >
> >> So, to achieve immutability in a consistent manner I would suggest
> >> to use the same mechanism that is implemented in
> >> RegistryInfrastructureImpl.
> >> After the startup of the registry the definition classes gets locked,
> >> that
> >> means further modification by calls to the add methods are forbidden.
> >> This requirement must be document in the interfaces and could be
> >> implemented
> >> in the default implementation of the definition interfaces.
> >>
> >> I don't expect this to make the implementation of the API more difficult
> >> in any way, Knut.
> >> Please take a look at the current implementations of the api: the xml
> >> module specializes
> >> 2 classes of the default implementation only and the annotation module
> >> doesn't override
> >> any implementation at all. Most of the stuff is handled by the
> >> constructors.
> >> I don't think that a spring implementation would require special
> >> implementations
> >> of the api which cannot be inherited from the default implementation.
> >>
> >> How do you expect the api to get simpler? Could you give an example?
> >>
> >
> > IMHO the API would be simpler just by having fewer methods in it. The
> > implementor won't have to worry about implementing the add methods
> > which actually need to implement a guard just like you've done in
> > ModuleDefinitionImpl to protect against unwanted modifications. Also a
> > user won't get the idea that the definitions can be changed after the
> > registry has been constructed.
> >
> > On another note I discovered that the internal objects will even after
> > registry startup always maintain a reference to their respective
> > definition objects which thus won't ever get garbage collected. Is
> > that on purpose?
> Yes, it's on purpose. On the one hand you need access to the
> specific implementations of the definition api (xml, annotations)
> from the constructors (see InvokeFactoryServiceConstructor).
> On the other hand the definition data is rather lean, but
> surely we could make some optimization there later.
>
One example of this you're describing is the
InvokeFactoryServiceConstructor which will query the ServicePoint for
its definition and cast it to its XML specific implementation to
retireve the schema.
Another solution would be if the ImplementationConstructor object
already had all the details it needed from the definition objects in
order for it to create the CSI. The ServicePoint would then at
registry build time be wired with this ImplementationConstructor
instead of its ServicePointDefinition. After registry construction
time the definition objects would then be garbage collected.
Regards,
--knut
Re: mutability in hivemind 2 registry construction api
Posted by Achim Hügen <ac...@gmx.de>.
Knut,
Knut Wannheden schrieb:
> Hi Achim,
>
> On 1/25/07, Achim Hügen <ac...@gmx.de> wrote:
>> I agree that it is desirable to reduce mutability.
>>
>> Most of the collections returned from any definition
>> class could be made immutable.
>> A call to Collections.unmodifiableCollection() would solve this.
>>
>> Regarding the addXxx methods I find it very helpful to use
>> the definition classes for construction and extension resolving.
>> Otherwise one would need an additional structure that represents
>> the assocations between extension points and extensions and which
>> is used during construction for resolving and constraint checking.
>> To my mind it feels like the most natural fit to add and retrieve
>> the associated objects directly from their source.
>>
>
> When *defining* a module using Java code I agree that using the
> addXxx() methods may feel more natural so it might make sense to have
> those in implementation classes. But I don't agree with that this is
> required for the extension resolving. You say that an additional
> structure would be required. As I see it this additional structure is
> already present, it's HiveMind internal counterpart to the definition
> structure. I.e. the objects Module, ServicePoint, etc. created during
> the registry construction. And that's also how it worked in HiveMind
The problem is that those objects are generic (and should stay generic)
and doesn't know anything about specific implementations of the
definition api (xml, annotations).
The ServicePoint class would have to store a schema for a xml service point
because the schema is assigned during the extension resolving phase.
Moreover the hivedoc generation needs a resolved registry definition
too and can't operate on the internal objects.
> 1.
>
>> These add methods are defined in the public interfaces.
>> RegistryDefinition#addModule
>> RegistryDefinition#addPostProcessor
>> RegistryDefinition#addRegistryInitializationListener
>> ModuleDefinition#addServicePoint
>> ModuleDefinition#addConfigurationPoint
>> ...
>> ConfigurationPointDefinition#addContribution
>> ConfigurationPointDefinition#addParser
>> ServicePointDefinition#addImplementation
>> ServicePointDefinition#addInterceptor
>>
>> Although it might be possible to shift some of them to the
>> the implementation classes, at least
>> the add-methods of RegistryDefinition and ModuleDefinition must remain.
>>
>
> Why must the add methods on these two interfaces remain?
I was wrong for ModuleDefinition and already moved them to the impl class.
So it is no longer possible to add extension points to another module.
It is still possible to add extensions and that is what they are
designed for.
> I can see
> that we need those on RegistryDefinition unless we change the
> RegistryProvider (should we move that to the definition package?) to
> something like:
>
> public interface RegistryProvider
> {
> Collection getModules();
> Collection getPostProcessors();
> Collection getRegistryInitializationListeners();
> }
>
> Of course the latter two could arguably also be moved to the
> ModuleDefinition.
>
> As far as I can understand the add methods on ModuleDefintion are
> currently used so that a RegistryProvider can augment any other module
> by first retrieving it from the RegistryDefinition. Also a
> RegistryPostProcessor can do that. I think that seems a little bit
> dangerous. I'd like to think of a module definition as sealed! I know
> that this is used in the case of the "hivemind" module but that case
> could be treated separately.
Let us not be too restrictive here. Thats more a chance but a threat.
For example you could iterate over all services and add an interceptor
to all services that match certain criterias.
>
>> So, to achieve immutability in a consistent manner I would suggest
>> to use the same mechanism that is implemented in
>> RegistryInfrastructureImpl.
>> After the startup of the registry the definition classes gets locked,
>> that
>> means further modification by calls to the add methods are forbidden.
>> This requirement must be document in the interfaces and could be
>> implemented
>> in the default implementation of the definition interfaces.
>>
>> I don't expect this to make the implementation of the API more difficult
>> in any way, Knut.
>> Please take a look at the current implementations of the api: the xml
>> module specializes
>> 2 classes of the default implementation only and the annotation module
>> doesn't override
>> any implementation at all. Most of the stuff is handled by the
>> constructors.
>> I don't think that a spring implementation would require special
>> implementations
>> of the api which cannot be inherited from the default implementation.
>>
>> How do you expect the api to get simpler? Could you give an example?
>>
>
> IMHO the API would be simpler just by having fewer methods in it. The
> implementor won't have to worry about implementing the add methods
> which actually need to implement a guard just like you've done in
> ModuleDefinitionImpl to protect against unwanted modifications. Also a
> user won't get the idea that the definitions can be changed after the
> registry has been constructed.
>
> On another note I discovered that the internal objects will even after
> registry startup always maintain a reference to their respective
> definition objects which thus won't ever get garbage collected. Is
> that on purpose?
Yes, it's on purpose. On the one hand you need access to the
specific implementations of the definition api (xml, annotations)
from the constructors (see InvokeFactoryServiceConstructor).
On the other hand the definition data is rather lean, but
surely we could make some optimization there later.
Achim
Re: mutability in hivemind 2 registry construction api
Posted by Knut Wannheden <kn...@gmail.com>.
Hi Achim,
On 1/25/07, Achim Hügen <ac...@gmx.de> wrote:
> I agree that it is desirable to reduce mutability.
>
> Most of the collections returned from any definition
> class could be made immutable.
> A call to Collections.unmodifiableCollection() would solve this.
>
> Regarding the addXxx methods I find it very helpful to use
> the definition classes for construction and extension resolving.
> Otherwise one would need an additional structure that represents
> the assocations between extension points and extensions and which
> is used during construction for resolving and constraint checking.
> To my mind it feels like the most natural fit to add and retrieve
> the associated objects directly from their source.
>
When *defining* a module using Java code I agree that using the
addXxx() methods may feel more natural so it might make sense to have
those in implementation classes. But I don't agree with that this is
required for the extension resolving. You say that an additional
structure would be required. As I see it this additional structure is
already present, it's HiveMind internal counterpart to the definition
structure. I.e. the objects Module, ServicePoint, etc. created during
the registry construction. And that's also how it worked in HiveMind
1.
> These add methods are defined in the public interfaces.
> RegistryDefinition#addModule
> RegistryDefinition#addPostProcessor
> RegistryDefinition#addRegistryInitializationListener
> ModuleDefinition#addServicePoint
> ModuleDefinition#addConfigurationPoint
> ...
> ConfigurationPointDefinition#addContribution
> ConfigurationPointDefinition#addParser
> ServicePointDefinition#addImplementation
> ServicePointDefinition#addInterceptor
>
> Although it might be possible to shift some of them to the
> the implementation classes, at least
> the add-methods of RegistryDefinition and ModuleDefinition must remain.
>
Why must the add methods on these two interfaces remain? I can see
that we need those on RegistryDefinition unless we change the
RegistryProvider (should we move that to the definition package?) to
something like:
public interface RegistryProvider
{
Collection getModules();
Collection getPostProcessors();
Collection getRegistryInitializationListeners();
}
Of course the latter two could arguably also be moved to the ModuleDefinition.
As far as I can understand the add methods on ModuleDefintion are
currently used so that a RegistryProvider can augment any other module
by first retrieving it from the RegistryDefinition. Also a
RegistryPostProcessor can do that. I think that seems a little bit
dangerous. I'd like to think of a module definition as sealed! I know
that this is used in the case of the "hivemind" module but that case
could be treated separately.
> So, to achieve immutability in a consistent manner I would suggest
> to use the same mechanism that is implemented in
> RegistryInfrastructureImpl.
> After the startup of the registry the definition classes gets locked, that
> means further modification by calls to the add methods are forbidden.
> This requirement must be document in the interfaces and could be
> implemented
> in the default implementation of the definition interfaces.
>
> I don't expect this to make the implementation of the API more difficult
> in any way, Knut.
> Please take a look at the current implementations of the api: the xml
> module specializes
> 2 classes of the default implementation only and the annotation module
> doesn't override
> any implementation at all. Most of the stuff is handled by the
> constructors.
> I don't think that a spring implementation would require special
> implementations
> of the api which cannot be inherited from the default implementation.
>
> How do you expect the api to get simpler? Could you give an example?
>
IMHO the API would be simpler just by having fewer methods in it. The
implementor won't have to worry about implementing the add methods
which actually need to implement a guard just like you've done in
ModuleDefinitionImpl to protect against unwanted modifications. Also a
user won't get the idea that the definitions can be changed after the
registry has been constructed.
On another note I discovered that the internal objects will even after
registry startup always maintain a reference to their respective
definition objects which thus won't ever get garbage collected. Is
that on purpose?
--knut
Re: mutability in hivemind 2 registry construction api
Posted by Achim Hügen <ac...@gmx.de>.
I agree that it is desirable to reduce mutability.
Most of the collections returned from any definition
class could be made immutable.
A call to Collections.unmodifiableCollection() would solve this.
Regarding the addXxx methods I find it very helpful to use
the definition classes for construction and extension resolving.
Otherwise one would need an additional structure that represents
the assocations between extension points and extensions and which
is used during construction for resolving and constraint checking.
To my mind it feels like the most natural fit to add and retrieve
the associated objects directly from their source.
These add methods are defined in the public interfaces.
RegistryDefinition#addModule
RegistryDefinition#addPostProcessor
RegistryDefinition#addRegistryInitializationListener
ModuleDefinition#addServicePoint
ModuleDefinition#addConfigurationPoint
...
ConfigurationPointDefinition#addContribution
ConfigurationPointDefinition#addParser
ServicePointDefinition#addImplementation
ServicePointDefinition#addInterceptor
Although it might be possible to shift some of them to the
the implementation classes, at least
the add-methods of RegistryDefinition and ModuleDefinition must remain.
So, to achieve immutability in a consistent manner I would suggest
to use the same mechanism that is implemented in
RegistryInfrastructureImpl.
After the startup of the registry the definition classes gets locked, that
means further modification by calls to the add methods are forbidden.
This requirement must be document in the interfaces and could be
implemented
in the default implementation of the definition interfaces.
I don't expect this to make the implementation of the API more difficult
in any way, Knut.
Please take a look at the current implementations of the api: the xml
module specializes
2 classes of the default implementation only and the annotation module
doesn't override
any implementation at all. Most of the stuff is handled by the
constructors.
I don't think that a spring implementation would require special
implementations
of the api which cannot be inherited from the default implementation.
How do you expect the api to get simpler? Could you give an example?
Achim
Am Wed, 24 Jan 2007 16:59:31 +0100 schrieb Knut Wannheden
<kn...@gmail.com>:
> Hi all,
>
> I just took a look at the new registry construction API in the 2.0
> proposal. I think it looks very good but one thing I'd like to discuss
> is the mutability requirements. I'm talking about the various addXxx()
> methods and the fact that some Collection objects returned by some
> getters must be mutable. Specifically I'd like to discuss if the
> mutability in the API is needed and / or desired.
>
>> From what I can work out the mutability of the module definitions is
> used by HiveMind for the following things:
>
> 1. Module definition construction -- The actual implementations of the
> API can use the addXxx() methods to construct the actual module
> definition.
>
> 2. Merging "hivemind" module definition -- If the user is using the
> optional XML support in HiveMind then HiveMind will during registry
> construction merge definitions for the "hivemind" module from the
> hivemodule.xml file in the XML module with the plain Java definitions
> in the framework module. (Note that this is a specific case of the
> former usage described.)
>
> 3. Extension resolving -- During registry construction HiveMind will
> "move" any extensions (service implementations, service interceptors,
> contributions, and the new configuration parsers) which have been
> registered at the module level to the appropriate extension point by
> removing it from the respective module's collection (returned by a
> getXxx() method) and add it to the extension using an addXxx() method.
>
> I hope I didn't miss anything now.
>
> IMHO it would be great if we could drop the mutability requirements
> and thus both simplify the API and make it easier to write an
> implementation for it. One use case I had in mind is something James
> mentioned: mapping a Spring application context to a HiveMind module.
>
> Any other opinions on this one?
>
> Regards,
>
> --knut