This is no longer our best practice for configuration data. The current best practice is to have a component named XXXConfiguration for each module.
The config property is located in xwiki.cfg
Thus the proposal is to:
Deprecate (and legacify when possible) the 2 apis mentioned above
Introduce a new org.xwiki.configuration.CoreConfiguration component interface, with a isReadOnly() method.
Note: We introduced a com.xpn.xwiki.CoreConfiguration component in the past but it contains a single method that’s been deprecated and thus we might also deprecate the full component.
(optional) Deprecate xwiki.cfg/xwiki.readonly and introduce a new xwiki.properties/core.readonly property.
Note: we may need to discuss the need to set only a subwiki as readonly. I don’t know if there are use cases for it in farm modeor not. Any idea?
Of course if we deprecated it, we would still need to fallback to it for backward compatibility reasons.
+1, this feature was barely documented and not maintained but some users probably relied heavily on it. Deprecating it without an alternative would mean a degradation in XWiki’s features.
That made me rethink the proposal and instead of keeping this in the oldcore module, we could directly put it in the right location. Setting and checking the wiki to read-only is an administration operation, or a maintenance operation (which is a special type of administration), or a management operation (also a special type of administration).
So we have 3 main choices I think:
Use the existing xwiki-platform-administration-api module
org.xwiki.administration.AdministrationConfiguration class
org.xwiki.administration.script.AdministrationScriptService class
administration.readonly property
Create a new xwiki-platform-maintenance/xwiki-platform-maintenance-api module
org.xwiki.maintenance.MaintenanceConfiguration class
org.xwiki.maintenance.script.MaintenanceScriptService class
maintenance.readonly property
Create a new xwiki-platform-management/xwiki-platform-management-api module
org.xwiki.management.ManagementConfiguration class
org.xwiki.management.script.ManagementScriptService class
management.readonly property
I think right now my preference goes slightly to 1) (Administration) as I’m unsure if we’ll have enough stuff to put in the “maintenance” or “management” modules. And if one day we have enough, we could still move them into a new module. But if we think there’s a future for the maintenance module, that could be a good choice too.
Sounds a bit strange to me, actually, those looks like use cases and not natures of the readonly mode. My first reflex would have been to associate it to the environment (which have the advantage of making it accessible to xwiki-commons stuff) or the container.
For me it was more associated to the concept of Wiki (ie platform). I’m not sure what “readonly” would mean in commons and rendering for example. There are no UI and no stores there for example (We could imagine some file system stores but that sounds a bit too far-fetched).
I could be ok to put it in commons, but I’d like to see/imagine some uses cases for it inside some commons modules first.
BTW if we put it in commons, we have several choices: environment, container (as you mentioned), but also xwiki-commons-management.
Note that xwiki-commons-container is currently only targeting the servlet container but the readonly configuration option is larger than the servlet container. It’s actually more for the stores than the servlet container.
Same comment for the xwiki-commons-environment which is for accessing resources for the servlet environment, the portlet environment (deprecated) or the standard environment. It currently has no relationship with any databases or other stores.
There is no such thing as xwiki-commons-container, it’s in platform.
For me it’s more generic than the servlet container, #getPermanentDirectory already does not have much to do with it. It’s just stuff related to the environment in which XWiki is running in general, and for me a property instructing XWiki than it should ideally not modify stored data feels like an environment thing.
It’s tempting but there’s no concept of stores in commons, so the “readonly” parameter cannot be associated with stores. I’d like to see some use cases inside commons first, i.e why it should be a commons config and not a platform one.
For me, it’s more a concept of a platform (ie a runtime), and commons is not a runtime.
Let’s see what others think. I’m not against it but I fear that it’s not going to be used in commons and it’d be a concept quite unneeded there. If we put the concept there, we’ll need a default impl in commons that we won’t use and overrides in platform anyway in order to locate it in xwiki.properties and then xobjects + add an Admin UI in the future + override the script service (or define it only in platform).
Not sure what you mean here, it’s hardly the first property stored in xwiki.properties which is exposed in xwiki-commons, we use Provider<ConfigurationSource> for this.