An application introduced an OSGiConfig node that has a mixinType of ReplicationStatus. This broke the inheritance/merge model for the settings found in apps/system/config. I wonder if someone in the community could help explain how mixinTypes might be used for an OSGiConfig node? Are there certain mixinTypes that would apply to OSGiConfig or is this simply some oversight on the properties of the OSGiConfig node-type?
Solved! Go to Solution.
There may be some relevance to CQ5.6 migrating to AEM6.1........so the code-upgrade module might be improved by removing the OSGIConfig legacy property for mixinType. Or, potentially an XSD or DTD parser validation of the 6.x OSGiConfig node allowed properties to prevent system properties being ignored!!
Thanks for the reply. Might I request the favor of a further explanation what you mean by activated that config? I do not have the 5.6 history that you might so I am guessing that the OSGi Config approach in 5.6 may have worked differently which populated the mixinType? Or a replication/activation artifact from 5.6 that exported, and likely works in 5.6, which is deprecated or removed in 6.x? We are testing for impact/regression but surely a faster answer could be 'its old and no longer used but once was for XYZ dojo mixin'.
in crxde lite you can replicate a single node, thus creating a mixin node. That might have been the cause for this.
You can remove the mixin type without any impact.
So to expand on this:
- In CRXDE/Lite you go to /apps/system/config/myOsgiConfig Node
- Choose the replication tab
- Press Replicate
- It replicates it and puts it in the replication queue
- It adds the mixin types property value
Now, go to the same location
- Try to replicate an 'nt:file' node
- Try to replicate an 'nt:resource' node
- Neither of these will add mixIn types to the node properties
- They do show in the replication queue