On Fri, Apr 6, 2012 at 8:51 AM, Vincent Massol <[email protected]> wrote: > > On Apr 5, 2012, at 6:51 PM, Anca Luca wrote: > >> On 04/05/2012 06:42 PM, Vincent Massol wrote: >>> Hi Sergiu, >>> >>> 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? >>> This is not really how it's been designed ATM. Whenever you wish to use a >>> different implementation of a component you use a component implementation >>> with the same role and same hint. You then make it available in your >>> classpath. (Of course you can also do this at runtime simply by registering >>> a new implementation over the old one). >>> >>> To decide which implementation is used you use a priority order, as >>> described on: >>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Component+Module#HOverrides >>> >>> I'd be curious to know your exact use case and understand why the current >>> mechanism doesn't work for it. >> >> One usecase I see is that you have multiple implementations and you want to >> change the default one for a specific running instance of xwiki. > > This is supported already. > >> Overwrite mechanism only allows you to say which impl should be used from >> the _components with the same hint_. However, you cannot change the hint of >> a component at configuration time, so if you have a standard distr of xwiki >> and you want to use ldap authentication, let's say (if only auth was impl >> with components), unless you do some java to add the default hint to the >> ldap implementation and then to specify that this one has priority over all >> the default ones, I don't see how you can re-wire the default. > > Yes that's because the hint is not a configuration param. It's an intrinsic > information about what it represents. When you have: > > @Named("ldap") > public class DefaultLDAPAuthenticator implements Authenticator > ... > > It means that (Authenticator,"ldap") means the LDAP Authenticator > implementation and not something else. If you want to change that > implementation you need to write a component with (Authenticator,"ldap"). > > Now if what you want is way to have *several* implementations of the same > Role at once in the classloader you need to use different hints and if what > you want is pick one implementation from those various implementation and > make it your default you need to configure somewhere which one to use. We use > that everywhere in the XE. > > 2 examples: > * Macros. In this case it's the user who says which ones to use by using the > "hint" as the macro name telling XWiki which macro implementation to use: > {{hint .../}} > * Storage implementation. In this case we want only one default storage impl > to be used. What we do is have a Storage Manager which is in charge of > deciding which implementation to use. In this case the selection is based on > a configuration param which contains the hint of the implementation to use > (for ex: xwiki.store.main.hint=hibernate). > > I don't see the limitation. It's even more powerful than what you suggest > (which is static rewiring of component implementations) since in this case we > support dynamic rewiring based on any rule. > > I still fail to see the use case that would make what you suggest required.
>From what I understood it's not that much about adding something we can't do right now but Sergiu basically wants to make Storage Manager useless by introducing a generic system working for any set of components with the same use case of configurable default implementation (cache factory, storage, etc.). Instead of going through a manager you would directly lookup/inject the "default" implementation which would not be the component with role MyRole and hint "default" but the configured default component (can be true for any rolehint, like changing which macro implementation to use for the hint "velocity" for example choosing between XWiki and JSR223 implementation). Right Sergiu ? > > Thanks > -Vincent > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
