Hey,
Currently we have a Service configuration mechanism implemented in
ServiceConfigurationMixin(SCM) that allows a Service to be configured
through an EntityComposite. The Service uses it by casting itself to the
Entity interface by using @This, like so:
public class MyServiceMixin
implements MyService
{
@This MyServiceConfiguration config;
public void doStuff()
{
config.someConfigProperty().get();
}
}
The SCM will implement the MyServiceConfiguration interface
automatically, and delegate all calls to an Entity of type
MyServiceConfiguration with the identity "MyService". This works, but is
perhaps a bit too magical.
Here's an alternative way it could work. Instead of having a generic
mixin we could have a standard Configuration interface through which we
can access the config. Like so:
public class MyServiceMixin
implements MyService
{
@This Configuration<MyServiceConfiguration> config;
public void doStuff()
{
config.configuration().someConfigProperty().get();
config.refresh(); // Reload the config if it has been updated
}
}
This makes it much more explicit that it is the configuration that is
being used, and gives a good place for the refresh() method, which is
important for the Service to be able to refresh the state of the
configuration, if it has been changed externally through UI or similar.
What do you think? Would this make more sense as a general Service
configuration mechanism? Any other options?
The only problem with the above is the implementation, since the
interface is generic, i.e. Configuration<T> and so the implementation
must somehow figure out what T is mapped to in the injection, which is
non-trivial. But if we want it to work I'll make it work :-)
What say ye?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
