Hi,
I have evaluated further the idea of reloading specific resources,
namely add/update/delete of (root) resource classes. Conclusions:
1) The solution is non-trivial requiring careful implementation to
ensure that existing requests
being processed are not affected; and
2) It is really an optimization of the complete reload
functionality that is already available.
Unless developers require such an optimization now i would prefer not
to spend the time right now implementing the solution, but others are
most welcome to have a go!. Let me know what you think.
What follows are some more details on implementing a more optimal
solution for the benefit of myself and others that may choose to
tackle this later on.
Because of concurrency a clone and replace solution is a good
approach. Namely clone the concurrent map used for look up of a
resource class to the meta-data, make modifications to the clone and
replace the field value (which is a thread-safe operation).
A new root resource classes rule needs to be created if any root
resource classes are modified, and this instead will replace the field
value. This rule is responsible matching a URI path to a root resource
class given the set of paths associated with root resource classes.
Modification consists of two aspects: 1) put (for update and addition)
of resource classes; and 2) delete of resource classes. It may be
appropriate to consider a transaction consisting of the set of classes
to put and delete, which is more efficient that individual transactions.
In general a better approach is to consider using re-factoring to use
OSGi for modules consisting of resource classes and providers. This
provides a framework to manage the addition/removal of modules at
runtime and isolation between modules. I would prefer to spend time on
such an approach.
Paul.