Hi Anca, On Apr 6, 2012, at 10:58 AM, Anca Luca wrote:
> On 04/06/2012 08:51 AM, Vincent Massol 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. > > Ok, so you write a factory (call it manager if you want, I can also call it > proxy if I want) that has the hint default and that actually does nothing but > give you the implementation that was configured at default with one or the > others of the means. > So if you want the user to have a choice (the dude installing xwiki and > having it running), you must _always_ write these factories, as soon as there > is more than one implementation, and have it read configuration from some > place. > If somebody builds something based on xwiki platform and adds an extra > implementation and wants to be able to change that, he needs to write his new > implementation + this factory (+ a bit of magic to actually overcome the fact > that the old implementation was "default" and now his new implementation must > be default but also needs to be able to dispatch to the old default -- here I > so much agree with sergiu default shouldn't exist). > > In addition, most of these factories will work exactly the same: they will > look for a param in the configuration file and use that hint as the default. > Of course we can provide an > AbstractXWikiConfigurationBasedGenericComponentImplementationManager to make > it easy for people to write their own. > > It is covering the use case, but it's a pain. In addition, it really depends > on the fact that the person that wrote the multiple implementations thought > of whether there should be something that dispatches between them or not > (because somebody at some point might wanna change it). > > Since all these managers will be the same, why not add an "implicit > implementation" of this in the CM, by just allowing a hint to be configured > in the config file, and the CM would read it on the fly? > > This doesn't mean that you cannot write your own if you want, that dispatches > based on the moon phase, for example. > > Note that I push more towards dumb-simple things, although I understand why > it's a complex topic. Sorry, I replied to your mail first and then I saw and replied to Sergiu's. I have provided more details in the that second mail. Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
