Specify overriding properties for a connector instance must be possible.
All overriding properties must be reproposed for valuation into resource
configuration interface (see attached images as reference).
Overrode properties must be replaced into connector properties in phase of
connector bean registration.
At the moment we register a spring bean for each connector instance. ID of
a bean is the related connector instance ID.
This behavious would be changed: we should reagister a spring bean for each
couple resource+connector. The ID of the bean should be a concatenation
between resource name and connector instance ID.
Please find attached the complete patch for this issue.
To summarize the implementation:
- added fields in the console to let connector configuration properties be
overridable and let resource fill these
- added REST operation to retrieve configuration properties by connector
- Register a connector instance bean for every target resource with
combined configuration from both connector and resource
Side-effects of this patch, not necessarily related to the issue:
- Refactoring of the xml-serialization (the jdk-style one) to a util class
(see also )
- Addition of Mockito as dependency, for mocking in unit tests
- Moved LOG from org.syncope.core.init.AbstractLoader to its concrete
subclasses, to correctly reflect the category it logs to
- Moved getConnectorManager() from ConnInstanceLoader to a new class
ConnectorBundleLoader, to separate responsibilities (and for better
isolated unit tests, although I could not come up with a proper working
unit test for registerConnector() yet)
Things to discuss:
- Connector instance beans are not registered only for resource-connector
pairs, but also for every connector instance alone (like they were before
This makes it possible to retrieve schema names and configuration
properties of connector instances that are created but do not have a
resource attached to it yet. I'm not sure it's the most beautiful setup,
but it works anyway.
- What about connector properties that were overridable once, but changed
later to be not overridable anymore. Should resources configured to
override still be able to do so, or should these overridden properties have
no effect anymore?