OSGiConfig node with mixinTypes

[bobkranson]

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?

[bobkranson]

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!!

[Jörg_Hoh · Accepted solution]

This mixinType does not have any relevance, but obviously someone activated that config once via crxde lite.

Jörg

[bobkranson]

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'.

Bob

[Jörg_Hoh]

Hi,

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.

[bobkranson]

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

So, in my humble estimation, this is a bug with the osgiconfig node type that will prevent correct inheritance and operation of a system that has multiple named package configuration items of type OSGiConfig.  Additionally I call it a bug because if you use the right-click mixins option and use the minus sign to remove the mixin, the property is still there but with no value.  This would suggest to me that the object will not merge or inherit correctly because the class cast of 6 properties to 5 properties (throwing numbers at it) will fail with cast exception (if it were java which is class based, but just fails because its javascript/json that is class-less, ie not strict).