Feature #105
Rework all code to be independant of src/dst type
| Status: | Assigned | Start: | 02/07/2009 | ||
|---|---|---|---|---|---|
| Priority: | Normal | Due date: | |||
| Assigned to: | Sébastien Bahloul | % Done: | 80% |
||
| Category: | Core | ||||
| Target version: | 1.3.x branch |
Description
Change central methods to work with srcBean and dstBean, regardless of where they came from/are going to. This includes returning modifications in a generic way, not JndiModifications.
This would be a good start to enable several cool features afterwards, including:- Multiple sources/destinations
- Synchronizing to a DB
History
Updated by Sébastien Bahloul 7 months ago
With the new asynchronous capabilities and code rewrites, could be interesting to retargeted this issue to 1.2 branch ?
Updated by Jonathan Clarke 7 months ago
- Status changed from New to Assigned
- Assigned to set to Sébastien Bahloul
Sébastien Bahloul wrote:
With the new asynchronous capabilities and code rewrites, could be interesting to retargeted this issue to 1.2 branch ?
As discussed tonight, let's keep this for 1.3, and try and get 1.2 out as soon as possible.
Updated by Jonathan Clarke 2 months ago
Updated by Sébastien Bahloul about 1 month ago
- % Done changed from 0 to 80
It just requires to handle modifications in a more generic way, less Jndi related, and provided a binding to JndiModification to provide compatibility
Updated by Sébastien Bahloul about 1 month ago
- File lsc-generic-modifications.diff added
Here is the diff. A feedback is required because it implies lots of classes modification and breaks some compatibilities :P
Updated by Rémy-Christophe Schermesser about 1 month ago
Very good work Sebastien ! Your patch is big yet simple.
I have 2 propositions :
- Why did you name the constants in LscModification SOMETHING_OBJECT and not simply SOMETHING ? (ex: CREATE_OBJECT and CREATE). I think it is easier to name them like that
- Do you think the Lsc prfix in the name of the classes is mandatory ? The classes are already in a lsc package, so I would remove the prefix.
Updated by Jonathan Clarke 21 days ago
Sébastien Bahloul wrote:
Here is the diff. A feedback is required because it implies lots of classes modification and breaks some compatibilities :P
Thanks to some free time at RMLL in Bordeaux, I took a look at this patch with Seb :)
Some comments:- The patch is very clear, and I agree with almost all of it :)
- The new class LscModifications stores a "main ID" which is the inheritance of "DN" from JndiModifications. I don't think that this is a general notion for all data repositories (having a DN to identify entries is very LDAP specific).
- Careful with unrelated changes! Like logging messages, etc :)
- I think you can s/Set<Entry<A,B>>/Map<A,B>/ :)
- We should rename the "main ID" in LscModifications to be a "display name" to identify entries in logs (just a string, which might be the DN for LDAP related connectors but not necessarily)
- JNDI based connectors should manage the DN just like any other attribute. The fact that changing the DN requires a seperate operation (MODRDN) should be hidden in the JNDI connectors. I'll open a new feature request for this.
- It would be nice to store old values in LscAttributeModification, to see what we're replacing. This is necessary for treating the DN like other attributes for JNDI connectors (to detect when to do a MODRDN).