[
https://issues.apache.org/jira/browse/JCRVLT-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17408730#comment-17408730
]
Dominik Süß commented on JCRVLT-557:
------------------------------------
[~kwin], [~tripod] - this is problematic as this is a breaking change - the
packages may not be owned and controlled by the operator of the system and this
breaks backward compatiblity (which means we can't drop in the new version
without previously working packages starting to fail. An option I could see is
to introduce an install option that allows to toggle the corresponding behavior
- for consumers that would be failing the toggle could be set (legacy behavior)
IF they are failing until they have fixed this. We could add some logging to
detect and log warns in case of this toggle being set so we can provide proper
feedback to consumers that have such packages around. (cc [~cziegeler])
> Breaking change in behavior for implict nodetype calculation
> ------------------------------------------------------------
>
> Key: JCRVLT-557
> URL: https://issues.apache.org/jira/browse/JCRVLT-557
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
> Reporter: Dominik Süß
> Priority: Major
>
> During extensive validation of backward compatiblity of droping in head
> (3.5.1-SNAPSHOT) over 3.4.0 led to detection of a breaking behavioral change.
> The simplified case looks like this:
> * a node is already present as nt:unstructured
> * a package is being installed with an the filter root not having a
> .content.xml
> * the child node of this node would be nt:unstructured
> Experienced outcome in 3.4.0: all 3 nodes would be of nt:unstructured
> Behavior in 3.5.1-SNAPSHOT: ConstraintViolationExceptionas no matching
> NodeTypeDefinition is found for the child node (indicating that the parent
> wasn't created as nt:unstrructureed)
> The original case is slightly more complex where the substructure is deeper
> with some excludes and an "implicit" node (not covered by the filter due to
> the exclude would fail to create with the same ConstraintViolationException.
> My current assumption is that solving the provided testcase (will create IT
> for the PR) would also solve the more complex scenario - if necessary I can
> add a secondary test case closer to the real-world failure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
