6 Apr
2012
6 Apr
'12
11:06 a.m.
Hi Anca,
On Apr 6, 2012, at 10:58 AM, Anca Luca wrote:
On 04/06/2012 08:51 AM, Vincent Massol wrote:
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
On Apr 5, 2012, at 6:51 PM, Anca Luca wrote:
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. On 04/05/2012 06:42 PM, Vincent Massol wrote:
This is supported already.
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#HOver…
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. 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.