Currently SezPoz has no special support for dynamic configuration changes; you pass in a ClassLoader which has access to a certain number of JARs containing registrations, and you get a list of items back.
For services which are loaded on demand and then discarded—say, file format translators arranged by file extension—this is not really an issue, since you could just have a utility method to expose a ClassLoader corresponding to the current list of loaded plugins, with the expectation that this could change from call to call.
For menu items and other things which need to be permanently displayed, dynamic (un)loading of plugins would be trickier. First you would need some kind of event fired when a plugin is loaded or unloaded, that could be listened to by components displaying indexed objects. Since IndexItem implements equals/hashCode according to its visible behavior, it should suffice to retain a Set<IndexItem<A,I>> from the previous load, and then just check whether a new load has added or removed items.
It should be possible to enhance the API to make this kind of behavior
straightforward. Something like:
class Index<A,I> implements Iterable<IndexItem<A,I>> {
// factories as currently but also:
static Index<A,I> load(Class<A> annotation, Class<I> instanceType,
Collection<ClassLoader> loaders);
// methods as currently but also:
IndexDelta<A,I> load(ClassLoader loader);
IndexDelta<A,I> unload(ClassLoader loader);
IndexDelta<A,I> replace(Collection<ClassLoader> loaders);
}
class IndexDelta<A,I> {
Set<IndexItem<A,I>> added();
Set<IndexItem<A,I>> removed();
}
The application would need to offer some kind of event notification to
components so they could know to reload their indices and rebuild derived objects (e.g. a JMenuBar). This would be rather dependent on the architecture of a module system and probably out of scope for SezPoz.
Originally filed in JIRA.
Currently SezPoz has no special support for dynamic configuration changes; you pass in a
ClassLoaderwhich has access to a certain number of JARs containing registrations, and you get a list of items back.For services which are loaded on demand and then discarded—say, file format translators arranged by file extension—this is not really an issue, since you could just have a utility method to expose a
ClassLoadercorresponding to the current list of loaded plugins, with the expectation that this could change from call to call.For menu items and other things which need to be permanently displayed, dynamic (un)loading of plugins would be trickier. First you would need some kind of event fired when a plugin is loaded or unloaded, that could be listened to by components displaying indexed objects. Since
IndexItemimplementsequals/hashCodeaccording to its visible behavior, it should suffice to retain aSet<IndexItem<A,I>>from the previous load, and then just check whether a new load has added or removed items.It should be possible to enhance the API to make this kind of behavior straightforward. Something like:
The application would need to offer some kind of event notification to components so they could know to reload their indices and rebuild derived objects (e.g. a
JMenuBar). This would be rather dependent on the architecture of a module system and probably out of scope for SezPoz.