Actually, another way of presenting your proposal in a more generic way would be: "Add support for component Aliases". It's slightly more generic since it's not just about default. If you wish to change a hint for another one because it's not well named you could do it through an alias. This would also mean adding a ComponentManager.setAlias(String alias, Type existingRole, String existingHint). Anyway, the next step IMO is to check what Guice/CDI and OSGi are doing in this regards. Thanks -Vincent On Apr 5, 2012, at 5:55 PM, Sergiu Dumitriu wrote:
Hi devs,
Currently, requesting a component instance without a hint will look for the implementation that uses the "default" hint, which makes it difficult to change the implementation in an XWiki instance. Sure, it is easy as long as all the implementations use the "default" hint, but choosing the default between alternative implementations that should all still be usable by themselves is not possible.
Also, "default" is not really a good hint, since it describes the state of the implementation, not the technology, the aspect that makes it different from the others. It would be better to name each implementation with a proper hint.
I propose to define a mapping that can specify which hint is the default for a component. In a text file, META-INF/component-defaults.txt, we'll keep componentinterface=defaulthint mappings. For example:
com.xpn.xwiki.store.XWikiStoreInterface=hibernate com.xpn.xwiki.store.migration.DataMigrationManager=hibernate
And then, when we lookup the current storage implementation, we don't need to check what is the configured hint in xwiki.cfg (or xwiki.properties), we can just request the default implementation.
If there's no mapping for a component, we'll continue to use the "default" hint.
I'm not sure where exactly to keep such files. We bundle a components.txt file in each jar containing component implementations. We could do the same for the components we consider the platform defaults, and allow overrides in the WEB-INF/classes/META-INF/component-defaults.txt file. Still, this means that whenever platform defaults change, we need to keep another special section in the release notes, to let users know about these changes, so that they can manually revert to the old default if they need to.
In the future we could change existing components to give proper hints instead of "default", where such a change is applicable.
Another idea is to not use "default" at all, and instead go for a generic "xwiki", "xe", "xwiki-platform" or something like that whenever there's just one implementation for a component and we can't find another hint to describe it.
WDYT? -- Sergiu Dumitriu