I don't like the copy approach either. I found the same limitation and
proposed to make the constructor public but there was no interest at
that moment. Feel free to post a jira issue.
Ok. I'll do that.
I'd like to add checks for node type constraints before committing the
contribution. I don't like the idea of committing a repair tool that
will surely break the repo in known circumstances. Thanks for
volunteering :).
Could you be more specific how the tool may introduce new
inconsistencies ? Removing a mandatory name/property for example ?
In this case, we need to check the mandatory state of the Item we want
to remove and remove the parent too (and the parent of the parent and so
on). But as you pointd out, you need a NodeTypeRegistry to do that.
What can be done for the property, instead of removing it is to set to a
default value. Which can be done with a NodeTypeRegistry.
btw, I also plan to add test cases, I already made some but I'll add a
few more.
I found validating methods in ItemValidator class !. Looks good.
I copied the code to my two new checks : CheckPropertyValidate and
CheckNodeValidate which basically do the built-in jackrabbit validations
(type check, constraints, etc...). I couldn't come up with a better
name, but stay open to suggestions.
I guess I'm not forced to copy the code. I can initialize new instances
of the ItemValidator using a mock HierarchyManager (only used in error
messages). I'll fix that later on.
I changed the following in the original code :
- how the PropDef is retreive from the NodeTypeRegistry: using the
definition id is not the best choice for a checking tool. As far as I
understand, the definition id may change when the definition of the
node/property changed (and is re-computed then).
- the exceptions thrown to SanityCheckException (of course :)
Tell me if I'm doing something you've already done.
I'm interested to have your feedback on these points.
I hope I'll be able to finish my two checks for the end of the week.
Cheers,
Bertrand.
