Hi Sergiu,
I think that components and xwiki defaults are 2 distinct issues, and
here you're talking about defaults for xwiki (meta) services, not the
defaults for what a service means from a (lower level) component pov.
At component level, from my pov, default means "I don't care, I just
need one".
At xwiki services level (storage, authentication, datamigration, etc),
default means: "whichever is considered "standard" in the running
instance of xwiki".
I understand the need (which is why I love declarative wiring of
components, a la osgi/apache felix), yet I'm not 100% sure that we need
another mechanism to make it happen.
We have already changed the component overriding mechanism to allow
potentially infinite overriding, changing the 'default' implementation
in the whole instance can be achieved with this.
Also, we could still keep these configs in the
xwiki.cfg/xwiki.properties file (yet another configuration file
components-defaults.txt would be a pain from my pov) and change the
behaviour of the component manager (yey) to take that into account on
lookup. In the end, it _is_ about configuration (whether your xwiki
should use hibernate or other store).
Actually there's a third thing: the fact that default is not reflecting
the technology and for that there is a simple solution: you can have
multiple hints for a component. Thus, a hibernate thingy would have
hibernate and default hints. However, you need to check that the
Component manager is giving you the same instance when you ask for one
or the other of the hints (I think there was an issue like that with
components implementing multiple roles).
<see below for more>
On 04/05/2012 05: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.
Why? if they requested the default, as per my starting remark, it means
"I don't care, I just need one". So why should it matter that the
implementation changed?
Actually, if all the hint changes we make are about replacing default
implementations with hinted implementations and using the new hint as
the default, there shouldn't be any problem for the user. If we change
the default implementation itself, we'd need to announce that regardless
of the way we use to configure that (using default hint or proxying the
default with a declarative, overridable wiring) .
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.
I'm not sure we need that. We can consider it's a namespaced name and
that "default" means "default in xwiki".
WDYT?
In the end I agree, I think it's a good idea to:
1/ remove the obligation of having one component that has the hint default
2/ allowing the default to be wired at "configuration phase" rather than
at "development phase", in a declarative file that an admin can more
easily operate with.
but it shouldn't be in "yet another configuration file", it should be in
one of the standard configuration files (actually the one and only
xwiki.properties since xwiki.cfg is obsolete), where we have
traditionally stored the default implementations for various "xwiki
services".
Thanks,
Anca
P.S. sorry for the potential ideas mess above, I was writing as I was
thinking.
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
