You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Robert Munteanu <ro...@apache.org> on 2023/05/08 16:07:16 UTC

SLING-11865 - Conversion fails when initial content document does not include namespace declaration

Hi,

After cutting the cpconverter 1.3.2 release I noticed a change in
behaviour with respect to ill-formed Sling initial content files. [1],
[2]

Previously (in version 1.3.0), an initial file that used custom
namespaces but did not declare them using bundle headers

e.g.

<node>
    <primaryNodeType>nt:unstructured</primaryNodeType>
        <node>
            <name>my:subnode</name>
            <primaryNodeType>nt:unstructured</primaryNodeType>
        </node>        
    </node>
</node>

would generate an ill-formed DocView xml (aka FileVault format).
However, that DocView xml would then be successfully processed when
installing the bundle.

With version 1.3.2 this kind of file is rejected since we have moved to
using FileVault for generating the DocView xml.

The FileVault refactoring is good and allows us to drop custom code and
old dependencies. At the same time, since I spotted this problem when
updating AEM tooling [3], I am concerned that there are projects out
there using the ill-formed initial content format that will be broken.

As Konrad suggested, I'd like to hear what others think and maybe
gather some new options to proceed. Currently we have:

1. Keep the new behaviour
2. Revert to the old behaviour

I am not sure if there is a middle ground, Konrad says that the
FileVault serialisation code cannot work with missing/invalid namespace
mappings.

Thoughts?

Thanks,
Robert


[1]: https://issues.apache.org/jira/browse/SLING-11865
[2]:
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/168
[3]: https://github.com/adobe/aemanalyser-maven-plugin/pull/205

RE: SLING-11865 - Conversion fails when initial content document does not include namespace declaration

Posted by Stefan Seifert <St...@diva-e.com.INVALID>.
1 is definitely the better approach.

as konrad mentioned as well, 1 could be combined with improved defaults in the downstream-tooling (e.g. aem analyser plugin). it should be possible to register the well-known namespaces used in AEM context there as default, that should cover most of the failures to be expected in existing projects.

from a sling perspective it's good to fail early in the build process if the mappings are missing, assuming the error message clearly indicates what to do to solve it.

stefan

> -----Original Message-----
> From: Robert Munteanu <ro...@apache.org>
> Sent: Monday, May 8, 2023 6:07 PM
> To: dev@sling.apache.org
> Subject: SLING-11865 - Conversion fails when initial content document does
> not include namespace declaration
> 
> Hi,
> 
> After cutting the cpconverter 1.3.2 release I noticed a change in
> behaviour with respect to ill-formed Sling initial content files. [1], [2]
> 
> Previously (in version 1.3.0), an initial file that used custom namespaces
> but did not declare them using bundle headers
> 
> e.g.
> 
> <node>
>     <primaryNodeType>nt:unstructured</primaryNodeType>
>         <node>
>             <name>my:subnode</name>
>             <primaryNodeType>nt:unstructured</primaryNodeType>
>         </node>
>     </node>
> </node>
> 
> would generate an ill-formed DocView xml (aka FileVault format).
> However, that DocView xml would then be successfully processed when
> installing the bundle.
> 
> With version 1.3.2 this kind of file is rejected since we have moved to
> using FileVault for generating the DocView xml.
> 
> The FileVault refactoring is good and allows us to drop custom code and
> old dependencies. At the same time, since I spotted this problem when
> updating AEM tooling [3], I am concerned that there are projects out there
> using the ill-formed initial content format that will be broken.
> 
> As Konrad suggested, I'd like to hear what others think and maybe gather
> some new options to proceed. Currently we have:
> 
> 1. Keep the new behaviour
> 2. Revert to the old behaviour
> 
> I am not sure if there is a middle ground, Konrad says that the FileVault
> serialisation code cannot work with missing/invalid namespace mappings.
> 
> Thoughts?
> 
> Thanks,
> Robert
> 
> 
> [1]: https://issues.apache.org/jira/browse/SLING-11865
> [2]:
> https://github.com/apache/sling-org-apache-sling-feature-
> cpconverter/pull/168
> [3]: https://github.com/adobe/aemanalyser-maven-plugin/pull/205

Re: SLING-11865 - Conversion fails when initial content document does not include namespace declaration

Posted by Julian Reschke <ju...@gmx.de>.
On 12.05.2023 15:48, Robert Munteanu wrote:
> On Mon, 2023-05-08 at 18:27 +0200, Konrad Windszus wrote:
>> Another option would probably be to pass parameters to cp2fm for
>> declaring additional namespaces.
>> Then downstream consumers could declare additional ones like “cq” and
>> those would have known URLs then which would be taken into account
>> for FileVault serialisation.
>
> Right, I'll give this a shot. With no one being enthusiastic about the
> workaround I would at least try and keep the fix clean.
>
> In case anyone is curious, the downstream work for this is at
>
> https://github.com/adobe/aemanalyser-maven-plugin/pull/205
>
> Thanks,
> Robert

If this covers most of the use cases this really seems like a good
approach ("fix early").

Thanks for picking this up, Robert.

Best regards, Julian

Re: SLING-11865 - Conversion fails when initial content document does not include namespace declaration

Posted by Robert Munteanu <ro...@apache.org>.
On Mon, 2023-05-08 at 18:27 +0200, Konrad Windszus wrote:
> Another option would probably be to pass parameters to cp2fm for
> declaring additional namespaces.
> Then downstream consumers could declare additional ones like “cq” and
> those would have known URLs then which would be taken into account
> for FileVault serialisation.

Right, I'll give this a shot. With no one being enthusiastic about the
workaround I would at least try and keep the fix clean.

In case anyone is curious, the downstream work for this is at 

https://github.com/adobe/aemanalyser-maven-plugin/pull/205

Thanks,
Robert

Re: SLING-11865 - Conversion fails when initial content document does not include namespace declaration

Posted by Konrad Windszus <kw...@apache.org>.
Hi,
From a Sling perspective having initial content without explicit namespace declaration is totally fine.
Therefore I wouldn’t call it ill-formed Sling initial content files.

But the converted DocView file is ill-formed (violating the spec) but still imported fine.

Having said this, FileVault serialisation does not support emitting those ill-formed DocView files, therefore the only middle ground would require really nasty workarounds like:

- Generate artificial namespace URIs for undeclared prefixes in cp2fm
- Let FileVault generate serialisations based on those artificial namespace URIs
- Remove all XML namespace declaration previously generated for the artificial namespace URIs again in cp2fm.

Another option would probably be to pass parameters to cp2fm for declaring additional namespaces.
Then downstream consumers could declare additional ones like “cq” and those would have known URLs then which would be taken into account for FileVault serialisation.

Konrad

> On 8. May 2023, at 18:07, Robert Munteanu <ro...@apache.org> wrote:
> 
> Hi,
> 
> After cutting the cpconverter 1.3.2 release I noticed a change in
> behaviour with respect to ill-formed Sling initial content files. [1],
> [2]
> 
> Previously (in version 1.3.0), an initial file that used custom
> namespaces but did not declare them using bundle headers
> 
> e.g.
> 
> <node>
>    <primaryNodeType>nt:unstructured</primaryNodeType>
>        <node>
>            <name>my:subnode</name>
>            <primaryNodeType>nt:unstructured</primaryNodeType>
>        </node>        
>    </node>
> </node>
> 
> would generate an ill-formed DocView xml (aka FileVault format).
> However, that DocView xml would then be successfully processed when
> installing the bundle.
> 
> With version 1.3.2 this kind of file is rejected since we have moved to
> using FileVault for generating the DocView xml.
> 
> The FileVault refactoring is good and allows us to drop custom code and
> old dependencies. At the same time, since I spotted this problem when
> updating AEM tooling [3], I am concerned that there are projects out
> there using the ill-formed initial content format that will be broken.
> 
> As Konrad suggested, I'd like to hear what others think and maybe
> gather some new options to proceed. Currently we have:
> 
> 1. Keep the new behaviour
> 2. Revert to the old behaviour
> 
> I am not sure if there is a middle ground, Konrad says that the
> FileVault serialisation code cannot work with missing/invalid namespace
> mappings.
> 
> Thoughts?
> 
> Thanks,
> Robert
> 
> 
> [1]: https://issues.apache.org/jira/browse/SLING-11865
> [2]:
> https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/168
> [3]: https://github.com/adobe/aemanalyser-maven-plugin/pull/205