[xwiki-devs] [Discussion] Set virtual=1 by default and deprecate the virtual mode API
Hi devs, According to the Roadmap of 5.0 [1][2] we will be deprecating the virtual mode API and moving to a virtual-by-default mode instead. The idea is that the multiwiki environment should be the default and, anyone wanting to use the single-wiki mode (as XE was doing in the past), will simply not create any subwiki. It is just pointless to have 2 products for such a simple fact and it also confuses users that have downloaded and started to use one product and later on realise that they needed the other. Also, when installing the wiki-manager and/or workspace extension(s) (because you might want to create subwikis/workspaces), there will be no need to stop the wiki, enable-virtual mode and restart it; all will be doable in the browser. Therefore, I`m sending this mail to ask your opinion about this topic, in case you might have something to say against it, and also to brainstorm on the required changes and implications on existing code so that the transition is as smooth and invisible as possible. Proposed changes: - Remove "xwiki.virtual" from xwiki.cfg(.vm) -- remove the usage of the "$xwikiCfgVirtual" maven property from xwiki-platform (, xwiki-enteprise and xwiki-manager) - Deprecate boolean com.xpn.xwiki.XWiki.isVirtualMode() (and the api.XWiki version) -- change its code to ((getVirtualWikisDatabaseNames(context).size() == 1) ? true : false) until it is removed by the deprecation process. Possibly needed changes: - Add main wiki default descriptor to xwiki-enterprise-ui (so that getVirtualWikisDatabaseNames includes the main wiki and also to avoid DNS issues (?) caused by how we handle virtual mode) -- or have it generated programmatically at startup if it does not exist (might be safer this way, since people might be using a different UI than xwiki-enterprise-ui) I will start working on this locally and see if I can spot other issues, but please share your thoughts. Thanks, Eduard ---------- [1] http://markmail.org/message/o6adfbscpidnn7zr [2] http://jira.xwiki.org/browse/XWIKI-8822
Hi Edy, sounds good to me. We can also have a step in the install / upgrade wizard for users to decide whether they want one / several wikis at first. I have questions / suggestions about the default set of templates to include by default once this switch is effective (maybe 1 standard wiki template and 1 workspace template?), but they're the topic of another discussion. Guillaume On Mon, Feb 18, 2013 at 2:07 PM, Eduard Moraru <[email protected]> wrote:
Hi devs,
According to the Roadmap of 5.0 [1][2] we will be deprecating the virtual mode API and moving to a virtual-by-default mode instead.
The idea is that the multiwiki environment should be the default and, anyone wanting to use the single-wiki mode (as XE was doing in the past), will simply not create any subwiki. It is just pointless to have 2 products for such a simple fact and it also confuses users that have downloaded and started to use one product and later on realise that they needed the other. Also, when installing the wiki-manager and/or workspace extension(s) (because you might want to create subwikis/workspaces), there will be no need to stop the wiki, enable-virtual mode and restart it; all will be doable in the browser.
Therefore, I`m sending this mail to ask your opinion about this topic, in case you might have something to say against it, and also to brainstorm on the required changes and implications on existing code so that the transition is as smooth and invisible as possible.
Proposed changes: - Remove "xwiki.virtual" from xwiki.cfg(.vm) -- remove the usage of the "$xwikiCfgVirtual" maven property from xwiki-platform (, xwiki-enteprise and xwiki-manager) - Deprecate boolean com.xpn.xwiki.XWiki.isVirtualMode() (and the api.XWiki version) -- change its code to ((getVirtualWikisDatabaseNames(context).size() == 1) ? true : false) until it is removed by the deprecation process.
Possibly needed changes: - Add main wiki default descriptor to xwiki-enterprise-ui (so that getVirtualWikisDatabaseNames includes the main wiki and also to avoid DNS issues (?) caused by how we handle virtual mode) -- or have it generated programmatically at startup if it does not exist (might be safer this way, since people might be using a different UI than xwiki-enterprise-ui)
I will start working on this locally and see if I can spot other issues, but please share your thoughts.
Thanks, Eduard
---------- [1] http://markmail.org/message/o6adfbscpidnn7zr [2] http://jira.xwiki.org/browse/XWIKI-8822 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Mon, Feb 18, 2013 at 2:07 PM, Eduard Moraru <[email protected]> wrote:
Hi devs,
According to the Roadmap of 5.0 [1][2] we will be deprecating the virtual mode API and moving to a virtual-by-default mode instead.
The idea is that the multiwiki environment should be the default and, anyone wanting to use the single-wiki mode (as XE was doing in the past), will simply not create any subwiki. It is just pointless to have 2 products for such a simple fact and it also confuses users that have downloaded and started to use one product and later on realise that they needed the other. Also, when installing the wiki-manager and/or workspace extension(s) (because you might want to create subwikis/workspaces), there will be no need to stop the wiki, enable-virtual mode and restart it; all will be doable in the browser.
Therefore, I`m sending this mail to ask your opinion about this topic, in case you might have something to say against it, and also to brainstorm on the required changes and implications on existing code so that the transition is as smooth and invisible as possible.
Proposed changes: - Remove "xwiki.virtual" from xwiki.cfg(.vm) -- remove the usage of the "$xwikiCfgVirtual" maven property from xwiki-platform (, xwiki-enteprise and xwiki-manager) - Deprecate boolean com.xpn.xwiki.XWiki.isVirtualMode() (and the api.XWiki version) -- change its code to ((getVirtualWikisDatabaseNames(context).size() == 1) ? true : false) until it is removed by the deprecation process.
-1. It means that you are going to be in non virtual mode when starting XEM which is very wrong and the complete opposite of what we want here. We should deprecate and don't touch it's implementation in any way other that returning true by default instead of false when there is nothing in the configuration. Again as you said the goal is to be in virtual mode by default, period. If the UI want to do something different when there is only one wiki the UI should test if there is only one wiki but breaking all extensions counting on the virtual mode is very bad API breakage.
Possibly needed changes: - Add main wiki default descriptor to xwiki-enterprise-ui (so that getVirtualWikisDatabaseNames includes the main wiki and also to avoid DNS issues (?) caused by how we handle virtual mode)
This is useless IMO: * the fact that getVirtualWikisDatabaseNames does not return the main wiki when there is no descriptor for it is a bug that should be fixed * I don't see how having a descriptor with localhost in it will help in any way not having DNS issue, it's not helping much in XEM it's not going to be better in XE. IMO the right solution is to fallback on main wiki by default when the wiki is unknown instead of sending a redirect to some URL which cannot work and only allow to enable this redirect URL as an option
-- or have it generated programmatically at startup if it does not exist (might be safer this way, since people might be using a different UI than xwiki-enterprise-ui)
I will start working on this locally and see if I can spot other issues, but please share your thoughts.
Thanks, Eduard
---------- [1] http://markmail.org/message/o6adfbscpidnn7zr [2] http://jira.xwiki.org/browse/XWIKI-8822 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Hi Thomas, On Mon, Feb 18, 2013 at 3:45 PM, Thomas Mortagne <[email protected]>wrote:
Hi devs,
According to the Roadmap of 5.0 [1][2] we will be deprecating the virtual mode API and moving to a virtual-by-default mode instead.
The idea is that the multiwiki environment should be the default and, anyone wanting to use the single-wiki mode (as XE was doing in the past), will simply not create any subwiki. It is just pointless to have 2 products for such a simple fact and it also confuses users that have downloaded and started to use one product and later on realise that they needed the other. Also, when installing the wiki-manager and/or workspace extension(s) (because you might want to create subwikis/workspaces), there will be no need to stop the wiki, enable-virtual mode and restart it; all will be doable in the browser.
Therefore, I`m sending this mail to ask your opinion about this topic, in case you might have something to say against it, and also to brainstorm on the required changes and implications on existing code so that the transition is as smooth and invisible as possible.
Proposed changes: - Remove "xwiki.virtual" from xwiki.cfg(.vm) -- remove the usage of the "$xwikiCfgVirtual" maven property from xwiki-platform (, xwiki-enteprise and xwiki-manager) - Deprecate boolean com.xpn.xwiki.XWiki.isVirtualMode() (and the api.XWiki version) -- change its code to ((getVirtualWikisDatabaseNames(context).size() ==
On Mon, Feb 18, 2013 at 2:07 PM, Eduard Moraru <[email protected]> wrote: 1)
? true : false) until it is removed by the deprecation process.
-1. It means that you are going to be in non virtual mode when starting XEM which is very wrong and the complete opposite of what we want here. We should deprecate and don't touch it's implementation in any way other that returning true by default instead of false when there is nothing in the configuration. Again as you said the goal is to be in virtual mode by default, period. If the UI want to do something different when there is only one wiki the UI should test if there is only one wiki but breaking all extensions counting on the virtual mode is very bad API breakage.
I agree. The isVirtualMode check was supposed to tell you if "there can be more than one wiki", while I was suggesting to transform it to "are there currently more than one wikis?", which is obviously not equivalent.
Possibly needed changes: - Add main wiki default descriptor to xwiki-enterprise-ui (so that getVirtualWikisDatabaseNames includes the main wiki and also to avoid DNS issues (?) caused by how we handle virtual mode)
This is useless IMO: * the fact that getVirtualWikisDatabaseNames does not return the main wiki when there is no descriptor for it is a bug that should be fixed
Ok. I have created the jira issue for it: http://jira.xwiki.org/browse/XWIKI-8829 Also, on the same topic, I think that we should also expose the getVirtualWikisDatabaseNames method in api.XWiki. Maybe we should rename it to something simpler like api.XWiki.getAllWikis() or getAllWikiNames().
* I don't see how having a descriptor with localhost in it will help in any way not having DNS issue, it's not helping much in XEM it's not going to be better in XE. IMO the right solution is to fallback on main wiki by default when the wiki is unknown instead of sending a redirect to some URL which cannot work and only allow to enable this redirect URL as an option
Ok, so we comment out xwiki.virtual.redirect in xwiki.cfg and, by default, redirect to the main wiki's Main.WebHome. An existing jira issue that is very related to this topic is http://jira.xwiki.org/browse/XWIKI-479 We could reuse that. Thanks, Eduard
-- or have it generated programmatically at startup if it does not exist (might be safer this way, since people might be using a different UI than xwiki-enterprise-ui)
I will start working on this locally and see if I can spot other issues, but please share your thoughts.
Thanks, Eduard
---------- [1] http://markmail.org/message/o6adfbscpidnn7zr [2] http://jira.xwiki.org/browse/XWIKI-8822 _______________________________________________ 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
On Mon, Feb 18, 2013 at 3:38 PM, Eduard Moraru <[email protected]> wrote:
Hi Thomas,
On Mon, Feb 18, 2013 at 3:45 PM, Thomas Mortagne <[email protected]>wrote:
Hi devs,
According to the Roadmap of 5.0 [1][2] we will be deprecating the virtual mode API and moving to a virtual-by-default mode instead.
The idea is that the multiwiki environment should be the default and, anyone wanting to use the single-wiki mode (as XE was doing in the past), will simply not create any subwiki. It is just pointless to have 2 products for such a simple fact and it also confuses users that have downloaded and started to use one product and later on realise that they needed the other. Also, when installing the wiki-manager and/or workspace extension(s) (because you might want to create subwikis/workspaces), there will be no need to stop the wiki, enable-virtual mode and restart it; all will be doable in the browser.
Therefore, I`m sending this mail to ask your opinion about this topic, in case you might have something to say against it, and also to brainstorm on the required changes and implications on existing code so that the transition is as smooth and invisible as possible.
Proposed changes: - Remove "xwiki.virtual" from xwiki.cfg(.vm) -- remove the usage of the "$xwikiCfgVirtual" maven property from xwiki-platform (, xwiki-enteprise and xwiki-manager) - Deprecate boolean com.xpn.xwiki.XWiki.isVirtualMode() (and the api.XWiki version) -- change its code to ((getVirtualWikisDatabaseNames(context).size() ==
On Mon, Feb 18, 2013 at 2:07 PM, Eduard Moraru <[email protected]> wrote: 1)
? true : false) until it is removed by the deprecation process.
-1. It means that you are going to be in non virtual mode when starting XEM which is very wrong and the complete opposite of what we want here. We should deprecate and don't touch it's implementation in any way other that returning true by default instead of false when there is nothing in the configuration. Again as you said the goal is to be in virtual mode by default, period. If the UI want to do something different when there is only one wiki the UI should test if there is only one wiki but breaking all extensions counting on the virtual mode is very bad API breakage.
I agree. The isVirtualMode check was supposed to tell you if "there can be more than one wiki", while I was suggesting to transform it to "are there currently more than one wikis?", which is obviously not equivalent.
Possibly needed changes: - Add main wiki default descriptor to xwiki-enterprise-ui (so that getVirtualWikisDatabaseNames includes the main wiki and also to avoid DNS issues (?) caused by how we handle virtual mode)
This is useless IMO: * the fact that getVirtualWikisDatabaseNames does not return the main wiki when there is no descriptor for it is a bug that should be fixed
Ok. I have created the jira issue for it: http://jira.xwiki.org/browse/XWIKI-8829
Also, on the same topic, I think that we should also expose the getVirtualWikisDatabaseNames method in api.XWiki. Maybe we should rename it to something simpler like api.XWiki.getAllWikis() or getAllWikiNames().
Yes, "getVirtualWikisDatabaseNames" is not very nice.
* I don't see how having a descriptor with localhost in it will help in any way not having DNS issue, it's not helping much in XEM it's not going to be better in XE. IMO the right solution is to fallback on main wiki by default when the wiki is unknown instead of sending a redirect to some URL which cannot work and only allow to enable this redirect URL as an option
Ok, so we comment out xwiki.virtual.redirect in xwiki.cfg and, by default, redirect to the main wiki's Main.WebHome.
I carefully chose "fallback" and not "redirect" because a real redirect is impossible here since no URL will really be right or the main wiki. The idea would be to do exactly the same thing we do with IP, www.*,.
An existing jira issue that is very related to this topic is http://jira.xwiki.org/browse/XWIKI-479 We could reuse that.
Yes we can reuse it but not follow the proposal in the comments.
Thanks, Eduard
-- or have it generated programmatically at startup if it does not exist (might be safer this way, since people might be using a different UI than xwiki-enterprise-ui)
I will start working on this locally and see if I can spot other issues, but please share your thoughts.
Thanks, Eduard
---------- [1] http://markmail.org/message/o6adfbscpidnn7zr [2] http://jira.xwiki.org/browse/XWIKI-8822 _______________________________________________ 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Mon, Feb 18, 2013 at 3:48 PM, Thomas Mortagne <[email protected]> wrote:
On Mon, Feb 18, 2013 at 3:38 PM, Eduard Moraru <[email protected]> wrote:
Hi Thomas,
On Mon, Feb 18, 2013 at 3:45 PM, Thomas Mortagne <[email protected]>wrote:
Hi devs,
According to the Roadmap of 5.0 [1][2] we will be deprecating the virtual mode API and moving to a virtual-by-default mode instead.
The idea is that the multiwiki environment should be the default and, anyone wanting to use the single-wiki mode (as XE was doing in the past), will simply not create any subwiki. It is just pointless to have 2 products for such a simple fact and it also confuses users that have downloaded and started to use one product and later on realise that they needed the other. Also, when installing the wiki-manager and/or workspace extension(s) (because you might want to create subwikis/workspaces), there will be no need to stop the wiki, enable-virtual mode and restart it; all will be doable in the browser.
Therefore, I`m sending this mail to ask your opinion about this topic, in case you might have something to say against it, and also to brainstorm on the required changes and implications on existing code so that the transition is as smooth and invisible as possible.
Proposed changes: - Remove "xwiki.virtual" from xwiki.cfg(.vm) -- remove the usage of the "$xwikiCfgVirtual" maven property from xwiki-platform (, xwiki-enteprise and xwiki-manager) - Deprecate boolean com.xpn.xwiki.XWiki.isVirtualMode() (and the api.XWiki version) -- change its code to ((getVirtualWikisDatabaseNames(context).size() ==
On Mon, Feb 18, 2013 at 2:07 PM, Eduard Moraru <[email protected]> wrote: 1)
? true : false) until it is removed by the deprecation process.
-1. It means that you are going to be in non virtual mode when starting XEM which is very wrong and the complete opposite of what we want here. We should deprecate and don't touch it's implementation in any way other that returning true by default instead of false when there is nothing in the configuration. Again as you said the goal is to be in virtual mode by default, period. If the UI want to do something different when there is only one wiki the UI should test if there is only one wiki but breaking all extensions counting on the virtual mode is very bad API breakage.
I agree. The isVirtualMode check was supposed to tell you if "there can be more than one wiki", while I was suggesting to transform it to "are there currently more than one wikis?", which is obviously not equivalent.
Possibly needed changes: - Add main wiki default descriptor to xwiki-enterprise-ui (so that getVirtualWikisDatabaseNames includes the main wiki and also to avoid DNS issues (?) caused by how we handle virtual mode)
This is useless IMO: * the fact that getVirtualWikisDatabaseNames does not return the main wiki when there is no descriptor for it is a bug that should be fixed
Ok. I have created the jira issue for it: http://jira.xwiki.org/browse/XWIKI-8829
Also, on the same topic, I think that we should also expose the getVirtualWikisDatabaseNames method in api.XWiki. Maybe we should rename it to something simpler like api.XWiki.getAllWikis() or getAllWikiNames().
Yes, "getVirtualWikisDatabaseNames" is not very nice.
This name is also pretty wrong btw since that's wiki names and not database names which could be very different.
* I don't see how having a descriptor with localhost in it will help in any way not having DNS issue, it's not helping much in XEM it's not going to be better in XE. IMO the right solution is to fallback on main wiki by default when the wiki is unknown instead of sending a redirect to some URL which cannot work and only allow to enable this redirect URL as an option
Ok, so we comment out xwiki.virtual.redirect in xwiki.cfg and, by default, redirect to the main wiki's Main.WebHome.
I carefully chose "fallback" and not "redirect" because a real redirect is impossible here since no URL will really be right or the main wiki. The idea would be to do exactly the same thing we do with IP, www.*,.
An existing jira issue that is very related to this topic is http://jira.xwiki.org/browse/XWIKI-479 We could reuse that.
Yes we can reuse it but not follow the proposal in the comments.
Thanks, Eduard
-- or have it generated programmatically at startup if it does not exist (might be safer this way, since people might be using a different UI than xwiki-enterprise-ui)
I will start working on this locally and see if I can spot other issues, but please share your thoughts.
Thanks, Eduard
---------- [1] http://markmail.org/message/o6adfbscpidnn7zr [2] http://jira.xwiki.org/browse/XWIKI-8822 _______________________________________________ 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne
Hi devs, As some of you have already noticed and already started providing feedback (thank you), I have pushed a feature branch [1] that proposes the removal of the virtual mode concept (making it enabled and fixed by default). I have also gone trough the code in xwiki-platform and removed, in the feature branch, dead code (code branches that will never be reached because of this change). Some tests were also adapted to the new change. I have also tried a build of xwiki-platform with these changes and it built successfully. First of all, I want to make sure that we agree on the change, since Thomas already mentioned that he does not agree (but I need more details). Second, if we agree, please take the time to look over the changes (particularly in the modules that you each have experience in) and double check that the logic of the code was not altered in any way. I will not be merging this branch until I get a general green light from the committers, and until everybody is happy :) Please share your opinion both on this mail and/or on the specific changes in the github commits. Thanks, Eduard ---------- [1] https://github.com/xwiki/xwiki-platform/commits/feature-deprecate-virtual-mo... On Mon, Feb 18, 2013 at 4:53 PM, Thomas Mortagne <[email protected]>wrote:
On Mon, Feb 18, 2013 at 3:48 PM, Thomas Mortagne <[email protected]> wrote:
On Mon, Feb 18, 2013 at 3:38 PM, Eduard Moraru <[email protected]> wrote:
Hi Thomas,
On Mon, Feb 18, 2013 at 3:45 PM, Thomas Mortagne <[email protected]>wrote:
Hi devs,
According to the Roadmap of 5.0 [1][2] we will be deprecating the virtual mode API and moving to a virtual-by-default mode instead.
The idea is that the multiwiki environment should be the default and, anyone wanting to use the single-wiki mode (as XE was doing in the past), will simply not create any subwiki. It is just pointless to have 2 products for such a simple fact and it also confuses users that have downloaded and started to use one product and later on realise that they needed the other. Also, when installing the wiki-manager and/or workspace extension(s) (because you might want to create subwikis/workspaces), there will be no need to stop the wiki, enable-virtual mode and restart it; all will be doable in the browser.
Therefore, I`m sending this mail to ask your opinion about this topic, in case you might have something to say against it, and also to brainstorm on the required changes and implications on existing code so that the transition is as smooth and invisible as possible.
Proposed changes: - Remove "xwiki.virtual" from xwiki.cfg(.vm) -- remove the usage of the "$xwikiCfgVirtual" maven property from xwiki-platform (, xwiki-enteprise and xwiki-manager) - Deprecate boolean com.xpn.xwiki.XWiki.isVirtualMode() (and the api.XWiki version) -- change its code to ((getVirtualWikisDatabaseNames(context).size() ==
On Mon, Feb 18, 2013 at 2:07 PM, Eduard Moraru <[email protected]> wrote: 1)
? true : false) until it is removed by the deprecation process.
-1. It means that you are going to be in non virtual mode when starting XEM which is very wrong and the complete opposite of what we want here. We should deprecate and don't touch it's implementation in any way other that returning true by default instead of false when there is nothing in the configuration. Again as you said the goal is to be in virtual mode by default, period. If the UI want to do something different when there is only one wiki the UI should test if there is only one wiki but breaking all extensions counting on the virtual mode is very bad API breakage.
I agree. The isVirtualMode check was supposed to tell you if "there can be more than one wiki", while I was suggesting to transform it to "are there currently more than one wikis?", which is obviously not equivalent.
Possibly needed changes: - Add main wiki default descriptor to xwiki-enterprise-ui (so that getVirtualWikisDatabaseNames includes the main wiki and also to
avoid DNS
issues (?) caused by how we handle virtual mode)
This is useless IMO: * the fact that getVirtualWikisDatabaseNames does not return the main wiki when there is no descriptor for it is a bug that should be fixed
Ok. I have created the jira issue for it: http://jira.xwiki.org/browse/XWIKI-8829
Also, on the same topic, I think that we should also expose the getVirtualWikisDatabaseNames method in api.XWiki. Maybe we should rename it to something simpler like api.XWiki.getAllWikis() or getAllWikiNames().
Yes, "getVirtualWikisDatabaseNames" is not very nice.
This name is also pretty wrong btw since that's wiki names and not database names which could be very different.
* I don't see how having a descriptor with localhost in it will help in any way not having DNS issue, it's not helping much in XEM it's not going to be better in XE. IMO the right solution is to fallback on main wiki by default when the wiki is unknown instead of sending a redirect to some URL which cannot work and only allow to enable this redirect URL as an option
Ok, so we comment out xwiki.virtual.redirect in xwiki.cfg and, by
default,
redirect to the main wiki's Main.WebHome.
I carefully chose "fallback" and not "redirect" because a real redirect is impossible here since no URL will really be right or the main wiki. The idea would be to do exactly the same thing we do with IP, www.*,.
An existing jira issue that is very related to this topic is http://jira.xwiki.org/browse/XWIKI-479 We could reuse that.
Yes we can reuse it but not follow the proposal in the comments.
Thanks, Eduard
-- or have it generated programmatically at startup if it does not
exist
(might be safer this way, since people might be using a different UI than xwiki-enterprise-ui)
I will start working on this locally and see if I can spot other issues, but please share your thoughts.
Thanks, Eduard
---------- [1] http://markmail.org/message/o6adfbscpidnn7zr [2] http://jira.xwiki.org/browse/XWIKI-8822 _______________________________________________ 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi devs, To be more precise, the essence of my proposed change [1] is to actually always return "true" in the isVirtualMode() method, ignoring any configuration and marking the method as @deprecated, to be removed in future versions. Is there any reason not to do this? (Why) Would we want to preserve the possibility of going back to a non-virtual mode? (mostly addressed to Thomas, but to others as well) Thanks, Eduard ---------- [1] https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8... On Fri, Feb 22, 2013 at 3:39 PM, Eduard Moraru <[email protected]> wrote:
Hi devs,
As some of you have already noticed and already started providing feedback (thank you), I have pushed a feature branch [1] that proposes the removal of the virtual mode concept (making it enabled and fixed by default).
I have also gone trough the code in xwiki-platform and removed, in the feature branch, dead code (code branches that will never be reached because of this change). Some tests were also adapted to the new change. I have also tried a build of xwiki-platform with these changes and it built successfully.
First of all, I want to make sure that we agree on the change, since Thomas already mentioned that he does not agree (but I need more details).
Second, if we agree, please take the time to look over the changes (particularly in the modules that you each have experience in) and double check that the logic of the code was not altered in any way.
I will not be merging this branch until I get a general green light from the committers, and until everybody is happy :)
Please share your opinion both on this mail and/or on the specific changes in the github commits.
Thanks, Eduard
---------- [1] https://github.com/xwiki/xwiki-platform/commits/feature-deprecate-virtual-mo...
On Mon, Feb 18, 2013 at 4:53 PM, Thomas Mortagne < [email protected]> wrote:
On Mon, Feb 18, 2013 at 3:48 PM, Thomas Mortagne <[email protected]> wrote:
On Mon, Feb 18, 2013 at 3:38 PM, Eduard Moraru <[email protected]> wrote:
Hi Thomas,
On Mon, Feb 18, 2013 at 3:45 PM, Thomas Mortagne <[email protected]>wrote:
Hi devs,
According to the Roadmap of 5.0 [1][2] we will be deprecating the virtual mode API and moving to a virtual-by-default mode instead.
The idea is that the multiwiki environment should be the default and, anyone wanting to use the single-wiki mode (as XE was doing in the past), will simply not create any subwiki. It is just pointless to have 2 products for such a simple fact and it also confuses users that have downloaded and started to use one product and later on realise that they needed the other. Also, when installing the wiki-manager and/or workspace extension(s) (because you might want to create subwikis/workspaces), there will be no need to stop the wiki, enable-virtual mode and restart it; all will be doable in the browser.
Therefore, I`m sending this mail to ask your opinion about this topic, in case you might have something to say against it, and also to brainstorm on the required changes and implications on existing code so that the transition is as smooth and invisible as possible.
Proposed changes: - Remove "xwiki.virtual" from xwiki.cfg(.vm) -- remove the usage of the "$xwikiCfgVirtual" maven property from xwiki-platform (, xwiki-enteprise and xwiki-manager) - Deprecate boolean com.xpn.xwiki.XWiki.isVirtualMode() (and the api.XWiki version) -- change its code to ((getVirtualWikisDatabaseNames(context).size() ==
On Mon, Feb 18, 2013 at 2:07 PM, Eduard Moraru <[email protected]> wrote: 1)
? true : false) until it is removed by the deprecation process.
-1. It means that you are going to be in non virtual mode when starting XEM which is very wrong and the complete opposite of what we want here. We should deprecate and don't touch it's implementation in any way other that returning true by default instead of false when there is nothing in the configuration. Again as you said the goal is to be in virtual mode by default, period. If the UI want to do something different when there is only one wiki the UI should test if there is only one wiki but breaking all extensions counting on the virtual mode is very bad API breakage.
I agree. The isVirtualMode check was supposed to tell you if "there can be more than one wiki", while I was suggesting to transform it to "are there currently more than one wikis?", which is obviously not equivalent.
Possibly needed changes: - Add main wiki default descriptor to xwiki-enterprise-ui (so that getVirtualWikisDatabaseNames includes the main wiki and also to
avoid DNS
issues (?) caused by how we handle virtual mode)
This is useless IMO: * the fact that getVirtualWikisDatabaseNames does not return the main wiki when there is no descriptor for it is a bug that should be fixed
Ok. I have created the jira issue for it: http://jira.xwiki.org/browse/XWIKI-8829
Also, on the same topic, I think that we should also expose the getVirtualWikisDatabaseNames method in api.XWiki. Maybe we should rename it to something simpler like api.XWiki.getAllWikis() or getAllWikiNames().
Yes, "getVirtualWikisDatabaseNames" is not very nice.
This name is also pretty wrong btw since that's wiki names and not database names which could be very different.
* I don't see how having a descriptor with localhost in it will help in any way not having DNS issue, it's not helping much in XEM it's not going to be better in XE. IMO the right solution is to fallback on main wiki by default when the wiki is unknown instead of sending a redirect to some URL which cannot work and only allow to enable this redirect URL as an option
Ok, so we comment out xwiki.virtual.redirect in xwiki.cfg and, by
default,
redirect to the main wiki's Main.WebHome.
I carefully chose "fallback" and not "redirect" because a real redirect is impossible here since no URL will really be right or the main wiki. The idea would be to do exactly the same thing we do with IP, www.*,.
An existing jira issue that is very related to this topic is http://jira.xwiki.org/browse/XWIKI-479 We could reuse that.
Yes we can reuse it but not follow the proposal in the comments.
Thanks, Eduard
-- or have it generated programmatically at startup if it does not
exist
(might be safer this way, since people might be using a different UI than xwiki-enterprise-ui)
I will start working on this locally and see if I can spot other issues, but please share your thoughts.
Thanks, Eduard
---------- [1] http://markmail.org/message/o6adfbscpidnn7zr [2] http://jira.xwiki.org/browse/XWIKI-8822 _______________________________________________ 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi devs, To further fuel this discussion, I will mention some points that are more or less problematic when removing the notion of virtual mode (checks for xwiki.isVirtualMode()), since a direct change would leave a some pieces of code dead (never called) or just need a bit of discussion on them: 1. c.x.x.s.XWikiHibernateBaseStore.initHibernate(XWikiContext context) [1] That piece of code seems to only run when the wiki is not in virtual mode.
From what I managed to understand from Thomas [2], it's probably this case: "in your hibernate configuration if you set a database which is not called 'xwiki'. In virtual mode this configuration is not taken into account and you have to indicate the name of the database in xwiki.cfg". I think we need to review this behavior. IMO, we should do take this configuration into account in virtual mode as well, as long as there is no other technical impediment. It is a configuration for the main wiki after all, and it should still be valid.
2. c.x.x.XWiki.onPluginPreferenceEvent(Event event, XWikiDocument doc, XWikiContext context) [3] This piece of code seems to reload the plugins if the "plugins" property changed in XWikiPreferences, but only if the wiki is not in virtual mode. I think we need to change this to happen for any wiki and the plugins need to be reloaded only for that specific wiki for which the change happened (if it is possible). 3. extension.vm - extensionActionButton macro [4] This UI code decides when to displays the (Un)Install button of an extension for the current wiki or for the entire farm. Removing the virtual mode check will always show the (un)install on farm button. I think Marius had some concerns about his one. 4. distribution.vm - displayMainUiStep_unknownPreviousUI [5] This code assumes that if virtualMode is true, then the product is XEM, otherwise it's XE. This is used to propose old version names for the 2 products. Obviously this is needs to be refactored and use a different way of determining which is which. 5. c.x.x.p.w.WikiManager public List<Wiki> getAllWikis(XWikiContext context) throws XWikiException [6] We have decided that c.x.x.XWiki.getVirtualWikisDatabaseNames will also return the main wiki's name. However, the WikiManager plugin can not do this so easily because the main wiki's descriptor may not exist. How could we handle this, in order to be consistent? Would creating programmatically the main wiki's descriptor with default values on ApplicationReady event do any good? Will it do any harm? Thanks, Eduard ---------- [1] https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb... [2] https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8... [3] https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb... [4] https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb... [5] https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb... [6] https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb... On Fri, Feb 22, 2013 at 3:48 PM, Eduard Moraru <[email protected]> wrote:
Hi devs,
To be more precise, the essence of my proposed change [1] is to actually always return "true" in the isVirtualMode() method, ignoring any configuration and marking the method as @deprecated, to be removed in future versions.
Is there any reason not to do this? (Why) Would we want to preserve the possibility of going back to a non-virtual mode? (mostly addressed to Thomas, but to others as well)
Thanks, Eduard
---------- [1] https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8...
On Fri, Feb 22, 2013 at 3:39 PM, Eduard Moraru <[email protected]>wrote:
Hi devs,
As some of you have already noticed and already started providing feedback (thank you), I have pushed a feature branch [1] that proposes the removal of the virtual mode concept (making it enabled and fixed by default).
I have also gone trough the code in xwiki-platform and removed, in the feature branch, dead code (code branches that will never be reached because of this change). Some tests were also adapted to the new change. I have also tried a build of xwiki-platform with these changes and it built successfully.
First of all, I want to make sure that we agree on the change, since Thomas already mentioned that he does not agree (but I need more details).
Second, if we agree, please take the time to look over the changes (particularly in the modules that you each have experience in) and double check that the logic of the code was not altered in any way.
I will not be merging this branch until I get a general green light from the committers, and until everybody is happy :)
Please share your opinion both on this mail and/or on the specific changes in the github commits.
Thanks, Eduard
---------- [1] https://github.com/xwiki/xwiki-platform/commits/feature-deprecate-virtual-mo...
On Mon, Feb 18, 2013 at 4:53 PM, Thomas Mortagne < [email protected]> wrote:
On Mon, Feb 18, 2013 at 3:48 PM, Thomas Mortagne <[email protected]> wrote:
On Mon, Feb 18, 2013 at 3:38 PM, Eduard Moraru <[email protected]> wrote:
Hi Thomas,
On Mon, Feb 18, 2013 at 3:45 PM, Thomas Mortagne <[email protected]>wrote:
On Mon, Feb 18, 2013 at 2:07 PM, Eduard Moraru <[email protected]
wrote: > Hi devs, > > According to the Roadmap of 5.0 [1][2] we will be deprecating the virtual > mode API and moving to a virtual-by-default mode instead. > > The idea is that the multiwiki environment should be the default and, > anyone wanting to use the single-wiki mode (as XE was doing in the past), > will simply not create any subwiki. It is just pointless to have 2 products > for such a simple fact and it also confuses users that have downloaded and > started to use one product and later on realise that they needed the other. > Also, when installing the wiki-manager and/or workspace extension(s) > (because you might want to create subwikis/workspaces), there will be no > need to stop the wiki, enable-virtual mode and restart it; all will be > doable in the browser. > > Therefore, I`m sending this mail to ask your opinion about this topic, in > case you might have something to say against it, and also to brainstorm on > the required changes and implications on existing code so that the > transition is as smooth and invisible as possible. > > Proposed changes: > - Remove "xwiki.virtual" from xwiki.cfg(.vm) > -- remove the usage of the "$xwikiCfgVirtual" maven property from > xwiki-platform (, xwiki-enteprise and xwiki-manager) > - Deprecate boolean com.xpn.xwiki.XWiki.isVirtualMode() (and the api.XWiki > version) > -- change its code to ((getVirtualWikisDatabaseNames(context).size() == 1) > ? true : false) until it is removed by the deprecation process.
-1. It means that you are going to be in non virtual mode when starting XEM which is very wrong and the complete opposite of what we want here. We should deprecate and don't touch it's implementation in any way other that returning true by default instead of false when there is nothing in the configuration. Again as you said the goal is to be in virtual mode by default, period. If the UI want to do something different when there is only one wiki the UI should test if there is only one wiki but breaking all extensions counting on the virtual mode is very bad API breakage.
I agree. The isVirtualMode check was supposed to tell you if "there can be more than one wiki", while I was suggesting to transform it to "are there currently more than one wikis?", which is obviously not equivalent.
> > Possibly needed changes: > - Add main wiki default descriptor to xwiki-enterprise-ui (so that > getVirtualWikisDatabaseNames includes the main wiki and also to avoid DNS > issues (?) caused by how we handle virtual mode)
This is useless IMO: * the fact that getVirtualWikisDatabaseNames does not return the main wiki when there is no descriptor for it is a bug that should be fixed
Ok. I have created the jira issue for it: http://jira.xwiki.org/browse/XWIKI-8829
Also, on the same topic, I think that we should also expose the getVirtualWikisDatabaseNames method in api.XWiki. Maybe we should rename it to something simpler like api.XWiki.getAllWikis() or getAllWikiNames().
Yes, "getVirtualWikisDatabaseNames" is not very nice.
This name is also pretty wrong btw since that's wiki names and not database names which could be very different.
* I don't see how having a descriptor with localhost in it will help in any way not having DNS issue, it's not helping much in XEM it's
not
going to be better in XE. IMO the right solution is to fallback on main wiki by default when the wiki is unknown instead of sending a redirect to some URL which cannot work and only allow to enable this redirect URL as an option
Ok, so we comment out xwiki.virtual.redirect in xwiki.cfg and, by default, redirect to the main wiki's Main.WebHome.
I carefully chose "fallback" and not "redirect" because a real redirect is impossible here since no URL will really be right or the main wiki. The idea would be to do exactly the same thing we do with IP, www.*,.
An existing jira issue that is very related to this topic is http://jira.xwiki.org/browse/XWIKI-479 We could reuse that.
Yes we can reuse it but not follow the proposal in the comments.
Thanks, Eduard
> -- or have it generated programmatically at startup if it does not
exist
> (might be safer this way, since people might be using a different UI than > xwiki-enterprise-ui) > > I will start working on this locally and see if I can spot other issues, > but please share your thoughts. > > Thanks, > Eduard > > ---------- > [1] http://markmail.org/message/o6adfbscpidnn7zr > [2] http://jira.xwiki.org/browse/XWIKI-8822 > _______________________________________________ > 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Edouard, Here is my comment regarding point 1. Probably more, especially on point 5 coming next. Regarding point 1., this does not seems to be exactly what we document in xwiki.cfg: #-# [Since 1.6M1] #-# Force the database name for the main wiki in virtual mode and for the wiki itself in non virtual mode. # xwiki.db=xwiki However, Thomas is not fully true, neither this is exactly the way it works. That peace of code does not really change the database use for connecting, but only the schema/catalog used, by prefixing all unqualified table with that schema/catalog name. This does not really means exactly the same as changing the schema/catalog of the connection create by the connection pool. Doing this in virtual mode will be useless, since the com.xpn.xwiki.store.XWikiHibernateBaseStore#setDatabase() will change the schema/catalog of the connection, and therefore qualifying table will be unneeded. So, it is probably safe to remove that code. Just for the sake of completeness, applying that code to virtual code would be worse, imagine the following configuration for a virtual wiki: In hibernate.cfg of myserver.mydomain.dom: <property name="connection.url">jdbc:mysql://mysql.server.local/myserver?.... (mysql.server.local is a common mysql server for multiple xwiki servers) In xwiki.cfg of myserver.mydomain.dom: xwiki.db= xwiki.db.prefix=myserver At mysql.server.local, "myserver" server will access a subwiki named "mywiki" using the "myservermywiki" database, while the main wiki will be the "myserver" database. Side note: looking more carefully at this function, there is a potential silent NPE or some useless code. Either the if (this.sessionFactory == null) {...} is misplaced, useless or magically useless in non-virtual mode, since this.sessionFactory is required in the section of code you are mentioning. Obviously, once removed, the potential misbehavior will vanish. On Wed, Feb 27, 2013 at 10:21 AM, Eduard Moraru <[email protected]>wrote:
Hi devs,
To further fuel this discussion, I will mention some points that are more or less problematic when removing the notion of virtual mode (checks for xwiki.isVirtualMode()), since a direct change would leave a some pieces of code dead (never called) or just need a bit of discussion on them:
1. c.x.x.s.XWikiHibernateBaseStore.initHibernate(XWikiContext context) [1]
That piece of code seems to only run when the wiki is not in virtual mode. From what I managed to understand from Thomas [2], it's probably this case: "in your hibernate configuration if you set a database which is not called 'xwiki'. In virtual mode this configuration is not taken into account and you have to indicate the name of the database in xwiki.cfg". I think we need to review this behavior. IMO, we should do take this configuration into account in virtual mode as well, as long as there is no other technical impediment. It is a configuration for the main wiki after all, and it should still be valid.
2. c.x.x.XWiki.onPluginPreferenceEvent(Event event, XWikiDocument doc, XWikiContext context) [3]
This piece of code seems to reload the plugins if the "plugins" property changed in XWikiPreferences, but only if the wiki is not in virtual mode. I think we need to change this to happen for any wiki and the plugins need to be reloaded only for that specific wiki for which the change happened (if it is possible).
3. extension.vm - extensionActionButton macro [4]
This UI code decides when to displays the (Un)Install button of an extension for the current wiki or for the entire farm. Removing the virtual mode check will always show the (un)install on farm button. I think Marius had some concerns about his one.
4. distribution.vm - displayMainUiStep_unknownPreviousUI [5]
This code assumes that if virtualMode is true, then the product is XEM, otherwise it's XE. This is used to propose old version names for the 2 products. Obviously this is needs to be refactored and use a different way of determining which is which.
5. c.x.x.p.w.WikiManager public List<Wiki> getAllWikis(XWikiContext context) throws XWikiException [6]
We have decided that c.x.x.XWiki.getVirtualWikisDatabaseNames will also return the main wiki's name. However, the WikiManager plugin can not do this so easily because the main wiki's descriptor may not exist. How could we handle this, in order to be consistent? Would creating programmatically the main wiki's descriptor with default values on ApplicationReady event do any good? Will it do any harm?
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb... [2]
https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8... [3]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb... [4]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb... [5]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb... [6]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
On Fri, Feb 22, 2013 at 3:48 PM, Eduard Moraru <[email protected]> wrote:
Hi devs,
To be more precise, the essence of my proposed change [1] is to actually always return "true" in the isVirtualMode() method, ignoring any configuration and marking the method as @deprecated, to be removed in future versions.
Is there any reason not to do this? (Why) Would we want to preserve the possibility of going back to a non-virtual mode? (mostly addressed to Thomas, but to others as well)
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8...
On Fri, Feb 22, 2013 at 3:39 PM, Eduard Moraru <[email protected] wrote:
Hi devs,
As some of you have already noticed and already started providing feedback (thank you), I have pushed a feature branch [1] that proposes
the
removal of the virtual mode concept (making it enabled and fixed by default).
I have also gone trough the code in xwiki-platform and removed, in the feature branch, dead code (code branches that will never be reached because of this change). Some tests were also adapted to the new change. I have also tried a build of xwiki-platform with these changes and it built successfully.
First of all, I want to make sure that we agree on the change, since Thomas already mentioned that he does not agree (but I need more details).
Second, if we agree, please take the time to look over the changes (particularly in the modules that you each have experience in) and double check that the logic of the code was not altered in any way.
I will not be merging this branch until I get a general green light from the committers, and until everybody is happy :)
Please share your opinion both on this mail and/or on the specific changes in the github commits.
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/commits/feature-deprecate-virtual-mo...
On Mon, Feb 18, 2013 at 4:53 PM, Thomas Mortagne < [email protected]> wrote:
On Mon, Feb 18, 2013 at 3:48 PM, Thomas Mortagne <[email protected]> wrote:
On Mon, Feb 18, 2013 at 3:38 PM, Eduard Moraru <[email protected]
wrote:
Hi Thomas,
On Mon, Feb 18, 2013 at 3:45 PM, Thomas Mortagne <[email protected]>wrote:
> On Mon, Feb 18, 2013 at 2:07 PM, Eduard Moraru < [email protected]
> wrote: > > Hi devs, > > > > According to the Roadmap of 5.0 [1][2] we will be deprecating the virtual > > mode API and moving to a virtual-by-default mode instead. > > > > The idea is that the multiwiki environment should be the default and, > > anyone wanting to use the single-wiki mode (as XE was doing in the past), > > will simply not create any subwiki. It is just pointless to have 2 > products > > for such a simple fact and it also confuses users that have downloaded > and > > started to use one product and later on realise that they needed the > other. > > Also, when installing the wiki-manager and/or workspace extension(s) > > (because you might want to create subwikis/workspaces), there will be no > > need to stop the wiki, enable-virtual mode and restart it; all will be > > doable in the browser. > > > > Therefore, I`m sending this mail to ask your opinion about this topic, in > > case you might have something to say against it, and also to brainstorm > on > > the required changes and implications on existing code so that the > > transition is as smooth and invisible as possible. > > > > Proposed changes: > > - Remove "xwiki.virtual" from xwiki.cfg(.vm) > > -- remove the usage of the "$xwikiCfgVirtual" maven property from > > xwiki-platform (, xwiki-enteprise and xwiki-manager) > > - Deprecate boolean com.xpn.xwiki.XWiki.isVirtualMode() (and the > api.XWiki > > version) > > -- change its code to ((getVirtualWikisDatabaseNames(context).size() == > 1) > > ? true : false) until it is removed by the deprecation process. > > -1. It means that you are going to be in non virtual mode when > starting XEM which is very wrong and the complete opposite of what we > want here. We should deprecate and don't touch it's implementation in > any way other that returning true by default instead of false when > there is nothing in the configuration. Again as you said the goal is > to be in virtual mode by default, period. If the UI want to do > something different when there is only one wiki the UI should test if > there is only one wiki but breaking all extensions counting on the > virtual mode is very bad API breakage. >
I agree. The isVirtualMode check was supposed to tell you if "there can be more than one wiki", while I was suggesting to transform it to "are there currently more than one wikis?", which is obviously not equivalent.
> > > > Possibly needed changes: > > - Add main wiki default descriptor to xwiki-enterprise-ui (so that > > getVirtualWikisDatabaseNames includes the main wiki and also to avoid DNS > > issues (?) caused by how we handle virtual mode) > > This is useless IMO: > * the fact that getVirtualWikisDatabaseNames does not return the main > wiki when there is no descriptor for it is a bug that should be fixed >
Ok. I have created the jira issue for it: http://jira.xwiki.org/browse/XWIKI-8829
Also, on the same topic, I think that we should also expose the getVirtualWikisDatabaseNames method in api.XWiki. Maybe we should rename it to something simpler like api.XWiki.getAllWikis() or getAllWikiNames().
Yes, "getVirtualWikisDatabaseNames" is not very nice.
This name is also pretty wrong btw since that's wiki names and not database names which could be very different.
> * I don't see how having a descriptor with localhost in it will
help
> in any way not having DNS issue, it's not helping much in XEM it's not > going to be better in XE. IMO the right solution is to fallback on > main wiki by default when the wiki is unknown instead of sending a > redirect to some URL which cannot work and only allow to enable this > redirect URL as an option >
Ok, so we comment out xwiki.virtual.redirect in xwiki.cfg and, by default, redirect to the main wiki's Main.WebHome.
I carefully chose "fallback" and not "redirect" because a real redirect is impossible here since no URL will really be right or the main wiki. The idea would be to do exactly the same thing we do with IP, www.*,.
An existing jira issue that is very related to this topic is http://jira.xwiki.org/browse/XWIKI-479 We could reuse that.
Yes we can reuse it but not follow the proposal in the comments.
Thanks, Eduard
> > > -- or have it generated programmatically at startup if it does
not exist
> > (might be safer this way, since people might be using a different UI than > > xwiki-enterprise-ui) > > > > I will start working on this locally and see if I can spot other issues, > > but please share your thoughts. > > > > Thanks, > > Eduard > > > > ---------- > > [1] http://markmail.org/message/o6adfbscpidnn7zr > > [2] http://jira.xwiki.org/browse/XWIKI-8822 > > _______________________________________________ > > 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Wed, Feb 27, 2013 at 11:21 AM, Eduard Moraru <[email protected]> wrote:
Hi devs,
To further fuel this discussion, I will mention some points that are more or less problematic when removing the notion of virtual mode (checks for xwiki.isVirtualMode()), since a direct change would leave a some pieces of code dead (never called) or just need a bit of discussion on them:
1. c.x.x.s.XWikiHibernateBaseStore.initHibernate(XWikiContext context) [1]
That piece of code seems to only run when the wiki is not in virtual mode. From what I managed to understand from Thomas [2], it's probably this case: "in your hibernate configuration if you set a database which is not called 'xwiki'. In virtual mode this configuration is not taken into account and you have to indicate the name of the database in xwiki.cfg". I think we need to review this behavior. IMO, we should do take this configuration into account in virtual mode as well, as long as there is no other technical impediment. It is a configuration for the main wiki after all, and it should still be valid.
2. c.x.x.XWiki.onPluginPreferenceEvent(Event event, XWikiDocument doc, XWikiContext context) [3]
This piece of code seems to reload the plugins if the "plugins" property changed in XWikiPreferences, but only if the wiki is not in virtual mode. I think we need to change this to happen for any wiki and the plugins need to be reloaded only for that specific wiki for which the change happened (if it is possible).
3. extension.vm - extensionActionButton macro [4]
This UI code decides when to displays the (Un)Install button of an extension for the current wiki or for the entire farm. Removing the virtual mode check will always show the (un)install on farm button. I think Marius had some concerns about his one.
As I said in my comment on GitHub I think the isVirtualMode() test should be replaced in this particular case with something like hasVirtualWikis() . It makes sense to display EM buttons that target multiple wikis only if you have multiple wikis.
4. distribution.vm - displayMainUiStep_unknownPreviousUI [5]
This code assumes that if virtualMode is true, then the product is XEM, otherwise it's XE. This is used to propose old version names for the 2 products. Obviously this is needs to be refactored and use a different way of determining which is which.
Yes. Thanks, Marius
5. c.x.x.p.w.WikiManager public List<Wiki> getAllWikis(XWikiContext context) throws XWikiException [6]
We have decided that c.x.x.XWiki.getVirtualWikisDatabaseNames will also return the main wiki's name. However, the WikiManager plugin can not do this so easily because the main wiki's descriptor may not exist. How could we handle this, in order to be consistent? Would creating programmatically the main wiki's descriptor with default values on ApplicationReady event do any good? Will it do any harm?
Thanks, Eduard
---------- [1] https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb... [2] https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8... [3] https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb... [4] https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb... [5] https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb... [6] https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
On Fri, Feb 22, 2013 at 3:48 PM, Eduard Moraru <[email protected]> wrote:
Hi devs,
To be more precise, the essence of my proposed change [1] is to actually always return "true" in the isVirtualMode() method, ignoring any configuration and marking the method as @deprecated, to be removed in future versions.
Is there any reason not to do this? (Why) Would we want to preserve the possibility of going back to a non-virtual mode? (mostly addressed to Thomas, but to others as well)
Thanks, Eduard
---------- [1] https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8...
On Fri, Feb 22, 2013 at 3:39 PM, Eduard Moraru <[email protected]>wrote:
Hi devs,
As some of you have already noticed and already started providing feedback (thank you), I have pushed a feature branch [1] that proposes the removal of the virtual mode concept (making it enabled and fixed by default).
I have also gone trough the code in xwiki-platform and removed, in the feature branch, dead code (code branches that will never be reached because of this change). Some tests were also adapted to the new change. I have also tried a build of xwiki-platform with these changes and it built successfully.
First of all, I want to make sure that we agree on the change, since Thomas already mentioned that he does not agree (but I need more details).
Second, if we agree, please take the time to look over the changes (particularly in the modules that you each have experience in) and double check that the logic of the code was not altered in any way.
I will not be merging this branch until I get a general green light from the committers, and until everybody is happy :)
Please share your opinion both on this mail and/or on the specific changes in the github commits.
Thanks, Eduard
---------- [1] https://github.com/xwiki/xwiki-platform/commits/feature-deprecate-virtual-mo...
On Mon, Feb 18, 2013 at 4:53 PM, Thomas Mortagne < [email protected]> wrote:
On Mon, Feb 18, 2013 at 3:48 PM, Thomas Mortagne <[email protected]> wrote:
On Mon, Feb 18, 2013 at 3:38 PM, Eduard Moraru <[email protected]> wrote:
Hi Thomas,
On Mon, Feb 18, 2013 at 3:45 PM, Thomas Mortagne <[email protected]>wrote:
> On Mon, Feb 18, 2013 at 2:07 PM, Eduard Moraru <[email protected]
> wrote: > > Hi devs, > > > > According to the Roadmap of 5.0 [1][2] we will be deprecating the virtual > > mode API and moving to a virtual-by-default mode instead. > > > > The idea is that the multiwiki environment should be the default and, > > anyone wanting to use the single-wiki mode (as XE was doing in the past), > > will simply not create any subwiki. It is just pointless to have 2 > products > > for such a simple fact and it also confuses users that have downloaded > and > > started to use one product and later on realise that they needed the > other. > > Also, when installing the wiki-manager and/or workspace extension(s) > > (because you might want to create subwikis/workspaces), there will be no > > need to stop the wiki, enable-virtual mode and restart it; all will be > > doable in the browser. > > > > Therefore, I`m sending this mail to ask your opinion about this topic, in > > case you might have something to say against it, and also to brainstorm > on > > the required changes and implications on existing code so that the > > transition is as smooth and invisible as possible. > > > > Proposed changes: > > - Remove "xwiki.virtual" from xwiki.cfg(.vm) > > -- remove the usage of the "$xwikiCfgVirtual" maven property from > > xwiki-platform (, xwiki-enteprise and xwiki-manager) > > - Deprecate boolean com.xpn.xwiki.XWiki.isVirtualMode() (and the > api.XWiki > > version) > > -- change its code to ((getVirtualWikisDatabaseNames(context).size() == > 1) > > ? true : false) until it is removed by the deprecation process. > > -1. It means that you are going to be in non virtual mode when > starting XEM which is very wrong and the complete opposite of what we > want here. We should deprecate and don't touch it's implementation in > any way other that returning true by default instead of false when > there is nothing in the configuration. Again as you said the goal is > to be in virtual mode by default, period. If the UI want to do > something different when there is only one wiki the UI should test if > there is only one wiki but breaking all extensions counting on the > virtual mode is very bad API breakage. >
I agree. The isVirtualMode check was supposed to tell you if "there can be more than one wiki", while I was suggesting to transform it to "are there currently more than one wikis?", which is obviously not equivalent.
> > > > Possibly needed changes: > > - Add main wiki default descriptor to xwiki-enterprise-ui (so that > > getVirtualWikisDatabaseNames includes the main wiki and also to avoid DNS > > issues (?) caused by how we handle virtual mode) > > This is useless IMO: > * the fact that getVirtualWikisDatabaseNames does not return the main > wiki when there is no descriptor for it is a bug that should be fixed >
Ok. I have created the jira issue for it: http://jira.xwiki.org/browse/XWIKI-8829
Also, on the same topic, I think that we should also expose the getVirtualWikisDatabaseNames method in api.XWiki. Maybe we should rename it to something simpler like api.XWiki.getAllWikis() or getAllWikiNames().
Yes, "getVirtualWikisDatabaseNames" is not very nice.
This name is also pretty wrong btw since that's wiki names and not database names which could be very different.
> * I don't see how having a descriptor with localhost in it will help > in any way not having DNS issue, it's not helping much in XEM it's
not
> going to be better in XE. IMO the right solution is to fallback on > main wiki by default when the wiki is unknown instead of sending a > redirect to some URL which cannot work and only allow to enable this > redirect URL as an option >
Ok, so we comment out xwiki.virtual.redirect in xwiki.cfg and, by default, redirect to the main wiki's Main.WebHome.
I carefully chose "fallback" and not "redirect" because a real redirect is impossible here since no URL will really be right or the main wiki. The idea would be to do exactly the same thing we do with IP, www.*,.
An existing jira issue that is very related to this topic is http://jira.xwiki.org/browse/XWIKI-479 We could reuse that.
Yes we can reuse it but not follow the proposal in the comments.
Thanks, Eduard
> > > -- or have it generated programmatically at startup if it does not
exist
> > (might be safer this way, since people might be using a different UI than > > xwiki-enterprise-ui) > > > > I will start working on this locally and see if I can spot other issues, > > but please share your thoughts. > > > > Thanks, > > Eduard > > > > ---------- > > [1] http://markmail.org/message/o6adfbscpidnn7zr > > [2] http://jira.xwiki.org/browse/XWIKI-8822 > > _______________________________________________ > > 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
I'm a bit late to the party but +1 to the idea of making wikis "virtualMode=true" all of the time, it will allow code paths to be removed and simplified even though it will have a (probably marginal) performance hit. I don't see any need for distinguishing between a non-multiwiki and a multiwiki without any subwikis. Thanks, Caleb On 02/27/2013 11:34 AM, Marius Dumitru Florea wrote:
On Wed, Feb 27, 2013 at 11:21 AM, Eduard Moraru <[email protected]> wrote:
Hi devs,
To further fuel this discussion, I will mention some points that are more or less problematic when removing the notion of virtual mode (checks for xwiki.isVirtualMode()), since a direct change would leave a some pieces of code dead (never called) or just need a bit of discussion on them:
1. c.x.x.s.XWikiHibernateBaseStore.initHibernate(XWikiContext context) [1]
That piece of code seems to only run when the wiki is not in virtual mode. From what I managed to understand from Thomas [2], it's probably this case: "in your hibernate configuration if you set a database which is not called 'xwiki'. In virtual mode this configuration is not taken into account and you have to indicate the name of the database in xwiki.cfg". I think we need to review this behavior. IMO, we should do take this configuration into account in virtual mode as well, as long as there is no other technical impediment. It is a configuration for the main wiki after all, and it should still be valid.
2. c.x.x.XWiki.onPluginPreferenceEvent(Event event, XWikiDocument doc, XWikiContext context) [3]
This piece of code seems to reload the plugins if the "plugins" property changed in XWikiPreferences, but only if the wiki is not in virtual mode. I think we need to change this to happen for any wiki and the plugins need to be reloaded only for that specific wiki for which the change happened (if it is possible).
3. extension.vm - extensionActionButton macro [4]
This UI code decides when to displays the (Un)Install button of an extension for the current wiki or for the entire farm. Removing the virtual mode check will always show the (un)install on farm button. I think Marius had some concerns about his one.
As I said in my comment on GitHub I think the isVirtualMode() test should be replaced in this particular case with something like hasVirtualWikis() . It makes sense to display EM buttons that target multiple wikis only if you have multiple wikis.
4. distribution.vm - displayMainUiStep_unknownPreviousUI [5]
This code assumes that if virtualMode is true, then the product is XEM, otherwise it's XE. This is used to propose old version names for the 2 products. Obviously this is needs to be refactored and use a different way of determining which is which.
Yes.
Thanks, Marius
5. c.x.x.p.w.WikiManager public List<Wiki> getAllWikis(XWikiContext context) throws XWikiException [6]
We have decided that c.x.x.XWiki.getVirtualWikisDatabaseNames will also return the main wiki's name. However, the WikiManager plugin can not do this so easily because the main wiki's descriptor may not exist. How could we handle this, in order to be consistent? Would creating programmatically the main wiki's descriptor with default values on ApplicationReady event do any good? Will it do any harm?
Thanks, Eduard
---------- [1] https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb... [2] https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8... [3] https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb... [4] https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb... [5] https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb... [6] https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
On Fri, Feb 22, 2013 at 3:48 PM, Eduard Moraru <[email protected]> wrote:
Hi devs,
To be more precise, the essence of my proposed change [1] is to actually always return "true" in the isVirtualMode() method, ignoring any configuration and marking the method as @deprecated, to be removed in future versions.
Is there any reason not to do this? (Why) Would we want to preserve the possibility of going back to a non-virtual mode? (mostly addressed to Thomas, but to others as well)
Thanks, Eduard
---------- [1] https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8...
On Fri, Feb 22, 2013 at 3:39 PM, Eduard Moraru <[email protected]>wrote:
Hi devs,
As some of you have already noticed and already started providing feedback (thank you), I have pushed a feature branch [1] that proposes the removal of the virtual mode concept (making it enabled and fixed by default).
I have also gone trough the code in xwiki-platform and removed, in the feature branch, dead code (code branches that will never be reached because of this change). Some tests were also adapted to the new change. I have also tried a build of xwiki-platform with these changes and it built successfully.
First of all, I want to make sure that we agree on the change, since Thomas already mentioned that he does not agree (but I need more details).
Second, if we agree, please take the time to look over the changes (particularly in the modules that you each have experience in) and double check that the logic of the code was not altered in any way.
I will not be merging this branch until I get a general green light from the committers, and until everybody is happy :)
Please share your opinion both on this mail and/or on the specific changes in the github commits.
Thanks, Eduard
---------- [1] https://github.com/xwiki/xwiki-platform/commits/feature-deprecate-virtual-mo...
On Mon, Feb 18, 2013 at 4:53 PM, Thomas Mortagne < [email protected]> wrote:
On Mon, Feb 18, 2013 at 3:48 PM, Thomas Mortagne <[email protected]> wrote:
On Mon, Feb 18, 2013 at 3:38 PM, Eduard Moraru <[email protected]> wrote: > Hi Thomas, > > On Mon, Feb 18, 2013 at 3:45 PM, Thomas Mortagne > <[email protected]>wrote: > >> On Mon, Feb 18, 2013 at 2:07 PM, Eduard Moraru <[email protected]
>> wrote: >>> Hi devs, >>> >>> According to the Roadmap of 5.0 [1][2] we will be deprecating the virtual >>> mode API and moving to a virtual-by-default mode instead. >>> >>> The idea is that the multiwiki environment should be the default and, >>> anyone wanting to use the single-wiki mode (as XE was doing in the past), >>> will simply not create any subwiki. It is just pointless to have 2 >> products >>> for such a simple fact and it also confuses users that have downloaded >> and >>> started to use one product and later on realise that they needed the >> other. >>> Also, when installing the wiki-manager and/or workspace extension(s) >>> (because you might want to create subwikis/workspaces), there will be no >>> need to stop the wiki, enable-virtual mode and restart it; all will be >>> doable in the browser. >>> >>> Therefore, I`m sending this mail to ask your opinion about this topic, in >>> case you might have something to say against it, and also to brainstorm >> on >>> the required changes and implications on existing code so that the >>> transition is as smooth and invisible as possible. >>> >>> Proposed changes: >>> - Remove "xwiki.virtual" from xwiki.cfg(.vm) >>> -- remove the usage of the "$xwikiCfgVirtual" maven property from >>> xwiki-platform (, xwiki-enteprise and xwiki-manager) >>> - Deprecate boolean com.xpn.xwiki.XWiki.isVirtualMode() (and the >> api.XWiki >>> version) >>> -- change its code to ((getVirtualWikisDatabaseNames(context).size() == >> 1) >>> ? true : false) until it is removed by the deprecation process. >> >> -1. It means that you are going to be in non virtual mode when >> starting XEM which is very wrong and the complete opposite of what we >> want here. We should deprecate and don't touch it's implementation in >> any way other that returning true by default instead of false when >> there is nothing in the configuration. Again as you said the goal is >> to be in virtual mode by default, period. If the UI want to do >> something different when there is only one wiki the UI should test if >> there is only one wiki but breaking all extensions counting on the >> virtual mode is very bad API breakage. >> > > I agree. The isVirtualMode check was supposed to tell you if "there can be > more than one wiki", while I was suggesting to transform it to "are there > currently more than one wikis?", which is obviously not equivalent. > > >>> >>> Possibly needed changes: >>> - Add main wiki default descriptor to xwiki-enterprise-ui (so that >>> getVirtualWikisDatabaseNames includes the main wiki and also to avoid DNS >>> issues (?) caused by how we handle virtual mode) >> >> This is useless IMO: >> * the fact that getVirtualWikisDatabaseNames does not return the main >> wiki when there is no descriptor for it is a bug that should be fixed >> > > Ok. I have created the jira issue for it: > http://jira.xwiki.org/browse/XWIKI-8829 > > Also, on the same topic, I think that we should also expose the > getVirtualWikisDatabaseNames method in api.XWiki. Maybe we should rename it > to something simpler like api.XWiki.getAllWikis() or getAllWikiNames().
Yes, "getVirtualWikisDatabaseNames" is not very nice.
This name is also pretty wrong btw since that's wiki names and not database names which could be very different.
> > >> * I don't see how having a descriptor with localhost in it will help >> in any way not having DNS issue, it's not helping much in XEM it's
not
>> going to be better in XE. IMO the right solution is to fallback on >> main wiki by default when the wiki is unknown instead of sending a >> redirect to some URL which cannot work and only allow to enable this >> redirect URL as an option >> > > Ok, so we comment out xwiki.virtual.redirect in xwiki.cfg and, by default, > redirect to the main wiki's Main.WebHome.
I carefully chose "fallback" and not "redirect" because a real redirect is impossible here since no URL will really be right or the main wiki. The idea would be to do exactly the same thing we do with IP, www.*,.
> > An existing jira issue that is very related to this topic is > http://jira.xwiki.org/browse/XWIKI-479 We could reuse that.
Yes we can reuse it but not follow the proposal in the comments.
> > Thanks, > Eduard > >> >>> -- or have it generated programmatically at startup if it does not exist >>> (might be safer this way, since people might be using a different UI than >>> xwiki-enterprise-ui) >>> >>> I will start working on this locally and see if I can spot other issues, >>> but please share your thoughts. >>> >>> Thanks, >>> Eduard >>> >>> ---------- >>> [1] http://markmail.org/message/o6adfbscpidnn7zr >>> [2] http://jira.xwiki.org/browse/XWIKI-8822 >>> _______________________________________________ >>> 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 >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi devs, On Wed, Feb 27, 2013 at 6:34 PM, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Feb 27, 2013 at 11:21 AM, Eduard Moraru <[email protected]> wrote:
Hi devs,
To further fuel this discussion, I will mention some points that are more or less problematic when removing the notion of virtual mode (checks for xwiki.isVirtualMode()), since a direct change would leave a some pieces of code dead (never called) or just need a bit of discussion on them:
1. c.x.x.s.XWikiHibernateBaseStore.initHibernate(XWikiContext context) [1]
That piece of code seems to only run when the wiki is not in virtual mode. From what I managed to understand from Thomas [2], it's probably this case: "in your hibernate configuration if you set a database which is not called 'xwiki'. In virtual mode this configuration is not taken into account and you have to indicate the name of the database in xwiki.cfg". I think we need to review this behavior. IMO, we should do take this configuration into account in virtual mode as well, as long as there is no other technical impediment. It is a configuration for the main wiki after all, and it should still be valid.
2. c.x.x.XWiki.onPluginPreferenceEvent(Event event, XWikiDocument doc, XWikiContext context) [3]
This piece of code seems to reload the plugins if the "plugins" property changed in XWikiPreferences, but only if the wiki is not in virtual mode. I think we need to change this to happen for any wiki and the plugins need to be reloaded only for that specific wiki for which the change happened (if it is possible).
Any input on this?
3. extension.vm - extensionActionButton macro [4]
This UI code decides when to displays the (Un)Install button of an extension for the current wiki or for the entire farm. Removing the virtual mode check will always show the (un)install on farm button. I think Marius had some concerns about his one.
As I said in my comment on GitHub I think the isVirtualMode() test should be replaced in this particular case with something like hasVirtualWikis() . It makes sense to display EM buttons that target multiple wikis only if you have multiple wikis.
Adding $xwiki.hasVirtualWikis() (convenience for $xwiki.getWikiNames().size() > 1).
4. distribution.vm - displayMainUiStep_unknownPreviousUI [5]
This code assumes that if virtualMode is true, then the product is XEM, otherwise it's XE. This is used to propose old version names for the 2 products. Obviously this is needs to be refactored and use a different
way
of determining which is which.
Yes.
Any suggestions? Maybe use the EM script service to check if the extension xwiki-enterprise-ui or xwiki-manager-ui is installed? Thanks, Eduard
Thanks, Marius
5. c.x.x.p.w.WikiManager public List<Wiki> getAllWikis(XWikiContext context) throws XWikiException [6]
We have decided that c.x.x.XWiki.getVirtualWikisDatabaseNames will also return the main wiki's name. However, the WikiManager plugin can not do this so easily because the main wiki's descriptor may not exist. How
could
we handle this, in order to be consistent? Would creating programmatically the main wiki's descriptor with default values on ApplicationReady event do any good? Will it do any harm?
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[2]
https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8...
[3]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[4]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[5]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[6]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
On Fri, Feb 22, 2013 at 3:48 PM, Eduard Moraru <[email protected]>
wrote:
Hi devs,
To be more precise, the essence of my proposed change [1] is to actually always return "true" in the isVirtualMode() method, ignoring any configuration and marking the method as @deprecated, to be removed in future versions.
Is there any reason not to do this? (Why) Would we want to preserve the possibility of going back to a non-virtual mode? (mostly addressed to Thomas, but to others as well)
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8...
On Fri, Feb 22, 2013 at 3:39 PM, Eduard Moraru <[email protected]
wrote:
Hi devs,
As some of you have already noticed and already started providing feedback (thank you), I have pushed a feature branch [1] that proposes
the
removal of the virtual mode concept (making it enabled and fixed by default).
I have also gone trough the code in xwiki-platform and removed, in the feature branch, dead code (code branches that will never be reached because of this change). Some tests were also adapted to the new change. I have also tried a build of xwiki-platform with these changes and it built successfully.
First of all, I want to make sure that we agree on the change, since Thomas already mentioned that he does not agree (but I need more details).
Second, if we agree, please take the time to look over the changes (particularly in the modules that you each have experience in) and double check that the logic of the code was not altered in any way.
I will not be merging this branch until I get a general green light from the committers, and until everybody is happy :)
Please share your opinion both on this mail and/or on the specific changes in the github commits.
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/commits/feature-deprecate-virtual-mo...
On Mon, Feb 18, 2013 at 4:53 PM, Thomas Mortagne < [email protected]> wrote:
On Mon, Feb 18, 2013 at 3:48 PM, Thomas Mortagne <[email protected]> wrote:
On Mon, Feb 18, 2013 at 3:38 PM, Eduard Moraru <
wrote:
> Hi Thomas, > > On Mon, Feb 18, 2013 at 3:45 PM, Thomas Mortagne > <[email protected]>wrote: > >> On Mon, Feb 18, 2013 at 2:07 PM, Eduard Moraru < [email protected]
>> wrote: >> > Hi devs, >> > >> > According to the Roadmap of 5.0 [1][2] we will be deprecating the virtual >> > mode API and moving to a virtual-by-default mode instead. >> > >> > The idea is that the multiwiki environment should be the default and, >> > anyone wanting to use the single-wiki mode (as XE was doing in the past), >> > will simply not create any subwiki. It is just pointless to have 2 >> products >> > for such a simple fact and it also confuses users that have downloaded >> and >> > started to use one product and later on realise that they needed the >> other. >> > Also, when installing the wiki-manager and/or workspace extension(s) >> > (because you might want to create subwikis/workspaces), there will be no >> > need to stop the wiki, enable-virtual mode and restart it; all will be >> > doable in the browser. >> > >> > Therefore, I`m sending this mail to ask your opinion about this topic, in >> > case you might have something to say against it, and also to brainstorm >> on >> > the required changes and implications on existing code so that the >> > transition is as smooth and invisible as possible. >> > >> > Proposed changes: >> > - Remove "xwiki.virtual" from xwiki.cfg(.vm) >> > -- remove the usage of the "$xwikiCfgVirtual" maven property from >> > xwiki-platform (, xwiki-enteprise and xwiki-manager) >> > - Deprecate boolean com.xpn.xwiki.XWiki.isVirtualMode() (and the >> api.XWiki >> > version) >> > -- change its code to ((getVirtualWikisDatabaseNames(context).size() == >> 1) >> > ? true : false) until it is removed by the deprecation process. >> >> -1. It means that you are going to be in non virtual mode when >> starting XEM which is very wrong and the complete opposite of what we >> want here. We should deprecate and don't touch it's implementation in >> any way other that returning true by default instead of false when >> there is nothing in the configuration. Again as you said the goal is >> to be in virtual mode by default, period. If the UI want to do >> something different when there is only one wiki the UI should test if >> there is only one wiki but breaking all extensions counting on the >> virtual mode is very bad API breakage. >> > > I agree. The isVirtualMode check was supposed to tell you if "there can be > more than one wiki", while I was suggesting to transform it to "are there > currently more than one wikis?", which is obviously not equivalent. > > >> > >> > Possibly needed changes: >> > - Add main wiki default descriptor to xwiki-enterprise-ui (so that >> > getVirtualWikisDatabaseNames includes the main wiki and also to avoid DNS >> > issues (?) caused by how we handle virtual mode) >> >> This is useless IMO: >> * the fact that getVirtualWikisDatabaseNames does not return the main >> wiki when there is no descriptor for it is a bug that should be fixed >> > > Ok. I have created the jira issue for it: > http://jira.xwiki.org/browse/XWIKI-8829 > > Also, on the same topic, I think that we should also expose the > getVirtualWikisDatabaseNames method in api.XWiki. Maybe we should rename it > to something simpler like api.XWiki.getAllWikis() or getAllWikiNames().
Yes, "getVirtualWikisDatabaseNames" is not very nice.
This name is also pretty wrong btw since that's wiki names and not database names which could be very different.
> > >> * I don't see how having a descriptor with localhost in it will
help
>> in any way not having DNS issue, it's not helping much in XEM it's not >> going to be better in XE. IMO the right solution is to fallback on >> main wiki by default when the wiki is unknown instead of sending a >> redirect to some URL which cannot work and only allow to enable this >> redirect URL as an option >> > > Ok, so we comment out xwiki.virtual.redirect in xwiki.cfg and, by default, > redirect to the main wiki's Main.WebHome.
I carefully chose "fallback" and not "redirect" because a real redirect is impossible here since no URL will really be right or the main wiki. The idea would be to do exactly the same thing we do with IP, www.*,.
> > An existing jira issue that is very related to this topic is > http://jira.xwiki.org/browse/XWIKI-479 We could reuse that.
Yes we can reuse it but not follow the proposal in the comments.
> > Thanks, > Eduard > >> >> > -- or have it generated programmatically at startup if it does not exist >> > (might be safer this way, since people might be using a different UI than >> > xwiki-enterprise-ui) >> > >> > I will start working on this locally and see if I can spot other issues, >> > but please share your thoughts. >> > >> > Thanks, >> > Eduard >> > >> > ---------- >> > [1] http://markmail.org/message/o6adfbscpidnn7zr >> > [2] http://jira.xwiki.org/browse/XWIKI-8822 >> > _______________________________________________ >> > 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 >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Mon, Mar 4, 2013 at 5:46 PM, Eduard Moraru <[email protected]> wrote:
Hi devs,
On Wed, Feb 27, 2013 at 6:34 PM, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Feb 27, 2013 at 11:21 AM, Eduard Moraru <[email protected]> wrote:
Hi devs,
To further fuel this discussion, I will mention some points that are more or less problematic when removing the notion of virtual mode (checks for xwiki.isVirtualMode()), since a direct change would leave a some pieces of code dead (never called) or just need a bit of discussion on them:
1. c.x.x.s.XWikiHibernateBaseStore.initHibernate(XWikiContext context) [1]
That piece of code seems to only run when the wiki is not in virtual mode. From what I managed to understand from Thomas [2], it's probably this case: "in your hibernate configuration if you set a database which is not called 'xwiki'. In virtual mode this configuration is not taken into account and you have to indicate the name of the database in xwiki.cfg". I think we need to review this behavior. IMO, we should do take this configuration into account in virtual mode as well, as long as there is no other technical impediment. It is a configuration for the main wiki after all, and it should still be valid.
2. c.x.x.XWiki.onPluginPreferenceEvent(Event event, XWikiDocument doc, XWikiContext context) [3]
This piece of code seems to reload the plugins if the "plugins" property changed in XWikiPreferences, but only if the wiki is not in virtual mode. I think we need to change this to happen for any wiki and the plugins need to be reloaded only for that specific wiki for which the change happened (if it is possible).
Any input on this?
3. extension.vm - extensionActionButton macro [4]
This UI code decides when to displays the (Un)Install button of an extension for the current wiki or for the entire farm. Removing the virtual mode check will always show the (un)install on farm button. I think Marius had some concerns about his one.
As I said in my comment on GitHub I think the isVirtualMode() test should be replaced in this particular case with something like hasVirtualWikis() . It makes sense to display EM buttons that target multiple wikis only if you have multiple wikis.
Adding $xwiki.hasVirtualWikis() (convenience for $xwiki.getWikiNames().size() > 1).
4. distribution.vm - displayMainUiStep_unknownPreviousUI [5]
This code assumes that if virtualMode is true, then the product is XEM, otherwise it's XE. This is used to propose old version names for the 2 products. Obviously this is needs to be refactored and use a different
way
of determining which is which.
Yes.
Any suggestions?
Maybe use the EM script service to check if the extension xwiki-enterprise-ui or xwiki-manager-ui is installed?
As discussed in private, for now it's better to use hasVirtualWikis() as a quick fix because I'm going to refactor this code soon to take the list of available versions for the configured UI so there won't be any need to distinguish between xwiki-enterprise-ui and xwiki-manager-ui. Also, with Thomas' work to support DW on subwikis we're going to split the distribution.vm template so don't spend time on distribution.vm changes because soon they will be hard to integrate. Thanks, Marius
Thanks, Eduard
Thanks, Marius
5. c.x.x.p.w.WikiManager public List<Wiki> getAllWikis(XWikiContext context) throws XWikiException [6]
We have decided that c.x.x.XWiki.getVirtualWikisDatabaseNames will also return the main wiki's name. However, the WikiManager plugin can not do this so easily because the main wiki's descriptor may not exist. How
could
we handle this, in order to be consistent? Would creating programmatically the main wiki's descriptor with default values on ApplicationReady event do any good? Will it do any harm?
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[2]
https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8...
[3]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[4]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[5]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[6]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
On Fri, Feb 22, 2013 at 3:48 PM, Eduard Moraru <[email protected]>
wrote:
Hi devs,
To be more precise, the essence of my proposed change [1] is to actually always return "true" in the isVirtualMode() method, ignoring any configuration and marking the method as @deprecated, to be removed in future versions.
Is there any reason not to do this? (Why) Would we want to preserve the possibility of going back to a non-virtual mode? (mostly addressed to Thomas, but to others as well)
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8...
On Fri, Feb 22, 2013 at 3:39 PM, Eduard Moraru <[email protected]
wrote:
Hi devs,
As some of you have already noticed and already started providing feedback (thank you), I have pushed a feature branch [1] that proposes
the
removal of the virtual mode concept (making it enabled and fixed by default).
I have also gone trough the code in xwiki-platform and removed, in the feature branch, dead code (code branches that will never be reached because of this change). Some tests were also adapted to the new change. I have also tried a build of xwiki-platform with these changes and it built successfully.
First of all, I want to make sure that we agree on the change, since Thomas already mentioned that he does not agree (but I need more details).
Second, if we agree, please take the time to look over the changes (particularly in the modules that you each have experience in) and double check that the logic of the code was not altered in any way.
I will not be merging this branch until I get a general green light from the committers, and until everybody is happy :)
Please share your opinion both on this mail and/or on the specific changes in the github commits.
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/commits/feature-deprecate-virtual-mo...
On Mon, Feb 18, 2013 at 4:53 PM, Thomas Mortagne < [email protected]> wrote:
On Mon, Feb 18, 2013 at 3:48 PM, Thomas Mortagne <[email protected]> wrote: > On Mon, Feb 18, 2013 at 3:38 PM, Eduard Moraru <
wrote: >> Hi Thomas, >> >> On Mon, Feb 18, 2013 at 3:45 PM, Thomas Mortagne >> <[email protected]>wrote: >> >>> On Mon, Feb 18, 2013 at 2:07 PM, Eduard Moraru < [email protected] > >>> wrote: >>> > Hi devs, >>> > >>> > According to the Roadmap of 5.0 [1][2] we will be deprecating the virtual >>> > mode API and moving to a virtual-by-default mode instead. >>> > >>> > The idea is that the multiwiki environment should be the default and, >>> > anyone wanting to use the single-wiki mode (as XE was doing in the past), >>> > will simply not create any subwiki. It is just pointless to have 2 >>> products >>> > for such a simple fact and it also confuses users that have downloaded >>> and >>> > started to use one product and later on realise that they needed the >>> other. >>> > Also, when installing the wiki-manager and/or workspace extension(s) >>> > (because you might want to create subwikis/workspaces), there will be no >>> > need to stop the wiki, enable-virtual mode and restart it; all will be >>> > doable in the browser. >>> > >>> > Therefore, I`m sending this mail to ask your opinion about this topic, in >>> > case you might have something to say against it, and also to brainstorm >>> on >>> > the required changes and implications on existing code so that the >>> > transition is as smooth and invisible as possible. >>> > >>> > Proposed changes: >>> > - Remove "xwiki.virtual" from xwiki.cfg(.vm) >>> > -- remove the usage of the "$xwikiCfgVirtual" maven property from >>> > xwiki-platform (, xwiki-enteprise and xwiki-manager) >>> > - Deprecate boolean com.xpn.xwiki.XWiki.isVirtualMode() (and the >>> api.XWiki >>> > version) >>> > -- change its code to ((getVirtualWikisDatabaseNames(context).size() == >>> 1) >>> > ? true : false) until it is removed by the deprecation process. >>> >>> -1. It means that you are going to be in non virtual mode when >>> starting XEM which is very wrong and the complete opposite of what we >>> want here. We should deprecate and don't touch it's implementation in >>> any way other that returning true by default instead of false when >>> there is nothing in the configuration. Again as you said the goal is >>> to be in virtual mode by default, period. If the UI want to do >>> something different when there is only one wiki the UI should test if >>> there is only one wiki but breaking all extensions counting on the >>> virtual mode is very bad API breakage. >>> >> >> I agree. The isVirtualMode check was supposed to tell you if "there can be >> more than one wiki", while I was suggesting to transform it to "are there >> currently more than one wikis?", which is obviously not equivalent. >> >> >>> > >>> > Possibly needed changes: >>> > - Add main wiki default descriptor to xwiki-enterprise-ui (so that >>> > getVirtualWikisDatabaseNames includes the main wiki and also to avoid DNS >>> > issues (?) caused by how we handle virtual mode) >>> >>> This is useless IMO: >>> * the fact that getVirtualWikisDatabaseNames does not return the main >>> wiki when there is no descriptor for it is a bug that should be fixed >>> >> >> Ok. I have created the jira issue for it: >> http://jira.xwiki.org/browse/XWIKI-8829 >> >> Also, on the same topic, I think that we should also expose the >> getVirtualWikisDatabaseNames method in api.XWiki. Maybe we should rename it >> to something simpler like api.XWiki.getAllWikis() or getAllWikiNames(). > > Yes, "getVirtualWikisDatabaseNames" is not very nice.
This name is also pretty wrong btw since that's wiki names and not database names which could be very different.
> >> >> >>> * I don't see how having a descriptor with localhost in it will help >>> in any way not having DNS issue, it's not helping much in XEM it's not >>> going to be better in XE. IMO the right solution is to fallback on >>> main wiki by default when the wiki is unknown instead of sending a >>> redirect to some URL which cannot work and only allow to enable this >>> redirect URL as an option >>> >> >> Ok, so we comment out xwiki.virtual.redirect in xwiki.cfg and, by default, >> redirect to the main wiki's Main.WebHome. > > I carefully chose "fallback" and not "redirect" because a real > redirect is impossible here since no URL will really be right or the > main wiki. The idea would be to do exactly the same thing we do with > IP, www.*,. > >> >> An existing jira issue that is very related to this topic is >> http://jira.xwiki.org/browse/XWIKI-479 We could reuse that. > > Yes we can reuse it but not follow the proposal in the comments. > >> >> Thanks, >> Eduard >> >>> >>> > -- or have it generated programmatically at startup if it does not exist >>> > (might be safer this way, since people might be using a different UI than >>> > xwiki-enterprise-ui) >>> > >>> > I will start working on this locally and see if I can spot other issues, >>> > but please share your thoughts. >>> > >>> > Thanks, >>> > Eduard >>> > >>> > ---------- >>> > [1] http://markmail.org/message/o6adfbscpidnn7zr >>> > [2] http://jira.xwiki.org/browse/XWIKI-8822 >>> > _______________________________________________ >>> > 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 >>> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Mar 4, 2013, at 9:23 PM, Marius Dumitru Florea <[email protected]> wrote:
On Mon, Mar 4, 2013 at 5:46 PM, Eduard Moraru <[email protected]> wrote:
Hi devs,
On Wed, Feb 27, 2013 at 6:34 PM, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Feb 27, 2013 at 11:21 AM, Eduard Moraru <[email protected]> wrote:
Hi devs,
To further fuel this discussion, I will mention some points that are more or less problematic when removing the notion of virtual mode (checks for xwiki.isVirtualMode()), since a direct change would leave a some pieces of code dead (never called) or just need a bit of discussion on them:
1. c.x.x.s.XWikiHibernateBaseStore.initHibernate(XWikiContext context) [1]
That piece of code seems to only run when the wiki is not in virtual mode. From what I managed to understand from Thomas [2], it's probably this case: "in your hibernate configuration if you set a database which is not called 'xwiki'. In virtual mode this configuration is not taken into account and you have to indicate the name of the database in xwiki.cfg". I think we need to review this behavior. IMO, we should do take this configuration into account in virtual mode as well, as long as there is no other technical impediment. It is a configuration for the main wiki after all, and it should still be valid.
2. c.x.x.XWiki.onPluginPreferenceEvent(Event event, XWikiDocument doc, XWikiContext context) [3]
This piece of code seems to reload the plugins if the "plugins" property changed in XWikiPreferences, but only if the wiki is not in virtual mode. I think we need to change this to happen for any wiki and the plugins need to be reloaded only for that specific wiki for which the change happened (if it is possible).
Any input on this?
3. extension.vm - extensionActionButton macro [4]
This UI code decides when to displays the (Un)Install button of an extension for the current wiki or for the entire farm. Removing the virtual mode check will always show the (un)install on farm button. I think Marius had some concerns about his one.
As I said in my comment on GitHub I think the isVirtualMode() test should be replaced in this particular case with something like hasVirtualWikis() . It makes sense to display EM buttons that target multiple wikis only if you have multiple wikis.
Adding $xwiki.hasVirtualWikis() (convenience for $xwiki.getWikiNames().size() > 1).
4. distribution.vm - displayMainUiStep_unknownPreviousUI [5]
This code assumes that if virtualMode is true, then the product is XEM, otherwise it's XE. This is used to propose old version names for the 2 products. Obviously this is needs to be refactored and use a different
way
of determining which is which.
Yes.
Any suggestions?
Maybe use the EM script service to check if the extension xwiki-enterprise-ui or xwiki-manager-ui is installed?
As discussed in private, for now it's better to use hasVirtualWikis()
Just make sure you don't call it like this :) See the comments on http://jira.xwiki.org/jira/browse/XWIKI-8875 Thanks -Vincent
as a quick fix because I'm going to refactor this code soon to take the list of available versions for the configured UI so there won't be any need to distinguish between xwiki-enterprise-ui and xwiki-manager-ui. Also, with Thomas' work to support DW on subwikis we're going to split the distribution.vm template so don't spend time on distribution.vm changes because soon they will be hard to integrate.
Thanks, Marius
Thanks, Eduard
Thanks, Marius
5. c.x.x.p.w.WikiManager public List<Wiki> getAllWikis(XWikiContext context) throws XWikiException [6]
We have decided that c.x.x.XWiki.getVirtualWikisDatabaseNames will also return the main wiki's name. However, the WikiManager plugin can not do this so easily because the main wiki's descriptor may not exist. How
could
we handle this, in order to be consistent? Would creating programmatically the main wiki's descriptor with default values on ApplicationReady event do any good? Will it do any harm?
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[2]
https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8...
[3]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[4]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[5]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[6]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
On Fri, Feb 22, 2013 at 3:48 PM, Eduard Moraru <[email protected]>
wrote:
Hi devs,
To be more precise, the essence of my proposed change [1] is to actually always return "true" in the isVirtualMode() method, ignoring any configuration and marking the method as @deprecated, to be removed in future versions.
Is there any reason not to do this? (Why) Would we want to preserve the possibility of going back to a non-virtual mode? (mostly addressed to Thomas, but to others as well)
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8...
On Fri, Feb 22, 2013 at 3:39 PM, Eduard Moraru <[email protected]
wrote:
Hi devs,
As some of you have already noticed and already started providing feedback (thank you), I have pushed a feature branch [1] that proposes
the
removal of the virtual mode concept (making it enabled and fixed by default).
I have also gone trough the code in xwiki-platform and removed, in the feature branch, dead code (code branches that will never be reached because of this change). Some tests were also adapted to the new change. I have also tried a build of xwiki-platform with these changes and it built successfully.
First of all, I want to make sure that we agree on the change, since Thomas already mentioned that he does not agree (but I need more details).
Second, if we agree, please take the time to look over the changes (particularly in the modules that you each have experience in) and double check that the logic of the code was not altered in any way.
I will not be merging this branch until I get a general green light from the committers, and until everybody is happy :)
Please share your opinion both on this mail and/or on the specific changes in the github commits.
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/commits/feature-deprecate-virtual-mo...
On Mon, Feb 18, 2013 at 4:53 PM, Thomas Mortagne < [email protected]> wrote:
> On Mon, Feb 18, 2013 at 3:48 PM, Thomas Mortagne > <[email protected]> wrote: >> On Mon, Feb 18, 2013 at 3:38 PM, Eduard Moraru <
> wrote: >>> Hi Thomas, >>> >>> On Mon, Feb 18, 2013 at 3:45 PM, Thomas Mortagne >>> <[email protected]>wrote: >>> >>>> On Mon, Feb 18, 2013 at 2:07 PM, Eduard Moraru < [email protected] >> >>>> wrote: >>>>> Hi devs, >>>>> >>>>> According to the Roadmap of 5.0 [1][2] we will be deprecating the > virtual >>>>> mode API and moving to a virtual-by-default mode instead. >>>>> >>>>> The idea is that the multiwiki environment should be the default > and, >>>>> anyone wanting to use the single-wiki mode (as XE was doing in the > past), >>>>> will simply not create any subwiki. It is just pointless to have 2 >>>> products >>>>> for such a simple fact and it also confuses users that have > downloaded >>>> and >>>>> started to use one product and later on realise that they needed > the >>>> other. >>>>> Also, when installing the wiki-manager and/or workspace > extension(s) >>>>> (because you might want to create subwikis/workspaces), there will > be no >>>>> need to stop the wiki, enable-virtual mode and restart it; all > will be >>>>> doable in the browser. >>>>> >>>>> Therefore, I`m sending this mail to ask your opinion about this > topic, in >>>>> case you might have something to say against it, and also to > brainstorm >>>> on >>>>> the required changes and implications on existing code so that the >>>>> transition is as smooth and invisible as possible. >>>>> >>>>> Proposed changes: >>>>> - Remove "xwiki.virtual" from xwiki.cfg(.vm) >>>>> -- remove the usage of the "$xwikiCfgVirtual" maven property from >>>>> xwiki-platform (, xwiki-enteprise and xwiki-manager) >>>>> - Deprecate boolean com.xpn.xwiki.XWiki.isVirtualMode() (and the >>>> api.XWiki >>>>> version) >>>>> -- change its code to > ((getVirtualWikisDatabaseNames(context).size() == >>>> 1) >>>>> ? true : false) until it is removed by the deprecation process. >>>> >>>> -1. It means that you are going to be in non virtual mode when >>>> starting XEM which is very wrong and the complete opposite of what we >>>> want here. We should deprecate and don't touch it's implementation in >>>> any way other that returning true by default instead of false when >>>> there is nothing in the configuration. Again as you said the goal is >>>> to be in virtual mode by default, period. If the UI want to do >>>> something different when there is only one wiki the UI should test if >>>> there is only one wiki but breaking all extensions counting on the >>>> virtual mode is very bad API breakage. >>>> >>> >>> I agree. The isVirtualMode check was supposed to tell you if "there > can be >>> more than one wiki", while I was suggesting to transform it to "are > there >>> currently more than one wikis?", which is obviously not equivalent. >>> >>> >>>>> >>>>> Possibly needed changes: >>>>> - Add main wiki default descriptor to xwiki-enterprise-ui (so that >>>>> getVirtualWikisDatabaseNames includes the main wiki and also to > avoid DNS >>>>> issues (?) caused by how we handle virtual mode) >>>> >>>> This is useless IMO: >>>> * the fact that getVirtualWikisDatabaseNames does not return the main >>>> wiki when there is no descriptor for it is a bug that should be fixed >>>> >>> >>> Ok. I have created the jira issue for it: >>> http://jira.xwiki.org/browse/XWIKI-8829 >>> >>> Also, on the same topic, I think that we should also expose the >>> getVirtualWikisDatabaseNames method in api.XWiki. Maybe we should > rename it >>> to something simpler like api.XWiki.getAllWikis() or > getAllWikiNames(). >> >> Yes, "getVirtualWikisDatabaseNames" is not very nice. > > This name is also pretty wrong btw since that's wiki names and not > database names which could be very different. > >> >>> >>> >>>> * I don't see how having a descriptor with localhost in it will help >>>> in any way not having DNS issue, it's not helping much in XEM it's > not >>>> going to be better in XE. IMO the right solution is to fallback on >>>> main wiki by default when the wiki is unknown instead of sending a >>>> redirect to some URL which cannot work and only allow to enable this >>>> redirect URL as an option >>>> >>> >>> Ok, so we comment out xwiki.virtual.redirect in xwiki.cfg and, by > default, >>> redirect to the main wiki's Main.WebHome. >> >> I carefully chose "fallback" and not "redirect" because a real >> redirect is impossible here since no URL will really be right or the >> main wiki. The idea would be to do exactly the same thing we do with >> IP, www.*,. >> >>> >>> An existing jira issue that is very related to this topic is >>> http://jira.xwiki.org/browse/XWIKI-479 We could reuse that. >> >> Yes we can reuse it but not follow the proposal in the comments. >> >>> >>> Thanks, >>> Eduard >>> >>>> >>>>> -- or have it generated programmatically at startup if it does not > exist >>>>> (might be safer this way, since people might be using a different > UI than >>>>> xwiki-enterprise-ui) >>>>> >>>>> I will start working on this locally and see if I can spot other > issues, >>>>> but please share your thoughts. >>>>> >>>>> Thanks, >>>>> Eduard >>>>> >>>>> ---------- >>>>> [1] http://markmail.org/message/o6adfbscpidnn7zr >>>>> [2] http://jira.xwiki.org/browse/XWIKI-8822 >>>>> _____________________________________
On Mon, Mar 4, 2013 at 10:37 PM, Vincent Massol <[email protected]> wrote:
On Mar 4, 2013, at 9:23 PM, Marius Dumitru Florea <[email protected]> wrote:
On Mon, Mar 4, 2013 at 5:46 PM, Eduard Moraru <[email protected]> wrote:
Hi devs,
On Wed, Feb 27, 2013 at 6:34 PM, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Feb 27, 2013 at 11:21 AM, Eduard Moraru <[email protected]> wrote:
Hi devs,
To further fuel this discussion, I will mention some points that are more or less problematic when removing the notion of virtual mode (checks for xwiki.isVirtualMode()), since a direct change would leave a some pieces of code dead (never called) or just need a bit of discussion on them:
1. c.x.x.s.XWikiHibernateBaseStore.initHibernate(XWikiContext context) [1]
That piece of code seems to only run when the wiki is not in virtual mode. From what I managed to understand from Thomas [2], it's probably this case: "in your hibernate configuration if you set a database which is not called 'xwiki'. In virtual mode this configuration is not taken into account and you have to indicate the name of the database in xwiki.cfg". I think we need to review this behavior. IMO, we should do take this configuration into account in virtual mode as well, as long as there is no other technical impediment. It is a configuration for the main wiki after all, and it should still be valid.
2. c.x.x.XWiki.onPluginPreferenceEvent(Event event, XWikiDocument doc, XWikiContext context) [3]
This piece of code seems to reload the plugins if the "plugins" property changed in XWikiPreferences, but only if the wiki is not in virtual mode. I think we need to change this to happen for any wiki and the plugins need to be reloaded only for that specific wiki for which the change happened (if it is possible).
Any input on this?
3. extension.vm - extensionActionButton macro [4]
This UI code decides when to displays the (Un)Install button of an extension for the current wiki or for the entire farm. Removing the virtual mode check will always show the (un)install on farm button. I think Marius had some concerns about his one.
As I said in my comment on GitHub I think the isVirtualMode() test should be replaced in this particular case with something like hasVirtualWikis() . It makes sense to display EM buttons that target multiple wikis only if you have multiple wikis.
Adding $xwiki.hasVirtualWikis() (convenience for $xwiki.getWikiNames().size() > 1).
4. distribution.vm - displayMainUiStep_unknownPreviousUI [5]
This code assumes that if virtualMode is true, then the product is XEM, otherwise it's XE. This is used to propose old version names for the 2 products. Obviously this is needs to be refactored and use a different
way
of determining which is which.
Yes.
Any suggestions?
Maybe use the EM script service to check if the extension xwiki-enterprise-ui or xwiki-manager-ui is installed?
As discussed in private, for now it's better to use hasVirtualWikis()
Just make sure you don't call it like this :)
That's the code-name ;) Thanks, Marius
See the comments on http://jira.xwiki.org/jira/browse/XWIKI-8875
Thanks -Vincent
as a quick fix because I'm going to refactor this code soon to take the list of available versions for the configured UI so there won't be any need to distinguish between xwiki-enterprise-ui and xwiki-manager-ui. Also, with Thomas' work to support DW on subwikis we're going to split the distribution.vm template so don't spend time on distribution.vm changes because soon they will be hard to integrate.
Thanks, Marius
Thanks, Eduard
Thanks, Marius
5. c.x.x.p.w.WikiManager public List<Wiki> getAllWikis(XWikiContext context) throws XWikiException [6]
We have decided that c.x.x.XWiki.getVirtualWikisDatabaseNames will also return the main wiki's name. However, the WikiManager plugin can not do this so easily because the main wiki's descriptor may not exist. How
could
we handle this, in order to be consistent? Would creating programmatically the main wiki's descriptor with default values on ApplicationReady event do any good? Will it do any harm?
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[2]
https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8...
[3]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[4]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[5]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[6]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
On Fri, Feb 22, 2013 at 3:48 PM, Eduard Moraru <[email protected]>
wrote:
Hi devs,
To be more precise, the essence of my proposed change [1] is to actually always return "true" in the isVirtualMode() method, ignoring any configuration and marking the method as @deprecated, to be removed in future versions.
Is there any reason not to do this? (Why) Would we want to preserve the possibility of going back to a non-virtual mode? (mostly addressed to Thomas, but to others as well)
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8...
On Fri, Feb 22, 2013 at 3:39 PM, Eduard Moraru <[email protected]
wrote:
> Hi devs, > > As some of you have already noticed and already started providing > feedback (thank you), I have pushed a feature branch [1] that proposes
the
> removal of the virtual mode concept (making it enabled and fixed by > default). > > I have also gone trough the code in xwiki-platform and removed, in the > feature branch, dead code (code branches that will never be reached because > of this change). Some tests were also adapted to the new change. I have > also tried a build of xwiki-platform with these changes and it built > successfully. > > First of all, I want to make sure that we agree on the change, since > Thomas already mentioned that he does not agree (but I need more details). > > Second, if we agree, please take the time to look over the changes > (particularly in the modules that you each have experience in) and double > check that the logic of the code was not altered in any way. > > I will not be merging this branch until I get a general green light from > the committers, and until everybody is happy :) > > Please share your opinion both on this mail and/or on the specific > changes in the github commits. > > Thanks, > Eduard > > ---------- > [1] > https://github.com/xwiki/xwiki-platform/commits/feature-deprecate-virtual-mo... > > > > On Mon, Feb 18, 2013 at 4:53 PM, Thomas Mortagne < > [email protected]> wrote: > >> On Mon, Feb 18, 2013 at 3:48 PM, Thomas Mortagne >> <[email protected]> wrote: >>> On Mon, Feb 18, 2013 at 3:38 PM, Eduard Moraru < [email protected]> >> wrote: >>>> Hi Thomas, >>>> >>>> On Mon, Feb 18, 2013 at 3:45 PM, Thomas Mortagne >>>> <[email protected]>wrote: >>>> >>>>> On Mon, Feb 18, 2013 at 2:07 PM, Eduard Moraru < [email protected] >>> >>>>> wrote: >>>>>> Hi devs, >>>>>> >>>>>> According to the Roadmap of 5.0 [1][2] we will be deprecating the >> virtual >>>>>> mode API and moving to a virtual-by-default mode instead. >>>>>> >>>>>> The idea is that the multiwiki environment should be the default >> and, >>>>>> anyone wanting to use the single-wiki mode (as XE was doing in the >> past), >>>>>> will simply not create any subwiki. It is just pointless to have 2 >>>>> products >>>>>> for such a simple fact and it also confuses users that have >> downloaded >>>>> and >>>>>> started to use one product and later on realise that they needed >> the >>>>> other. >>>>>> Also, when installing the wiki-manager and/or workspace >> extension(s) >>>>>> (because you might want to create subwikis/workspaces), there will >> be no >>>>>> need to stop the wiki, enable-virtual mode and restart it; all >> will be >>>>>> doable in the browser. >>>>>> >>>>>> Therefore, I`m sending this mail to ask your opinion about this >> topic, in >>>>>> case you might have something to say against it, and also to >> brainstorm >>>>> on >>>>>> the required changes and implications on existing code so that the >>>>>> transition is as smooth and invisible as possible. >>>>>> >>>>>> Proposed changes: >>>>>> - Remove "xwiki.virtual" from xwiki.cfg(.vm) >>>>>> -- remove the usage of the "$xwikiCfgVirtual" maven property from >>>>>> xwiki-platform (, xwiki-enteprise and xwiki-manager) >>>>>> - Deprecate boolean com.xpn.xwiki.XWiki.isVirtualMode() (and the >>>>> api.XWiki >>>>>> version) >>>>>> -- change its code to >> ((getVirtualWikisDatabaseNames(context).size() == >>>>> 1) >>>>>> ? true : false) until it is removed by the deprecation process. >>>>> >>>>> -1. It means that you are going to be in non virtual mode when >>>>> starting XEM which is very wrong and the complete opposite of what we >>>>> want here. We should deprecate and don't touch it's implementation in >>>>> any way other that returning true by default instead of false when >>>>> there is nothing in the configuration. Again as you said the goal is >>>>> to be in virtual mode by default, period. If the UI want to do >>>>> something different when there is only one wiki the UI should test if >>>>> there is only one wiki but breaking all extensions counting on the >>>>> virtual mode is very bad API breakage. >>>>> >>>> >>>> I agree. The isVirtualMode check was supposed to tell you if "there >> can be >>>> more than one wiki", while I was suggesting to transform it to "are >> there >>>> currently more than one wikis?", which is obviously not equivalent. >>>> >>>> >>>>>> >>>>>> Possibly needed changes: >>>>>> - Add main wiki default descriptor to xwiki-enterprise-ui (so that >>>>>> getVirtualWikisDatabaseNames includes the main wiki and also to >> avoid DNS >>>>>> issues (?) caused by how we handle virtual mode) >>>>> >>>>> This is useless IMO: >>>>> * the fact that getVirtualWikisDatabaseNames does not return the main >>>>> wiki when there is no descriptor for it is a bug that should be fixed >>>>> >>>> >>>> Ok. I have created the jira issue for it: >>>> http://jira.xwiki.org/browse/XWIKI-8829 >>>> >>>> Also, on the same topic, I think that we should also expose the >>>> getVirtualWikisDatabaseNames method in api.XWiki. Maybe we should >> rename it >>>> to something simpler like api.XWiki.getAllWikis() or >> getAllWikiNames(). >>> >>> Yes, "getVirtualWikisDatabaseNames" is not very nice. >> >> This name is also pretty wrong btw since that's wiki names and not >> database names which could be very different. >> >>> >>>> >>>> >>>>> * I don't see how having a descriptor with localhost in it will help >>>>> in any way not having DNS issue, it's not helping much in XEM it's >> not >>>>> going to be better in XE. IMO the right solution is to fallback on >>>>> main wiki by default when the wiki is unknown instead of sending a >>>>> redirect to some URL which cannot work and only allow to enable this >>>>> redirect URL as an option >>>>> >>>> >>>> Ok, so we comment out xwiki.virtual.redirect in xwiki.cfg and, by >> default, >>>> redirect to the main wiki's Main.WebHome. >>> >>> I carefully chose "fallback" and not "redirect" because a real >>> redirect is impossible here since no URL will really be right or the >>> main wiki. The idea would be to do exactly the same thing we do with >>> IP, www.*,. >>> >>>> >>>> An existing jira issue that is very related to this topic is >>>> http://jira.xwiki.org/browse/XWIKI-479 We could reuse that. >>> >>> Yes we can reuse it but not follow the proposal in the comments. >>> >>>> >>>> Thanks, >>>> Eduard >>>> >>>>> >>>>>> -- or have it generated programmatically at startup if it does not >> exist >>>>>> (might be safer this way, since people might be using a different >> UI than >>>>>> xwiki-enterprise-ui) >>>>>> >>>>>> I will start working on this locally and see if I can spot other >> issues, >>>>>> but please share your thoughts. >>>>>> >>>>>> Thanks, >>>>>> Eduard >>>>>> >>>>>> ---------- >>>>>> [1] http://markmail.org/message/o6adfbscpidnn7zr >>>>>> [2] http://jira.xwiki.org/browse/XWIKI-8822 >>>>>> _____________________________________
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi again Eduard, Regarding point 5., this is where it may get complex to support properly existing configuration file. So, the first question would be to know if we accept to disrupt upgraded wiki that use an old configuration file ? If the answer is yes, than good release notes should allow explaining how to be careful and adapt existing configuration to avoid unreachable wiki. Personally, causing such disruption has not my preference, since upgrading has not done so until now, AFAIK. Moreover, IMO being able to put by configuration the main wiki unreachable could only cause a negative feeling to newcomers. Option like autowww is probably useless complexity for the benefit. And the worse is the unknown wiki page that is never reach since it come from the main wiki to say it is itself unreachable (XWIKI-479). What you propose is not so easy, since creating the descriptor implies knowing the hostname when usepath=0 which may happen in old config even if unused. So here is what I would suggest: 1) Follow Thomas proposal: ensure getVirtualWikisDatabaseNames() always return the main wiki, even when no descriptor is available, but not by creating such descriptor. This ensure main wiki availability anytime. 2) Stop using a redirect to reach the unknown wiki page. This is also annoying for a simple typo in an URL since you loose that URL from the address bar. I see no usual need for going to a page outside XWiki, so stop using that configuration and eventually provide a configuration for deciding the page name of the main wiki that will be rendered. Anyway, use a .vm like other error to render that (optional) page or a default. This way, you leave a workaround for anyone wishing to restore the old behavior (you may even suggest commented code for that in the .vm) 3) Never proceed to unknown wiki page when there is only one wiki, considering any unknown as the main. 4) Deprecate the autowww option, which is now useless 5) Optional, but would be a nice to have for global admin, allow fixing the main wiki descriptor from the unknown wiki page. With those changes, you will fix most issue regarding the reachability of wikis in virtual mode, and therefore, having virtual as the default should not be an issue anymore, whatever your configuration is. WDYT ? On Wed, Feb 27, 2013 at 10:21 AM, Eduard Moraru <[email protected]>wrote:
Hi devs,
To further fuel this discussion, I will mention some points that are more or less problematic when removing the notion of virtual mode (checks for xwiki.isVirtualMode()), since a direct change would leave a some pieces of code dead (never called) or just need a bit of discussion on them:
1. c.x.x.s.XWikiHibernateBaseStore.initHibernate(XWikiContext context) [1]
That piece of code seems to only run when the wiki is not in virtual mode. From what I managed to understand from Thomas [2], it's probably this case: "in your hibernate configuration if you set a database which is not called 'xwiki'. In virtual mode this configuration is not taken into account and you have to indicate the name of the database in xwiki.cfg". I think we need to review this behavior. IMO, we should do take this configuration into account in virtual mode as well, as long as there is no other technical impediment. It is a configuration for the main wiki after all, and it should still be valid.
2. c.x.x.XWiki.onPluginPreferenceEvent(Event event, XWikiDocument doc, XWikiContext context) [3]
This piece of code seems to reload the plugins if the "plugins" property changed in XWikiPreferences, but only if the wiki is not in virtual mode. I think we need to change this to happen for any wiki and the plugins need to be reloaded only for that specific wiki for which the change happened (if it is possible).
3. extension.vm - extensionActionButton macro [4]
This UI code decides when to displays the (Un)Install button of an extension for the current wiki or for the entire farm. Removing the virtual mode check will always show the (un)install on farm button. I think Marius had some concerns about his one.
4. distribution.vm - displayMainUiStep_unknownPreviousUI [5]
This code assumes that if virtualMode is true, then the product is XEM, otherwise it's XE. This is used to propose old version names for the 2 products. Obviously this is needs to be refactored and use a different way of determining which is which.
5. c.x.x.p.w.WikiManager public List<Wiki> getAllWikis(XWikiContext context) throws XWikiException [6]
We have decided that c.x.x.XWiki.getVirtualWikisDatabaseNames will also return the main wiki's name. However, the WikiManager plugin can not do this so easily because the main wiki's descriptor may not exist. How could we handle this, in order to be consistent? Would creating programmatically the main wiki's descriptor with default values on ApplicationReady event do any good? Will it do any harm?
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb... [2]
https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8... [3]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb... [4]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb... [5]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb... [6]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
On Fri, Feb 22, 2013 at 3:48 PM, Eduard Moraru <[email protected]> wrote:
Hi devs,
To be more precise, the essence of my proposed change [1] is to actually always return "true" in the isVirtualMode() method, ignoring any configuration and marking the method as @deprecated, to be removed in future versions.
Is there any reason not to do this? (Why) Would we want to preserve the possibility of going back to a non-virtual mode? (mostly addressed to Thomas, but to others as well)
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8...
On Fri, Feb 22, 2013 at 3:39 PM, Eduard Moraru <[email protected] wrote:
Hi devs,
As some of you have already noticed and already started providing feedback (thank you), I have pushed a feature branch [1] that proposes
the
removal of the virtual mode concept (making it enabled and fixed by default).
I have also gone trough the code in xwiki-platform and removed, in the feature branch, dead code (code branches that will never be reached because of this change). Some tests were also adapted to the new change. I have also tried a build of xwiki-platform with these changes and it built successfully.
First of all, I want to make sure that we agree on the change, since Thomas already mentioned that he does not agree (but I need more details).
Second, if we agree, please take the time to look over the changes (particularly in the modules that you each have experience in) and double check that the logic of the code was not altered in any way.
I will not be merging this branch until I get a general green light from the committers, and until everybody is happy :)
Please share your opinion both on this mail and/or on the specific changes in the github commits.
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/commits/feature-deprecate-virtual-mo...
On Mon, Feb 18, 2013 at 4:53 PM, Thomas Mortagne < [email protected]> wrote:
On Mon, Feb 18, 2013 at 3:48 PM, Thomas Mortagne <[email protected]> wrote:
On Mon, Feb 18, 2013 at 3:38 PM, Eduard Moraru <[email protected]
wrote:
Hi Thomas,
On Mon, Feb 18, 2013 at 3:45 PM, Thomas Mortagne <[email protected]>wrote:
> On Mon, Feb 18, 2013 at 2:07 PM, Eduard Moraru < [email protected]
> wrote: > > Hi devs, > > > > According to the Roadmap of 5.0 [1][2] we will be deprecating the virtual > > mode API and moving to a virtual-by-default mode instead. > > > > The idea is that the multiwiki environment should be the default and, > > anyone wanting to use the single-wiki mode (as XE was doing in the past), > > will simply not create any subwiki. It is just pointless to have 2 > products > > for such a simple fact and it also confuses users that have downloaded > and > > started to use one product and later on realise that they needed the > other. > > Also, when installing the wiki-manager and/or workspace extension(s) > > (because you might want to create subwikis/workspaces), there will be no > > need to stop the wiki, enable-virtual mode and restart it; all will be > > doable in the browser. > > > > Therefore, I`m sending this mail to ask your opinion about this topic, in > > case you might have something to say against it, and also to brainstorm > on > > the required changes and implications on existing code so that the > > transition is as smooth and invisible as possible. > > > > Proposed changes: > > - Remove "xwiki.virtual" from xwiki.cfg(.vm) > > -- remove the usage of the "$xwikiCfgVirtual" maven property from > > xwiki-platform (, xwiki-enteprise and xwiki-manager) > > - Deprecate boolean com.xpn.xwiki.XWiki.isVirtualMode() (and the > api.XWiki > > version) > > -- change its code to ((getVirtualWikisDatabaseNames(context).size() == > 1) > > ? true : false) until it is removed by the deprecation process. > > -1. It means that you are going to be in non virtual mode when > starting XEM which is very wrong and the complete opposite of what we > want here. We should deprecate and don't touch it's implementation in > any way other that returning true by default instead of false when > there is nothing in the configuration. Again as you said the goal is > to be in virtual mode by default, period. If the UI want to do > something different when there is only one wiki the UI should test if > there is only one wiki but breaking all extensions counting on the > virtual mode is very bad API breakage. >
I agree. The isVirtualMode check was supposed to tell you if "there can be more than one wiki", while I was suggesting to transform it to "are there currently more than one wikis?", which is obviously not equivalent.
> > > > Possibly needed changes: > > - Add main wiki default descriptor to xwiki-enterprise-ui (so that > > getVirtualWikisDatabaseNames includes the main wiki and also to avoid DNS > > issues (?) caused by how we handle virtual mode) > > This is useless IMO: > * the fact that getVirtualWikisDatabaseNames does not return the main > wiki when there is no descriptor for it is a bug that should be fixed >
Ok. I have created the jira issue for it: http://jira.xwiki.org/browse/XWIKI-8829
Also, on the same topic, I think that we should also expose the getVirtualWikisDatabaseNames method in api.XWiki. Maybe we should rename it to something simpler like api.XWiki.getAllWikis() or getAllWikiNames().
Yes, "getVirtualWikisDatabaseNames" is not very nice.
This name is also pretty wrong btw since that's wiki names and not database names which could be very different.
> * I don't see how having a descriptor with localhost in it will
help
> in any way not having DNS issue, it's not helping much in XEM it's not > going to be better in XE. IMO the right solution is to fallback on > main wiki by default when the wiki is unknown instead of sending a > redirect to some URL which cannot work and only allow to enable this > redirect URL as an option >
Ok, so we comment out xwiki.virtual.redirect in xwiki.cfg and, by default, redirect to the main wiki's Main.WebHome.
I carefully chose "fallback" and not "redirect" because a real redirect is impossible here since no URL will really be right or the main wiki. The idea would be to do exactly the same thing we do with IP, www.*,.
An existing jira issue that is very related to this topic is http://jira.xwiki.org/browse/XWIKI-479 We could reuse that.
Yes we can reuse it but not follow the proposal in the comments.
Thanks, Eduard
> > > -- or have it generated programmatically at startup if it does
not exist
> > (might be safer this way, since people might be using a different UI than > > xwiki-enterprise-ui) > > > > I will start working on this locally and see if I can spot other issues, > > but please share your thoughts. > > > > Thanks, > > Eduard > > > > ---------- > > [1] http://markmail.org/message/o6adfbscpidnn7zr > > [2] http://jira.xwiki.org/browse/XWIKI-8822 > > _______________________________________________ > > 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
Hi Denis, Nice feedback! Please see below... On Wed, Feb 27, 2013 at 10:23 PM, Denis Gervalle <[email protected]> wrote:
Hi again Eduard,
Regarding point 5., this is where it may get complex to support properly existing configuration file. So, the first question would be to know if we accept to disrupt upgraded wiki that use an old configuration file ? If the answer is yes, than good release notes should allow explaining how to be careful and adapt existing configuration to avoid unreachable wiki.
Personally, causing such disruption has not my preference, since upgrading has not done so until now, AFAIK. Moreover, IMO being able to put by configuration the main wiki unreachable could only cause a negative feeling to newcomers. Option like autowww is probably useless complexity for the benefit. And the worse is the unknown wiki page that is never reach since it come from the main wiki to say it is itself unreachable (XWIKI-479).
What you propose is not so easy, since creating the descriptor implies knowing the hostname when usepath=0 which may happen in old config even if unused. So here is what I would suggest:
1) Follow Thomas proposal: ensure getVirtualWikisDatabaseNames() always return the main wiki, even when no descriptor is available, but not by creating such descriptor. This ensure main wiki availability anytime.
Already done in the feature branch. However, how do we handle point 5, as I have described it wrt. the wiki-manager plugin? The getAllWikis() method basically returns the list of wiki document descriptors. While for XWiki.getVirtualWikisDatabaseNames() it was easy to add a new string to the list of results, how would we handle it for the wiki-manager plugin, where we have to add an unexistent document (with objects -- what values?) to the list of results?
2) Stop using a redirect to reach the unknown wiki page. This is also annoying for a simple typo in an URL since you loose that URL from the address bar. I see no usual need for going to a page outside XWiki, so stop using that configuration and eventually provide a configuration for deciding the page name of the main wiki that will be rendered. Anyway, use a .vm like other error to render that (optional) page or a default. This way, you leave a workaround for anyone wishing to restore the old behavior (you may even suggest commented code for that in the .vm)
I like this idea of using a vm instead of a redirect.
3) Never proceed to unknown wiki page when there is only one wiki, considering any unknown as the main.
While I theoretically agree with this, in practice it might be a bit confusing for some users that explicitly wrote a subwiki (in domain based) or maybe they have a bookmark but they end up on the main wiki, where they could continue working without realizing that they are not on the wiki they have requested. Considering this, I think I prefer to display an explicit error.
4) Deprecate the autowww option, which is now useless
I have just came across this feature, so I`m not really familiar with the details and implications. As far as I understand it, by default, we allow the main wiki to be accessed trough the "www" subdomain (if tomcat is properly configured as well, I assume), "localhost" or ip address without having a descriptor. For all other cases, we proceed to get the descriptor and, if none is found, we redirect to whatever "xwiki.virtual.redirect" says. Which part of this (except point 3 which we cleared above) are you suggesting to deprecate? The default behaviour or the option to disable this default behaviour? Please detail this a bit. 5) Optional, but would be a nice to have for global admin, allow fixing the
main wiki descriptor from the unknown wiki page.
What do you mean by "fixing the main wiki descriptor from the unknown wiki page"? Please details this a bit as well. Thanks, Eduard
With those changes, you will fix most issue regarding the reachability of wikis in virtual mode, and therefore, having virtual as the default should not be an issue anymore, whatever your configuration is.
WDYT ?
On Wed, Feb 27, 2013 at 10:21 AM, Eduard Moraru <[email protected]
wrote:
Hi devs,
To further fuel this discussion, I will mention some points that are more or less problematic when removing the notion of virtual mode (checks for xwiki.isVirtualMode()), since a direct change would leave a some pieces of code dead (never called) or just need a bit of discussion on them:
1. c.x.x.s.XWikiHibernateBaseStore.initHibernate(XWikiContext context) [1]
That piece of code seems to only run when the wiki is not in virtual mode. From what I managed to understand from Thomas [2], it's probably this case: "in your hibernate configuration if you set a database which is not called 'xwiki'. In virtual mode this configuration is not taken into account and you have to indicate the name of the database in xwiki.cfg". I think we need to review this behavior. IMO, we should do take this configuration into account in virtual mode as well, as long as there is no other technical impediment. It is a configuration for the main wiki after all, and it should still be valid.
2. c.x.x.XWiki.onPluginPreferenceEvent(Event event, XWikiDocument doc, XWikiContext context) [3]
This piece of code seems to reload the plugins if the "plugins" property changed in XWikiPreferences, but only if the wiki is not in virtual mode. I think we need to change this to happen for any wiki and the plugins need to be reloaded only for that specific wiki for which the change happened (if it is possible).
3. extension.vm - extensionActionButton macro [4]
This UI code decides when to displays the (Un)Install button of an extension for the current wiki or for the entire farm. Removing the virtual mode check will always show the (un)install on farm button. I think Marius had some concerns about his one.
4. distribution.vm - displayMainUiStep_unknownPreviousUI [5]
This code assumes that if virtualMode is true, then the product is XEM, otherwise it's XE. This is used to propose old version names for the 2 products. Obviously this is needs to be refactored and use a different way of determining which is which.
5. c.x.x.p.w.WikiManager public List<Wiki> getAllWikis(XWikiContext context) throws XWikiException [6]
We have decided that c.x.x.XWiki.getVirtualWikisDatabaseNames will also return the main wiki's name. However, the WikiManager plugin can not do this so easily because the main wiki's descriptor may not exist. How could we handle this, in order to be consistent? Would creating programmatically the main wiki's descriptor with default values on ApplicationReady event do any good? Will it do any harm?
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[2]
https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8...
[3]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[4]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[5]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[6]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
On Fri, Feb 22, 2013 at 3:48 PM, Eduard Moraru <[email protected]> wrote:
Hi devs,
To be more precise, the essence of my proposed change [1] is to
actually
always return "true" in the isVirtualMode() method, ignoring any configuration and marking the method as @deprecated, to be removed in future versions.
Is there any reason not to do this? (Why) Would we want to preserve the possibility of going back to a non-virtual mode? (mostly addressed to Thomas, but to others as well)
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8...
On Fri, Feb 22, 2013 at 3:39 PM, Eduard Moraru <[email protected] wrote:
Hi devs,
As some of you have already noticed and already started providing feedback (thank you), I have pushed a feature branch [1] that proposes
the
removal of the virtual mode concept (making it enabled and fixed by default).
I have also gone trough the code in xwiki-platform and removed, in the feature branch, dead code (code branches that will never be reached because of this change). Some tests were also adapted to the new change. I have also tried a build of xwiki-platform with these changes and it built successfully.
First of all, I want to make sure that we agree on the change, since Thomas already mentioned that he does not agree (but I need more details).
Second, if we agree, please take the time to look over the changes (particularly in the modules that you each have experience in) and double check that the logic of the code was not altered in any way.
I will not be merging this branch until I get a general green light from the committers, and until everybody is happy :)
Please share your opinion both on this mail and/or on the specific changes in the github commits.
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/commits/feature-deprecate-virtual-mo...
On Mon, Feb 18, 2013 at 4:53 PM, Thomas Mortagne < [email protected]> wrote:
On Mon, Feb 18, 2013 at 3:48 PM, Thomas Mortagne <[email protected]> wrote:
On Mon, Feb 18, 2013 at 3:38 PM, Eduard Moraru <
wrote:
> Hi Thomas, > > On Mon, Feb 18, 2013 at 3:45 PM, Thomas Mortagne > <[email protected]>wrote: > >> On Mon, Feb 18, 2013 at 2:07 PM, Eduard Moraru < [email protected]
>> wrote: >> > Hi devs, >> > >> > According to the Roadmap of 5.0 [1][2] we will be deprecating the virtual >> > mode API and moving to a virtual-by-default mode instead. >> > >> > The idea is that the multiwiki environment should be the default and, >> > anyone wanting to use the single-wiki mode (as XE was doing in the past), >> > will simply not create any subwiki. It is just pointless to have 2 >> products >> > for such a simple fact and it also confuses users that have downloaded >> and >> > started to use one product and later on realise that they needed the >> other. >> > Also, when installing the wiki-manager and/or workspace extension(s) >> > (because you might want to create subwikis/workspaces), there will be no >> > need to stop the wiki, enable-virtual mode and restart it; all will be >> > doable in the browser. >> > >> > Therefore, I`m sending this mail to ask your opinion about this topic, in >> > case you might have something to say against it, and also to brainstorm >> on >> > the required changes and implications on existing code so that the >> > transition is as smooth and invisible as possible. >> > >> > Proposed changes: >> > - Remove "xwiki.virtual" from xwiki.cfg(.vm) >> > -- remove the usage of the "$xwikiCfgVirtual" maven property from >> > xwiki-platform (, xwiki-enteprise and xwiki-manager) >> > - Deprecate boolean com.xpn.xwiki.XWiki.isVirtualMode() (and the >> api.XWiki >> > version) >> > -- change its code to ((getVirtualWikisDatabaseNames(context).size() == >> 1) >> > ? true : false) until it is removed by the deprecation process. >> >> -1. It means that you are going to be in non virtual mode when >> starting XEM which is very wrong and the complete opposite of what we >> want here. We should deprecate and don't touch it's implementation in >> any way other that returning true by default instead of false when >> there is nothing in the configuration. Again as you said the goal is >> to be in virtual mode by default, period. If the UI want to do >> something different when there is only one wiki the UI should test if >> there is only one wiki but breaking all extensions counting on the >> virtual mode is very bad API breakage. >> > > I agree. The isVirtualMode check was supposed to tell you if "there can be > more than one wiki", while I was suggesting to transform it to "are there > currently more than one wikis?", which is obviously not equivalent. > > >> > >> > Possibly needed changes: >> > - Add main wiki default descriptor to xwiki-enterprise-ui (so that >> > getVirtualWikisDatabaseNames includes the main wiki and also to avoid DNS >> > issues (?) caused by how we handle virtual mode) >> >> This is useless IMO: >> * the fact that getVirtualWikisDatabaseNames does not return the main >> wiki when there is no descriptor for it is a bug that should be fixed >> > > Ok. I have created the jira issue for it: > http://jira.xwiki.org/browse/XWIKI-8829 > > Also, on the same topic, I think that we should also expose the > getVirtualWikisDatabaseNames method in api.XWiki. Maybe we should rename it > to something simpler like api.XWiki.getAllWikis() or getAllWikiNames().
Yes, "getVirtualWikisDatabaseNames" is not very nice.
This name is also pretty wrong btw since that's wiki names and not database names which could be very different.
> > >> * I don't see how having a descriptor with localhost in it will
help
>> in any way not having DNS issue, it's not helping much in XEM it's not >> going to be better in XE. IMO the right solution is to fallback on >> main wiki by default when the wiki is unknown instead of sending a >> redirect to some URL which cannot work and only allow to enable this >> redirect URL as an option >> > > Ok, so we comment out xwiki.virtual.redirect in xwiki.cfg and, by default, > redirect to the main wiki's Main.WebHome.
I carefully chose "fallback" and not "redirect" because a real redirect is impossible here since no URL will really be right or the main wiki. The idea would be to do exactly the same thing we do with IP, www.*,.
> > An existing jira issue that is very related to this topic is > http://jira.xwiki.org/browse/XWIKI-479 We could reuse that.
Yes we can reuse it but not follow the proposal in the comments.
> > Thanks, > Eduard > >> >> > -- or have it generated programmatically at startup if it does not exist >> > (might be safer this way, since people might be using a different UI than >> > xwiki-enterprise-ui) >> > >> > I will start working on this locally and see if I can spot other issues, >> > but please share your thoughts. >> > >> > Thanks, >> > Eduard >> > >> > ---------- >> > [1] http://markmail.org/message/o6adfbscpidnn7zr >> > [2] http://jira.xwiki.org/browse/XWIKI-8822 >> > _______________________________________________ >> > 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 >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Edouard, On Fri, Mar 1, 2013 at 6:28 PM, Eduard Moraru <[email protected]> wrote:
Hi Denis,
Nice feedback! Please see below...
On Wed, Feb 27, 2013 at 10:23 PM, Denis Gervalle <[email protected]> wrote:
Hi again Eduard,
Regarding point 5., this is where it may get complex to support properly existing configuration file. So, the first question would be to know if we accept to disrupt upgraded wiki that use an old configuration file ? If the answer is yes, than good release notes should allow explaining how to be careful and adapt existing configuration to avoid unreachable wiki.
Personally, causing such disruption has not my preference, since upgrading has not done so until now, AFAIK. Moreover, IMO being able to put by configuration the main wiki unreachable could only cause a negative feeling to newcomers. Option like autowww is probably useless complexity for the benefit. And the worse is the unknown wiki page that is never reach since it come from the main wiki to say it is itself unreachable (XWIKI-479).
What you propose is not so easy, since creating the descriptor implies knowing the hostname when usepath=0 which may happen in old config even if unused. So here is what I would suggest:
1) Follow Thomas proposal: ensure getVirtualWikisDatabaseNames() always return the main wiki, even when no descriptor is available, but not by creating such descriptor. This ensure main wiki availability anytime.
Already done in the feature branch. However, how do we handle point 5, as I have described it wrt. the wiki-manager plugin?
The getAllWikis() method basically returns the list of wiki document descriptors. While for XWiki.getVirtualWikisDatabaseNames() it was easy to add a new string to the list of results, how would we handle it for the wiki-manager plugin, where we have to add an unexistent document (with objects -- what values?) to the list of results?
Do we really need to handle it ? In no way you may create it automatically. If the wiki manager need it, it should handle this missing descriptor properly at UI level, proposing to create the descriptor and allowing the user to complete the required information.
2) Stop using a redirect to reach the unknown wiki page. This is also annoying for a simple typo in an URL since you loose that URL from the address bar. I see no usual need for going to a page outside XWiki, so stop using that configuration and eventually provide a configuration for deciding the page name of the main wiki that will be rendered. Anyway, use a .vm like other error to render that (optional) page or a default. This way, you leave a workaround for anyone wishing to restore the old behavior (you may even suggest commented code for that in the .vm)
I like this idea of using a vm instead of a redirect.
3) Never proceed to unknown wiki page when there is only one wiki, considering any unknown as the main.
While I theoretically agree with this, in practice it might be a bit confusing for some users that explicitly wrote a subwiki (in domain based) or maybe they have a bookmark but they end up on the main wiki, where they could continue working without realizing that they are not on the wiki they have requested.
Considering this, I think I prefer to display an explicit error.
I do not understand your use case ? What I have said is that if there is only a single main wiki, and no subwiki, never display the unknown wiki page, but reach the main wiki whatever the domain name is. If you don't, you do not fix several potential unreachable wiki issue that may arise by simple enabling virtual mode. I do not see the point of showing an error when there is only one available wiki.
4) Deprecate the autowww option, which is now useless
I have just came across this feature, so I`m not really familiar with the details and implications. As far as I understand it, by default, we allow the main wiki to be accessed trough the "www" subdomain (if tomcat is properly configured as well, I assume), "localhost" or ip address without having a descriptor. For all other cases, we proceed to get the descriptor and, if none is found, we redirect to whatever "xwiki.virtual.redirect" says.
Which part of this (except point 3 which we cleared above) are you suggesting to deprecate? The default behaviour or the option to disable this default behaviour? Please detail this a bit.
This exactly what it does, ensure accessibility to the main wiki through the IP, www subdomain and localhost, whatever the descriptor of the main wiki is. By default that feature is enable, so the option allow disabling. As you said yourself, you do not really understand that feature. This is why I am proposing to phase it out (no real change in code for now, simply stating this is deprecated). After a second thought, there may be one case where you need it, when you want to have a subwiki on www. Why not simply checking that no descriptor works for www before going to the main in that special case. For the IP and localhost, I do not see any reason to disable them.
5) Optional, but would be a nice to have for global admin, allow fixing the
main wiki descriptor from the unknown wiki page.
What do you mean by "fixing the main wiki descriptor from the unknown wiki page"? Please details this a bit as well.
Well, if the user is a global admin, provide through the unknown wiki error page a suggestion to access the main wiki or a way to fix up the main wiki descriptor to reestablish its access easily. I dislike the idea of having a dead end. But it is the icing on the cake. Thanks,
Thanks, Eduard
With those changes, you will fix most issue regarding the reachability of wikis in virtual mode, and therefore, having virtual as the default should not be an issue anymore, whatever your configuration is.
WDYT ?
On Wed, Feb 27, 2013 at 10:21 AM, Eduard Moraru <[email protected]
wrote:
Hi devs,
To further fuel this discussion, I will mention some points that are more or less problematic when removing the notion of virtual mode (checks for xwiki.isVirtualMode()), since a direct change would leave a some pieces of code dead (never called) or just need a bit of discussion on them:
1. c.x.x.s.XWikiHibernateBaseStore.initHibernate(XWikiContext context) [1]
That piece of code seems to only run when the wiki is not in virtual mode. From what I managed to understand from Thomas [2], it's probably this case: "in your hibernate configuration if you set a database which is not called 'xwiki'. In virtual mode this configuration is not taken into account and you have to indicate the name of the database in xwiki.cfg". I think we need to review this behavior. IMO, we should do take this configuration into account in virtual mode as well, as long as there is no other technical impediment. It is a configuration for the main wiki after all, and it should still be valid.
2. c.x.x.XWiki.onPluginPreferenceEvent(Event event, XWikiDocument doc, XWikiContext context) [3]
This piece of code seems to reload the plugins if the "plugins" property changed in XWikiPreferences, but only if the wiki is not in virtual mode. I think we need to change this to happen for any wiki and the plugins need to be reloaded only for that specific wiki for which the change happened (if it is possible).
3. extension.vm - extensionActionButton macro [4]
This UI code decides when to displays the (Un)Install button of an extension for the current wiki or for the entire farm. Removing the virtual mode check will always show the (un)install on farm button. I think Marius had some concerns about his one.
4. distribution.vm - displayMainUiStep_unknownPreviousUI [5]
This code assumes that if virtualMode is true, then the product is XEM, otherwise it's XE. This is used to propose old version names for the 2 products. Obviously this is needs to be refactored and use a different way of determining which is which.
5. c.x.x.p.w.WikiManager public List<Wiki> getAllWikis(XWikiContext context) throws XWikiException [6]
We have decided that c.x.x.XWiki.getVirtualWikisDatabaseNames will also return the main wiki's name. However, the WikiManager plugin can not do this so easily because the main wiki's descriptor may not exist. How could we handle this, in order to be consistent? Would creating programmatically the main wiki's descriptor with default values on ApplicationReady event do any good? Will it do any harm?
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[2]
https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8...
[3]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[4]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[5]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[6]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
On Fri, Feb 22, 2013 at 3:48 PM, Eduard Moraru <[email protected]> wrote:
Hi devs,
To be more precise, the essence of my proposed change [1] is to
actually
always return "true" in the isVirtualMode() method, ignoring any configuration and marking the method as @deprecated, to be removed in future versions.
Is there any reason not to do this? (Why) Would we want to preserve the possibility of going back to a non-virtual mode? (mostly addressed to Thomas, but to others as well)
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8...
On Fri, Feb 22, 2013 at 3:39 PM, Eduard Moraru <[email protected] wrote:
Hi devs,
As some of you have already noticed and already started providing feedback (thank you), I have pushed a feature branch [1] that
proposes the
removal of the virtual mode concept (making it enabled and fixed by default).
I have also gone trough the code in xwiki-platform and removed, in the feature branch, dead code (code branches that will never be reached because of this change). Some tests were also adapted to the new change. I have also tried a build of xwiki-platform with these changes and it built successfully.
First of all, I want to make sure that we agree on the change, since Thomas already mentioned that he does not agree (but I need more details).
Second, if we agree, please take the time to look over the changes (particularly in the modules that you each have experience in) and double check that the logic of the code was not altered in any way.
I will not be merging this branch until I get a general green light from the committers, and until everybody is happy :)
Please share your opinion both on this mail and/or on the specific changes in the github commits.
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/commits/feature-deprecate-virtual-mo...
On Mon, Feb 18, 2013 at 4:53 PM, Thomas Mortagne < [email protected]> wrote:
On Mon, Feb 18, 2013 at 3:48 PM, Thomas Mortagne <[email protected]> wrote: > On Mon, Feb 18, 2013 at 3:38 PM, Eduard Moraru <
wrote: >> Hi Thomas, >> >> On Mon, Feb 18, 2013 at 3:45 PM, Thomas Mortagne >> <[email protected]>wrote: >> >>> On Mon, Feb 18, 2013 at 2:07 PM, Eduard Moraru < [email protected] > >>> wrote: >>> > Hi devs, >>> > >>> > According to the Roadmap of 5.0 [1][2] we will be deprecating the virtual >>> > mode API and moving to a virtual-by-default mode instead. >>> > >>> > The idea is that the multiwiki environment should be the default and, >>> > anyone wanting to use the single-wiki mode (as XE was doing in the past), >>> > will simply not create any subwiki. It is just pointless to have 2 >>> products >>> > for such a simple fact and it also confuses users that have downloaded >>> and >>> > started to use one product and later on realise that they needed the >>> other. >>> > Also, when installing the wiki-manager and/or workspace extension(s) >>> > (because you might want to create subwikis/workspaces), there will be no >>> > need to stop the wiki, enable-virtual mode and restart it; all will be >>> > doable in the browser. >>> > >>> > Therefore, I`m sending this mail to ask your opinion about this topic, in >>> > case you might have something to say against it, and also to brainstorm >>> on >>> > the required changes and implications on existing code so that the >>> > transition is as smooth and invisible as possible. >>> > >>> > Proposed changes: >>> > - Remove "xwiki.virtual" from xwiki.cfg(.vm) >>> > -- remove the usage of the "$xwikiCfgVirtual" maven property from >>> > xwiki-platform (, xwiki-enteprise and xwiki-manager) >>> > - Deprecate boolean com.xpn.xwiki.XWiki.isVirtualMode() (and the >>> api.XWiki >>> > version) >>> > -- change its code to ((getVirtualWikisDatabaseNames(context).size() == >>> 1) >>> > ? true : false) until it is removed by the deprecation process. >>> >>> -1. It means that you are going to be in non virtual mode when >>> starting XEM which is very wrong and the complete opposite of what we >>> want here. We should deprecate and don't touch it's implementation in >>> any way other that returning true by default instead of false when >>> there is nothing in the configuration. Again as you said the goal is >>> to be in virtual mode by default, period. If the UI want to do >>> something different when there is only one wiki the UI should test if >>> there is only one wiki but breaking all extensions counting on the >>> virtual mode is very bad API breakage. >>> >> >> I agree. The isVirtualMode check was supposed to tell you if "there can be >> more than one wiki", while I was suggesting to transform it to "are there >> currently more than one wikis?", which is obviously not equivalent. >> >> >>> > >>> > Possibly needed changes: >>> > - Add main wiki default descriptor to xwiki-enterprise-ui (so that >>> > getVirtualWikisDatabaseNames includes the main wiki and also to avoid DNS >>> > issues (?) caused by how we handle virtual mode) >>> >>> This is useless IMO: >>> * the fact that getVirtualWikisDatabaseNames does not return the main >>> wiki when there is no descriptor for it is a bug that should be fixed >>> >> >> Ok. I have created the jira issue for it: >> http://jira.xwiki.org/browse/XWIKI-8829 >> >> Also, on the same topic, I think that we should also expose the >> getVirtualWikisDatabaseNames method in api.XWiki. Maybe we should rename it >> to something simpler like api.XWiki.getAllWikis() or getAllWikiNames(). > > Yes, "getVirtualWikisDatabaseNames" is not very nice.
This name is also pretty wrong btw since that's wiki names and not database names which could be very different.
> >> >> >>> * I don't see how having a descriptor with localhost in it will help >>> in any way not having DNS issue, it's not helping much in XEM it's not >>> going to be better in XE. IMO the right solution is to fallback on >>> main wiki by default when the wiki is unknown instead of sending a >>> redirect to some URL which cannot work and only allow to enable this >>> redirect URL as an option >>> >> >> Ok, so we comment out xwiki.virtual.redirect in xwiki.cfg and, by default, >> redirect to the main wiki's Main.WebHome. > > I carefully chose "fallback" and not "redirect" because a real > redirect is impossible here since no URL will really be right or the > main wiki. The idea would be to do exactly the same thing we do with > IP, www.*,. > >> >> An existing jira issue that is very related to this topic is >> http://jira.xwiki.org/browse/XWIKI-479 We could reuse that. > > Yes we can reuse it but not follow the proposal in the comments. > >> >> Thanks, >> Eduard >> >>> >>> > -- or have it generated programmatically at startup if it does not exist >>> > (might be safer this way, since people might be using a different UI than >>> > xwiki-enterprise-ui) >>> > >>> > I will start working on this locally and see if I can spot other issues, >>> > but please share your thoughts. >>> > >>> > Thanks, >>> > Eduard >>> > >>> > ---------- >>> > [1] http://markmail.org/message/o6adfbscpidnn7zr >>> > [2] http://jira.xwiki.org/browse/XWIKI-8822 >>> > _______________________________________________ >>> > 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 >>> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
Hi Denis, On Sun, Mar 3, 2013 at 1:42 AM, Denis Gervalle <[email protected]> wrote:
Hi Edouard,
On Fri, Mar 1, 2013 at 6:28 PM, Eduard Moraru <[email protected]> wrote:
Hi Denis,
Nice feedback! Please see below...
On Wed, Feb 27, 2013 at 10:23 PM, Denis Gervalle <[email protected]> wrote:
Hi again Eduard,
Regarding point 5., this is where it may get complex to support properly existing configuration file. So, the first question would be to know if we accept to disrupt upgraded wiki that use an old configuration file ? If the answer is yes, than good release notes should allow explaining how to be careful and adapt existing configuration to avoid unreachable wiki.
Personally, causing such disruption has not my preference, since upgrading has not done so until now, AFAIK. Moreover, IMO being able to put by configuration the main wiki unreachable could only cause a negative feeling to newcomers. Option like autowww is probably useless complexity for the benefit. And the worse is the unknown wiki page that is never reach since it come from the main wiki to say it is itself unreachable (XWIKI-479).
What you propose is not so easy, since creating the descriptor implies knowing the hostname when usepath=0 which may happen in old config even if unused. So here is what I would suggest:
1) Follow Thomas proposal: ensure getVirtualWikisDatabaseNames() always return the main wiki, even when no descriptor is available, but not by creating such descriptor. This ensure main wiki availability anytime.
Already done in the feature branch. However, how do we handle point 5, as I have described it wrt. the wiki-manager plugin?
The getAllWikis() method basically returns the list of wiki document descriptors. While for XWiki.getVirtualWikisDatabaseNames() it was easy to add a new string to the list of results, how would we handle it for the wiki-manager plugin, where we have to add an unexistent document (with objects -- what values?) to the list of results?
Do we really need to handle it ? In no way you may create it automatically. If the wiki manager need it, it should handle this missing descriptor properly at UI level, proposing to create the descriptor and allowing the user to complete the required information.
Well, I think you`re right. We could just not handle it, but make sure that it is specified in the documentation that if the main wiki does not have a descriptor, it will not be included in the returned list. It is not clean/consistent but neither is it vital.
2) Stop using a redirect to reach the unknown wiki page. This is also annoying for a simple typo in an URL since you loose that URL from the address bar. I see no usual need for going to a page outside XWiki, so stop using that configuration and eventually provide a configuration for deciding the page name of the main wiki that will be rendered. Anyway, use a .vm like other error to render that (optional) page or a default. This way, you leave a workaround for anyone wishing to restore the old behavior (you may even suggest commented code for that in the .vm)
I like this idea of using a vm instead of a redirect.
3) Never proceed to unknown wiki page when there is only one wiki, considering any unknown as the main.
While I theoretically agree with this, in practice it might be a bit confusing for some users that explicitly wrote a subwiki (in domain based) or maybe they have a bookmark but they end up on the main wiki, where they could continue working without realizing that they are not on the wiki
they
have requested.
Considering this, I think I prefer to display an explicit error.
I do not understand your use case ?
What I have said is that if there is only a single main wiki, and no subwiki, never display the unknown wiki page, but reach the main wiki whatever the domain name is. If you don't, you do not fix several potential unreachable wiki issue that may arise by simple enabling virtual mode. I do not see the point of showing an error when there is only one available wiki.
I don`t like the fact that we are making an assumption... an you know what they say about when you "ass-u-me" :) A "confusing" example may be the following: 1. The XWiki instance has the main wiki and 1 subwiki 2. The subwiki is removed 3. A user accesses the inexistent subwiki with outdated bookmarks (or who enters directly the url): subwiki.domain.com/xwiki/bin/view/Documentation/SomeDocumentation 3.1 He wants to add a paragraph at the end of the document and he is in a hurry 4. The space/page combination also exists on the main wiki, but it is diferent from what existed in the old subwiki. 5. The user edits the page and saves 6. The document is now inconsistent because the user did not pay attention to the URL and there was no visual indication (skin, panels, etc.) that he is on the wrong wiki Remember that if *right now* there is only 1 wiki, it does not mean that there never were other wikis in the past. An explicit error would have made the user alert and aware of what is going on.
4) Deprecate the autowww option, which is now useless
I have just came across this feature, so I`m not really familiar with the details and implications. As far as I understand it, by default, we allow the main wiki to be accessed trough the "www" subdomain (if tomcat is properly configured as well, I assume), "localhost" or ip address without having a descriptor. For all other cases, we proceed to get the
descriptor
and, if none is found, we redirect to whatever "xwiki.virtual.redirect" says.
Which part of this (except point 3 which we cleared above) are you suggesting to deprecate? The default behaviour or the option to disable this default behaviour? Please detail this a bit.
This exactly what it does, ensure accessibility to the main wiki through the IP, www subdomain and localhost, whatever the descriptor of the main wiki is. By default that feature is enable, so the option allow disabling. As you said yourself, you do not really understand that feature. This is why I am proposing to phase it out (no real change in code for now, simply stating this is deprecated). After a second thought, there may be one case where you need it, when you want to have a subwiki on www. Why not simply checking that no descriptor works for www before going to the main in that special case. For the IP and localhost, I do not see any reason to disable them.
Sounds good. Deprecate autowww and, additionally check if a subwiki named "www" exists.
5) Optional, but would be a nice to have for global admin, allow fixing the
main wiki descriptor from the unknown wiki page.
What do you mean by "fixing the main wiki descriptor from the unknown
wiki
page"? Please details this a bit as well.
Well, if the user is a global admin, provide through the unknown wiki error page a suggestion to access the main wiki or a way to fix up the main wiki descriptor to reestablish its access easily. I dislike the idea of having a dead end. But it is the icing on the cake.
I see now what you mean. Sounds good. Thanks, Eduard
Thanks,
Thanks, Eduard
With those changes, you will fix most issue regarding the reachability
of
wikis in virtual mode, and therefore, having virtual as the default should not be an issue anymore, whatever your configuration is.
WDYT ?
On Wed, Feb 27, 2013 at 10:21 AM, Eduard Moraru <[email protected]
wrote:
Hi devs,
To further fuel this discussion, I will mention some points that are more or less problematic when removing the notion of virtual mode (checks for xwiki.isVirtualMode()), since a direct change would leave a some pieces of code dead (never called) or just need a bit of discussion on them:
1. c.x.x.s.XWikiHibernateBaseStore.initHibernate(XWikiContext context) [1]
That piece of code seems to only run when the wiki is not in virtual mode. From what I managed to understand from Thomas [2], it's probably this case: "in your hibernate configuration if you set a database which is not called 'xwiki'. In virtual mode this configuration is not taken into account and you have to indicate the name of the database in xwiki.cfg". I think we need to review this behavior. IMO, we should do take this configuration into account in virtual mode as well, as long as there is no other technical impediment. It is a configuration for the main wiki after all, and it should still be valid.
2. c.x.x.XWiki.onPluginPreferenceEvent(Event event, XWikiDocument doc, XWikiContext context) [3]
This piece of code seems to reload the plugins if the "plugins" property changed in XWikiPreferences, but only if the wiki is not in virtual mode. I think we need to change this to happen for any wiki and the plugins need to be reloaded only for that specific wiki for which the change happened (if it is possible).
3. extension.vm - extensionActionButton macro [4]
This UI code decides when to displays the (Un)Install button of an extension for the current wiki or for the entire farm. Removing the virtual mode check will always show the (un)install on farm button. I think Marius had some concerns about his one.
4. distribution.vm - displayMainUiStep_unknownPreviousUI [5]
This code assumes that if virtualMode is true, then the product is XEM, otherwise it's XE. This is used to propose old version names for the 2 products. Obviously this is needs to be refactored and use a different way of determining which is which.
5. c.x.x.p.w.WikiManager public List<Wiki> getAllWikis(XWikiContext context) throws XWikiException [6]
We have decided that c.x.x.XWiki.getVirtualWikisDatabaseNames will also return the main wiki's name. However, the WikiManager plugin can not do this so easily because the main wiki's descriptor may not exist. How could we handle this, in order to be consistent? Would creating programmatically the main wiki's descriptor with default values on ApplicationReady event do any good? Will it do any harm?
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[2]
https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8...
[3]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[4]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[5]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[6]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
On Fri, Feb 22, 2013 at 3:48 PM, Eduard Moraru <[email protected]
wrote:
Hi devs,
To be more precise, the essence of my proposed change [1] is to actually always return "true" in the isVirtualMode() method, ignoring any configuration and marking the method as @deprecated, to be removed in future versions.
Is there any reason not to do this? (Why) Would we want to preserve the possibility of going back to a non-virtual mode? (mostly addressed to Thomas, but to others as well)
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8...
On Fri, Feb 22, 2013 at 3:39 PM, Eduard Moraru <
wrote:
Hi devs,
As some of you have already noticed and already started providing feedback (thank you), I have pushed a feature branch [1] that proposes the removal of the virtual mode concept (making it enabled and fixed by default).
I have also gone trough the code in xwiki-platform and removed, in the feature branch, dead code (code branches that will never be reached because of this change). Some tests were also adapted to the new change. I have also tried a build of xwiki-platform with these changes and it built successfully.
First of all, I want to make sure that we agree on the change, since Thomas already mentioned that he does not agree (but I need more details).
Second, if we agree, please take the time to look over the changes (particularly in the modules that you each have experience in) and double check that the logic of the code was not altered in any way.
I will not be merging this branch until I get a general green light from the committers, and until everybody is happy :)
Please share your opinion both on this mail and/or on the specific changes in the github commits.
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/commits/feature-deprecate-virtual-mo...
On Mon, Feb 18, 2013 at 4:53 PM, Thomas Mortagne < [email protected]> wrote:
> On Mon, Feb 18, 2013 at 3:48 PM, Thomas Mortagne > <[email protected]> wrote: > > On Mon, Feb 18, 2013 at 3:38 PM, Eduard Moraru <
> wrote: > >> Hi Thomas, > >> > >> On Mon, Feb 18, 2013 at 3:45 PM, Thomas Mortagne > >> <[email protected]>wrote: > >> > >>> On Mon, Feb 18, 2013 at 2:07 PM, Eduard Moraru < [email protected] > > > >>> wrote: > >>> > Hi devs, > >>> > > >>> > According to the Roadmap of 5.0 [1][2] we will be deprecating the > virtual > >>> > mode API and moving to a virtual-by-default mode instead. > >>> > > >>> > The idea is that the multiwiki environment should be the default > and, > >>> > anyone wanting to use the single-wiki mode (as XE was doing in the > past), > >>> > will simply not create any subwiki. It is just pointless to have 2 > >>> products > >>> > for such a simple fact and it also confuses users that have > downloaded > >>> and > >>> > started to use one product and later on realise that they needed > the > >>> other. > >>> > Also, when installing the wiki-manager and/or workspace > extension(s) > >>> > (because you might want to create subwikis/workspaces), there will > be no > >>> > need to stop the wiki, enable-virtual mode and restart it; all > will be > >>> > doable in the browser. > >>> > > >>> > Therefore, I`m sending this mail to ask your opinion about this > topic, in > >>> > case you might have something to say against it, and also to > brainstorm > >>> on > >>> > the required changes and implications on existing code so that the > >>> > transition is as smooth and invisible as possible. > >>> > > >>> > Proposed changes: > >>> > - Remove "xwiki.virtual" from xwiki.cfg(.vm) > >>> > -- remove the usage of the "$xwikiCfgVirtual" maven property from > >>> > xwiki-platform (, xwiki-enteprise and xwiki-manager) > >>> > - Deprecate boolean com.xpn.xwiki.XWiki.isVirtualMode() (and the > >>> api.XWiki > >>> > version) > >>> > -- change its code to > ((getVirtualWikisDatabaseNames(context).size() == > >>> 1) > >>> > ? true : false) until it is removed by the deprecation process. > >>> > >>> -1. It means that you are going to be in non virtual mode when > >>> starting XEM which is very wrong and the complete opposite of what we > >>> want here. We should deprecate and don't touch it's implementation in > >>> any way other that returning true by default instead of false when > >>> there is nothing in the configuration. Again as you said the goal is > >>> to be in virtual mode by default, period. If the UI want to do > >>> something different when there is only one wiki the UI should test if > >>> there is only one wiki but breaking all extensions counting on the > >>> virtual mode is very bad API breakage. > >>> > >> > >> I agree. The isVirtualMode check was supposed to tell you if "there > can be > >> more than one wiki", while I was suggesting to transform it to "are > there > >> currently more than one wikis?", which is obviously not equivalent. > >> > >> > >>> > > >>> > Possibly needed changes: > >>> > - Add main wiki default descriptor to xwiki-enterprise-ui (so that > >>> > getVirtualWikisDatabaseNames includes the main wiki and also to > avoid DNS > >>> > issues (?) caused by how we handle virtual mode) > >>> > >>> This is useless IMO: > >>> * the fact that getVirtualWikisDatabaseNames does not return the main > >>> wiki when there is no descriptor for it is a bug that should be fixed > >>> > >> > >> Ok. I have created the jira issue for it: > >> http://jira.xwiki.org/browse/XWIKI-8829 > >> > >> Also, on the same topic, I think that we should also expose the > >> getVirtualWikisDatabaseNames method in api.XWiki. Maybe we should > rename it > >> to something simpler like api.XWiki.getAllWikis() or > getAllWikiNames(). > > > > Yes, "getVirtualWikisDatabaseNames" is not very nice. > > This name is also pretty wrong btw since that's wiki names and not > database names which could be very different. > > > > >> > >> > >>> * I don't see how having a descriptor with localhost in it will help > >>> in any way not having DNS issue, it's not helping much in XEM it's > not > >>> going to be better in XE. IMO the right solution is to fallback on > >>> main wiki by default when the wiki is unknown instead of sending a > >>> redirect to some URL which cannot work and only allow to enable this > >>> redirect URL as an option > >>> > >> > >> Ok, so we comment out xwiki.virtual.redirect in xwiki.cfg and, by > default, > >> redirect to the main wiki's Main.WebHome. > > > > I carefully chose "fallback" and not "redirect" because a real > > redirect is impossible here since no URL will really be right or the > > main wiki. The idea would be to do exactly the same thing we do with > > IP, www.*,. > > > >> > >> An existing jira issue that is very related to this topic is > >> http://jira.xwiki.org/browse/XWIKI-479 We could reuse that. > > > > Yes we can reuse it but not follow the proposal in the comments. > > > >> > >> Thanks, > >> Eduard > >> > >>> > >>> > -- or have it generated programmatically at startup if it does not > exist > >>> > (might be safer this way, since people might be using a different > UI than > >>> > xwiki-enterprise-ui) > >>> > > >>> > I will start working on this locally and see if I can spot other > issues, > >>> > but please share your thoughts. > >>> > > >>> > Thanks, > >>> > Eduard > >>> > > >>> > ---------- > >>> > [1] http://markmail.org/message/o6adfbscpidnn7zr > >>> > [2] http://jira.xwiki.org/browse/XWIKI-8822 > >>> > _______________________________________________ > >>> > 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 > >>> > >> _______________________________________________ > >> devs mailing list > >> [email protected] > >> http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > -- > > Thomas Mortagne > > > > -- > Thomas Mortagne > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs >
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Eduard, On Mon, Mar 4, 2013 at 4:41 PM, Eduard Moraru <[email protected]> wrote:
Hi Denis,
On Sun, Mar 3, 2013 at 1:42 AM, Denis Gervalle <[email protected]> wrote:
Hi Edouard,
On Fri, Mar 1, 2013 at 6:28 PM, Eduard Moraru <[email protected]> wrote:
Hi Denis,
Nice feedback! Please see below...
On Wed, Feb 27, 2013 at 10:23 PM, Denis Gervalle <[email protected]> wrote:
Hi again Eduard,
Regarding point 5., this is where it may get complex to support properly existing configuration file. So, the first question would be to know if we accept to disrupt upgraded wiki that use an old configuration file ? If the answer is yes, than good release notes should allow explaining how to be careful and adapt existing configuration to avoid unreachable wiki.
Personally, causing such disruption has not my preference, since upgrading has not done so until now, AFAIK. Moreover, IMO being able to put by configuration the main wiki unreachable could only cause a negative feeling to newcomers. Option like autowww is probably useless complexity for the benefit. And the worse is the unknown wiki page that is never reach since it come from the main wiki to say it is itself unreachable (XWIKI-479).
What you propose is not so easy, since creating the descriptor implies knowing the hostname when usepath=0 which may happen in old config even if unused. So here is what I would suggest:
1) Follow Thomas proposal: ensure getVirtualWikisDatabaseNames() always return the main wiki, even when no descriptor is available, but not by creating such descriptor. This ensure main wiki availability anytime.
Already done in the feature branch. However, how do we handle point 5, as I have described it wrt. the wiki-manager plugin?
The getAllWikis() method basically returns the list of wiki document descriptors. While for XWiki.getVirtualWikisDatabaseNames() it was easy to add a new string to the list of results, how would we handle it for the wiki-manager plugin, where we have to add an unexistent document (with objects -- what values?) to the list of results?
Do we really need to handle it ? In no way you may create it automatically. If the wiki manager need it, it should handle this missing descriptor properly at UI level, proposing to create the descriptor and allowing the user to complete the required information.
Well, I think you`re right. We could just not handle it, but make sure that it is specified in the documentation that if the main wiki does not have a descriptor, it will not be included in the returned list. It is not clean/consistent but neither is it vital.
If we have 5) and it seems we need it (see below), the wiki manager could propose it as well.
2) Stop using a redirect to reach the unknown wiki page. This is also annoying for a simple typo in an URL since you loose that URL from the address bar. I see no usual need for going to a page outside XWiki, so stop using that configuration and eventually provide a configuration for deciding the page name of the main wiki that will be rendered. Anyway, use a .vm like other error to render that (optional) page or a default.
This
way, you leave a workaround for anyone wishing to restore the old behavior (you may even suggest commented code for that in the .vm)
I like this idea of using a vm instead of a redirect.
3) Never proceed to unknown wiki page when there is only one wiki, considering any unknown as the main.
While I theoretically agree with this, in practice it might be a bit confusing for some users that explicitly wrote a subwiki (in domain based) or maybe they have a bookmark but they end up on the main wiki, where they could continue working without realizing that they are not on the wiki they have requested.
Considering this, I think I prefer to display an explicit error.
I do not understand your use case ?
What I have said is that if there is only a single main wiki, and no subwiki, never display the unknown wiki page, but reach the main wiki whatever the domain name is. If you don't, you do not fix several potential unreachable wiki issue that may arise by simple enabling virtual mode. I do not see the point of showing an error when there is only one available wiki.
I don`t like the fact that we are making an assumption... an you know what they say about when you "ass-u-me" :)
A "confusing" example may be the following: 1. The XWiki instance has the main wiki and 1 subwiki 2. The subwiki is removed 3. A user accesses the inexistent subwiki with outdated bookmarks (or who enters directly the url): subwiki.domain.com/xwiki/bin/view/Documentation/SomeDocumentation 3.1 He wants to add a paragraph at the end of the document and he is in a hurry 4. The space/page combination also exists on the main wiki, but it is diferent from what existed in the old subwiki. 5. The user edits the page and saves 6. The document is now inconsistent because the user did not pay attention to the URL and there was no visual indication (skin, panels, etc.) that he is on the wrong wiki
Remember that if *right now* there is only 1 wiki, it does not mean that there never were other wikis in the past.
An explicit error would have made the user alert and aware of what is going on.
I understand your point, however this is a crucial point for moving to virtual per default. Worse than your example is the one where a single wiki user upgrading does not reach its (main) wiki anymore. Seems having 5) is no more the icing on the cake but a required solution to avoid this really bad situation.
4) Deprecate the autowww option, which is now useless
I have just came across this feature, so I`m not really familiar with
the
details and implications. As far as I understand it, by default, we allow the main wiki to be accessed trough the "www" subdomain (if tomcat is properly configured as well, I assume), "localhost" or ip address without having a descriptor. For all other cases, we proceed to get the descriptor and, if none is found, we redirect to whatever "xwiki.virtual.redirect" says.
Which part of this (except point 3 which we cleared above) are you suggesting to deprecate? The default behaviour or the option to disable this default behaviour? Please detail this a bit.
This exactly what it does, ensure accessibility to the main wiki through the IP, www subdomain and localhost, whatever the descriptor of the main wiki is. By default that feature is enable, so the option allow disabling. As you said yourself, you do not really understand that feature. This is why I am proposing to phase it out (no real change in code for now, simply stating this is deprecated). After a second thought, there may be one case where you need it, when you want to have a subwiki on www. Why not simply checking that no descriptor works for www before going to the main in that special case. For the IP and localhost, I do not see any reason to disable them.
Sounds good. Deprecate autowww and, additionally check if a subwiki named "www" exists.
5) Optional, but would be a nice to have for global admin, allow
fixing
the
main wiki descriptor from the unknown wiki page.
What do you mean by "fixing the main wiki descriptor from the unknown wiki page"? Please details this a bit as well.
Well, if the user is a global admin, provide through the unknown wiki error page a suggestion to access the main wiki or a way to fix up the main wiki descriptor to reestablish its access easily. I dislike the idea of having a dead end. But it is the icing on the cake.
I see now what you mean. Sounds good.
Thanks, Eduard
Thanks,
Thanks, Eduard
With those changes, you will fix most issue regarding the
reachability
of
wikis in virtual mode, and therefore, having virtual as the default should not be an issue anymore, whatever your configuration is.
WDYT ?
On Wed, Feb 27, 2013 at 10:21 AM, Eduard Moraru < [email protected]
wrote:
Hi devs,
To further fuel this discussion, I will mention some points that are more or less problematic when removing the notion of virtual mode (checks for xwiki.isVirtualMode()), since a direct change would leave a some pieces of code dead (never called) or just need a bit of discussion on them:
1. c.x.x.s.XWikiHibernateBaseStore.initHibernate(XWikiContext context) [1]
That piece of code seems to only run when the wiki is not in virtual mode. From what I managed to understand from Thomas [2], it's probably this case: "in your hibernate configuration if you set a database which is not called 'xwiki'. In virtual mode this configuration is not taken into account and you have to indicate the name of the database in xwiki.cfg". I think we need to review this behavior. IMO, we should do take this configuration into account in virtual mode as well, as long as there is no other technical impediment. It is a configuration for the main wiki after all, and it should still be valid.
2. c.x.x.XWiki.onPluginPreferenceEvent(Event event, XWikiDocument doc, XWikiContext context) [3]
This piece of code seems to reload the plugins if the "plugins" property changed in XWikiPreferences, but only if the wiki is not in virtual mode. I think we need to change this to happen for any wiki and the plugins need to be reloaded only for that specific wiki for which the change happened (if it is possible).
3. extension.vm - extensionActionButton macro [4]
This UI code decides when to displays the (Un)Install button of an extension for the current wiki or for the entire farm. Removing the virtual mode check will always show the (un)install on farm button. I think Marius had some concerns about his one.
4. distribution.vm - displayMainUiStep_unknownPreviousUI [5]
This code assumes that if virtualMode is true, then the product is XEM, otherwise it's XE. This is used to propose old version names for the 2 products. Obviously this is needs to be refactored and use a different way of determining which is which.
5. c.x.x.p.w.WikiManager public List<Wiki> getAllWikis(XWikiContext context) throws XWikiException [6]
We have decided that c.x.x.XWiki.getVirtualWikisDatabaseNames will also return the main wiki's name. However, the WikiManager plugin can not do this so easily because the main wiki's descriptor may not exist. How could we handle this, in order to be consistent? Would creating programmatically the main wiki's descriptor with default values on ApplicationReady event do any good? Will it do any harm?
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[2]
https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8...
[3]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[4]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[5]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[6]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
On Fri, Feb 22, 2013 at 3:48 PM, Eduard Moraru <
wrote:
Hi devs,
To be more precise, the essence of my proposed change [1] is to actually always return "true" in the isVirtualMode() method, ignoring any configuration and marking the method as @deprecated, to be removed in future versions.
Is there any reason not to do this? (Why) Would we want to preserve the possibility of going back to a non-virtual mode? (mostly addressed to Thomas, but to others as well)
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8...
On Fri, Feb 22, 2013 at 3:39 PM, Eduard Moraru <
wrote:
> Hi devs, > > As some of you have already noticed and already started providing > feedback (thank you), I have pushed a feature branch [1] that proposes the > removal of the virtual mode concept (making it enabled and fixed by > default). > > I have also gone trough the code in xwiki-platform and removed, in the > feature branch, dead code (code branches that will never be reached because > of this change). Some tests were also adapted to the new change. I have > also tried a build of xwiki-platform with these changes and it built > successfully. > > First of all, I want to make sure that we agree on the change, since > Thomas already mentioned that he does not agree (but I need more details). > > Second, if we agree, please take the time to look over the changes > (particularly in the modules that you each have experience in) and double > check that the logic of the code was not altered in any way. > > I will not be merging this branch until I get a general green light from > the committers, and until everybody is happy :) > > Please share your opinion both on this mail and/or on the specific > changes in the github commits. > > Thanks, > Eduard > > ---------- > [1] >
https://github.com/xwiki/xwiki-platform/commits/feature-deprecate-virtual-mo...
> > > > On Mon, Feb 18, 2013 at 4:53 PM, Thomas Mortagne < > [email protected]> wrote: > >> On Mon, Feb 18, 2013 at 3:48 PM, Thomas Mortagne >> <[email protected]> wrote: >> > On Mon, Feb 18, 2013 at 3:38 PM, Eduard Moraru < [email protected]
>> wrote: >> >> Hi Thomas, >> >> >> >> On Mon, Feb 18, 2013 at 3:45 PM, Thomas Mortagne >> >> <[email protected]>wrote: >> >> >> >>> On Mon, Feb 18, 2013 at 2:07 PM, Eduard Moraru < [email protected] >> > >> >>> wrote: >> >>> > Hi devs, >> >>> > >> >>> > According to the Roadmap of 5.0 [1][2] we will be deprecating the >> virtual >> >>> > mode API and moving to a virtual-by-default mode instead. >> >>> > >> >>> > The idea is that the multiwiki environment should be the default >> and, >> >>> > anyone wanting to use the single-wiki mode (as XE was doing in the >> past), >> >>> > will simply not create any subwiki. It is just pointless to have 2 >> >>> products >> >>> > for such a simple fact and it also confuses users that have >> downloaded >> >>> and >> >>> > started to use one product and later on realise that they needed >> the >> >>> other. >> >>> > Also, when installing the wiki-manager and/or workspace >> extension(s) >> >>> > (because you might want to create subwikis/workspaces), there will >> be no >> >>> > need to stop the wiki, enable-virtual mode and restart it; all >> will be >> >>> > doable in the browser. >> >>> > >> >>> > Therefore, I`m sending this mail to ask your opinion about this >> topic, in >> >>> > case you might have something to say against it, and also to >> brainstorm >> >>> on >> >>> > the required changes and implications on existing code so that the >> >>> > transition is as smooth and invisible as possible. >> >>> > >> >>> > Proposed changes: >> >>> > - Remove "xwiki.virtual" from xwiki.cfg(.vm) >> >>> > -- remove the usage of the "$xwikiCfgVirtual" maven property from >> >>> > xwiki-platform (, xwiki-enteprise and xwiki-manager) >> >>> > - Deprecate boolean com.xpn.xwiki.XWiki.isVirtualMode() (and the >> >>> api.XWiki >> >>> > version) >> >>> > -- change its code to >> ((getVirtualWikisDatabaseNames(context).size() == >> >>> 1) >> >>> > ? true : false) until it is removed by the deprecation process. >> >>> >> >>> -1. It means that you are going to be in non virtual mode when >> >>> starting XEM which is very wrong and the complete opposite of what we >> >>> want here. We should deprecate and don't touch it's implementation in >> >>> any way other that returning true by default instead of false when >> >>> there is nothing in the configuration. Again as you said the goal is >> >>> to be in virtual mode by default, period. If the UI want to do >> >>> something different when there is only one wiki the UI should test if >> >>> there is only one wiki but breaking all extensions counting on the >> >>> virtual mode is very bad API breakage. >> >>> >> >> >> >> I agree. The isVirtualMode check was supposed to tell you if "there >> can be >> >> more than one wiki", while I was suggesting to transform it to "are >> there >> >> currently more than one wikis?", which is obviously not equivalent. >> >> >> >> >> >>> > >> >>> > Possibly needed changes: >> >>> > - Add main wiki default descriptor to xwiki-enterprise-ui (so that >> >>> > getVirtualWikisDatabaseNames includes the main wiki and also to >> avoid DNS >> >>> > issues (?) caused by how we handle virtual mode) >> >>> >> >>> This is useless IMO: >> >>> * the fact that getVirtualWikisDatabaseNames does not return the main >> >>> wiki when there is no descriptor for it is a bug that should be fixed >> >>> >> >> >> >> Ok. I have created the jira issue for it: >> >> http://jira.xwiki.org/browse/XWIKI-8829 >> >> >> >> Also, on the same topic, I think that we should also expose the >> >> getVirtualWikisDatabaseNames method in api.XWiki. Maybe we should >> rename it >> >> to something simpler like api.XWiki.getAllWikis() or >> getAllWikiNames(). >> > >> > Yes, "getVirtualWikisDatabaseNames" is not very nice. >> >> This name is also pretty wrong btw since that's wiki names and not >> database names which could be very different. >> >> > >> >> >> >> >> >>> * I don't see how having a descriptor with localhost in it will help >> >>> in any way not having DNS issue, it's not helping much in XEM it's >> not >> >>> going to be better in XE. IMO the right solution is to fallback on >> >>> main wiki by default when the wiki is unknown instead of sending a >> >>> redirect to some URL which cannot work and only allow to enable this >> >>> redirect URL as an option >> >>> >> >> >> >> Ok, so we comment out xwiki.virtual.redirect in xwiki.cfg and, by >> default, >> >> redirect to the main wiki's Main.WebHome. >> > >> > I carefully chose "fallback" and not "redirect" because a real >> > redirect is impossible here since no URL will really be right or the >> > main wiki. The idea would be to do exactly the same thing we do with >> > IP, www.*,. >> > >> >> >> >> An existing jira issue that is very related to this topic is >> >> http://jira.xwiki.org/browse/XWIKI-479 We could reuse that. >> > >> > Yes we can reuse it but not follow the proposal in the comments. >> > >> >> >> >> Thanks, >> >> Eduard >> >> >> >>> >> >>> > -- or have it generated programmatically at startup if it does not >> exist >> >>> > (might be safer this way, since people might be using a different >> UI than >> >>> > xwiki-enterprise-ui) >> >>> > >> >>> > I will start working on this locally and see if I can spot other >> issues, >> >>> > but please share your thoughts. >> >>> > >> >>> > Thanks, >> >>> > Eduard >> >>> > >> >>> > ---------- >> >>> > [1] http://markmail.org/message/o6adfbscpidnn7zr >> >>> > [2] http://jira.xwiki.org/browse/XWIKI-8822 >> >>> > _______________________________________________ >> >>> > 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 >> >>> >> >> _______________________________________________ >> >> devs mailing list >> >> [email protected] >> >> http://lists.xwiki.org/mailman/listinfo/devs >> > >> > >> > >> > -- >> > Thomas Mortagne >> >> >> >> -- >> Thomas Mortagne >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > >
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
Hi, On Mon, Mar 4, 2013 at 8:34 PM, Denis Gervalle <[email protected]> wrote:
Hi Eduard,
On Mon, Mar 4, 2013 at 4:41 PM, Eduard Moraru <[email protected]> wrote:
Hi Denis,
On Sun, Mar 3, 2013 at 1:42 AM, Denis Gervalle <[email protected]> wrote:
Hi Edouard,
On Fri, Mar 1, 2013 at 6:28 PM, Eduard Moraru <[email protected]> wrote:
Hi Denis,
Nice feedback! Please see below...
On Wed, Feb 27, 2013 at 10:23 PM, Denis Gervalle <[email protected]> wrote:
Hi again Eduard,
Regarding point 5., this is where it may get complex to support properly existing configuration file. So, the first question would be to know if we accept to disrupt upgraded wiki that use an old configuration file ? If the answer is yes, than good release notes should allow explaining how to be careful and adapt existing configuration to avoid unreachable wiki.
Personally, causing such disruption has not my preference, since upgrading has not done so until now, AFAIK. Moreover, IMO being able to put by configuration the main wiki unreachable could only cause a negative feeling to newcomers. Option like autowww is probably useless complexity for the benefit. And the worse is the unknown wiki page that is never reach since it come from the main wiki to say it is itself unreachable (XWIKI-479).
What you propose is not so easy, since creating the descriptor implies knowing the hostname when usepath=0 which may happen in old config even if unused. So here is what I would suggest:
1) Follow Thomas proposal: ensure getVirtualWikisDatabaseNames() always return the main wiki, even when no descriptor is available, but not by creating such descriptor. This ensure main wiki availability anytime.
Already done in the feature branch. However, how do we handle point 5, as I have described it wrt. the wiki-manager plugin?
The getAllWikis() method basically returns the list of wiki document descriptors. While for XWiki.getVirtualWikisDatabaseNames() it was easy to add a new string to the list of results, how would we handle it for the wiki-manager plugin, where we have to add an unexistent document (with objects -- what values?) to the list of results?
Do we really need to handle it ? In no way you may create it automatically. If the wiki manager need it, it should handle this missing descriptor properly at UI level, proposing to create the descriptor and allowing the user to complete the required information.
Well, I think you`re right. We could just not handle it, but make sure that it is specified in the documentation that if the main wiki does not have a descriptor, it will not be included in the returned list. It is not clean/consistent but neither is it vital.
If we have 5) and it seems we need it (see below), the wiki manager could propose it as well.
I think that, when reffering to 5), we think of different things :). For me, 5) is about handling the fact that wikiManager should return a descriptor for the main wiki when there is none. AFAIU, we agreed that it should just state in the documentation that the main wiki descriptor can be missing from the list if it does not exist. For you, AFAIU, it's about XWIKI-479, autowww and (more generally) accessing the wiki. Hope I got it right :) Even if they are related in concept ("what do we do about the main wiki's descriptor?"), let's try to keep them separate for now.
2) Stop using a redirect to reach the unknown wiki page. This is also annoying for a simple typo in an URL since you loose that URL from
the
address bar. I see no usual need for going to a page outside XWiki, so stop using that configuration and eventually provide a configuration for deciding the page name of the main wiki that will be rendered. Anyway, use a .vm like other error to render that (optional) page or a default. This way, you leave a workaround for anyone wishing to restore the old behavior (you may even suggest commented code for that in the .vm)
I like this idea of using a vm instead of a redirect.
3) Never proceed to unknown wiki page when there is only one wiki, considering any unknown as the main.
While I theoretically agree with this, in practice it might be a bit confusing for some users that explicitly wrote a subwiki (in domain based) or maybe they have a bookmark but they end up on the main wiki, where they could continue working without realizing that they are not on the wiki they have requested.
Considering this, I think I prefer to display an explicit error.
I do not understand your use case ?
What I have said is that if there is only a single main wiki, and no subwiki, never display the unknown wiki page, but reach the main wiki whatever the domain name is. If you don't, you do not fix several potential unreachable wiki issue that may arise by simple enabling virtual mode. I do not see the point of showing an error when there is only one available wiki.
I don`t like the fact that we are making an assumption... an you know what they say about when you "ass-u-me" :)
A "confusing" example may be the following: 1. The XWiki instance has the main wiki and 1 subwiki 2. The subwiki is removed 3. A user accesses the inexistent subwiki with outdated bookmarks (or who enters directly the url): subwiki.domain.com/xwiki/bin/view/Documentation/SomeDocumentation 3.1 He wants to add a paragraph at the end of the document and he is in a hurry 4. The space/page combination also exists on the main wiki, but it is diferent from what existed in the old subwiki. 5. The user edits the page and saves 6. The document is now inconsistent because the user did not pay attention to the URL and there was no visual indication (skin, panels, etc.) that he is on the wrong wiki
Remember that if *right now* there is only 1 wiki, it does not mean that there never were other wikis in the past.
An explicit error would have made the user alert and aware of what is going on.
I understand your point, however this is a crucial point for moving to virtual per default. Worse than your example is the one where a single wiki user upgrading does not reach its (main) wiki anymore. Seems having 5) is no more the icing on the cake but a required solution to avoid this really bad situation.
As far as I can see in the code [1], when talking about wiki access, autowww allows an upgrading user to access his wiki using the ip address or, AFAIU, using www.domain.com (which was what he would have been using already in 90% of time). Coupled with the warnings/notices in the upgrading instructions, this sounds acceptable. Did I get it wrong? Thanks, Eduard ---------- [1] https://github.com/xwiki/xwiki-platform/blob/0c75e74502357d791876a991558a685...
4) Deprecate the autowww option, which is now useless
I have just came across this feature, so I`m not really familiar with
the
details and implications. As far as I understand it, by default, we allow the main wiki to be accessed trough the "www" subdomain (if tomcat is properly configured as well, I assume), "localhost" or ip address without having a descriptor. For all other cases, we proceed to get the descriptor and, if none is found, we redirect to whatever
"xwiki.virtual.redirect"
says.
Which part of this (except point 3 which we cleared above) are you suggesting to deprecate? The default behaviour or the option to disable this default behaviour? Please detail this a bit.
This exactly what it does, ensure accessibility to the main wiki through the IP, www subdomain and localhost, whatever the descriptor of the main wiki is. By default that feature is enable, so the option allow disabling. As you said yourself, you do not really understand that feature. This is why I am proposing to phase it out (no real change in code for now, simply stating this is deprecated). After a second thought, there may be one case where you need it, when you want to have a subwiki on www. Why not simply checking that no descriptor works for www before going to the main in that special case. For the IP and localhost, I do not see any reason to disable them.
Sounds good. Deprecate autowww and, additionally check if a subwiki named "www" exists.
5) Optional, but would be a nice to have for global admin, allow
fixing
the
main wiki descriptor from the unknown wiki page.
What do you mean by "fixing the main wiki descriptor from the unknown wiki page"? Please details this a bit as well.
Well, if the user is a global admin, provide through the unknown wiki error page a suggestion to access the main wiki or a way to fix up the main wiki descriptor to reestablish its access easily. I dislike the idea of having a dead end. But it is the icing on the cake.
I see now what you mean. Sounds good.
Thanks, Eduard
Thanks,
Thanks, Eduard
With those changes, you will fix most issue regarding the
reachability
of
wikis in virtual mode, and therefore, having virtual as the default should not be an issue anymore, whatever your configuration is.
WDYT ?
On Wed, Feb 27, 2013 at 10:21 AM, Eduard Moraru < [email protected]
wrote:
Hi devs,
To further fuel this discussion, I will mention some points that are more or less problematic when removing the notion of virtual mode (checks for xwiki.isVirtualMode()), since a direct change would leave a some pieces of code dead (never called) or just need a bit of discussion on them:
1. c.x.x.s.XWikiHibernateBaseStore.initHibernate(XWikiContext context) [1]
That piece of code seems to only run when the wiki is not in virtual mode. From what I managed to understand from Thomas [2], it's probably this case: "in your hibernate configuration if you set a database which is not called 'xwiki'. In virtual mode this configuration is not taken into account and you have to indicate the name of the database in xwiki.cfg". I think we need to review this behavior. IMO, we should do take this configuration into account in virtual mode as well, as long as there is no other technical impediment. It is a configuration for the main wiki after all, and it should still be valid.
2. c.x.x.XWiki.onPluginPreferenceEvent(Event event, XWikiDocument doc, XWikiContext context) [3]
This piece of code seems to reload the plugins if the "plugins" property changed in XWikiPreferences, but only if the wiki is not in virtual mode. I think we need to change this to happen for any wiki and the plugins need to be reloaded only for that specific wiki for which the change happened (if it is possible).
3. extension.vm - extensionActionButton macro [4]
This UI code decides when to displays the (Un)Install button of an extension for the current wiki or for the entire farm. Removing the virtual mode check will always show the (un)install on farm button. I think Marius had some concerns about his one.
4. distribution.vm - displayMainUiStep_unknownPreviousUI [5]
This code assumes that if virtualMode is true, then the product is XEM, otherwise it's XE. This is used to propose old version names for the 2 products. Obviously this is needs to be refactored and use a different way of determining which is which.
5. c.x.x.p.w.WikiManager public List<Wiki> getAllWikis(XWikiContext context) throws XWikiException [6]
We have decided that c.x.x.XWiki.getVirtualWikisDatabaseNames will also return the main wiki's name. However, the WikiManager plugin can not do this so easily because the main wiki's descriptor may not exist. How could we handle this, in order to be consistent? Would creating programmatically the main wiki's descriptor with default values on ApplicationReady event do any good? Will it do any harm?
Thanks, Eduard
---------- [1]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[2]
https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8...
[3]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[4]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[5]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
[6]
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
On Fri, Feb 22, 2013 at 3:48 PM, Eduard Moraru <
wrote:
> Hi devs, > > To be more precise, the essence of my proposed change [1] is to actually > always return "true" in the isVirtualMode() method, ignoring any > configuration and marking the method as @deprecated, to be removed in > future versions. > > Is there any reason not to do this? (Why) Would we want to preserve the > possibility of going back to a non-virtual mode? (mostly addressed to > Thomas, but to others as well) > > Thanks, > Eduard > > ---------- > [1] >
https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8...
> > > > > On Fri, Feb 22, 2013 at 3:39 PM, Eduard Moraru < [email protected] >wrote: > >> Hi devs, >> >> As some of you have already noticed and already started providing >> feedback (thank you), I have pushed a feature branch [1] that proposes the >> removal of the virtual mode concept (making it enabled and fixed by >> default). >> >> I have also gone trough the code in xwiki-platform and removed, in the >> feature branch, dead code (code branches that will never be reached because >> of this change). Some tests were also adapted to the new change. I have >> also tried a build of xwiki-platform with these changes and it built >> successfully. >> >> First of all, I want to make sure that we agree on the change, since >> Thomas already mentioned that he does not agree (but I need more details). >> >> Second, if we agree, please take the time to look over the changes >> (particularly in the modules that you each have experience in) and double >> check that the logic of the code was not altered in any way. >> >> I will not be merging this branch until I get a general green light from >> the committers, and until everybody is happy :) >> >> Please share your opinion both on this mail and/or on the specific >> changes in the github commits. >> >> Thanks, >> Eduard >> >> ---------- >> [1] >>
https://github.com/xwiki/xwiki-platform/commits/feature-deprecate-virtual-mo...
>> >> >> >> On Mon, Feb 18, 2013 at 4:53 PM, Thomas Mortagne < >> [email protected]> wrote: >> >>> On Mon, Feb 18, 2013 at 3:48 PM, Thomas Mortagne >>> <[email protected]> wrote: >>> > On Mon, Feb 18, 2013 at 3:38 PM, Eduard Moraru < [email protected] > >>> wrote: >>> >> Hi Thomas, >>> >> >>> >> On Mon, Feb 18, 2013 at 3:45 PM, Thomas Mortagne >>> >> <[email protected]>wrote: >>> >> >>> >>> On Mon, Feb 18, 2013 at 2:07 PM, Eduard Moraru < [email protected] >>> > >>> >>> wrote: >>> >>> > Hi devs, >>> >>> > >>> >>> > According to the Roadmap of 5.0 [1][2] we will be deprecating the >>> virtual >>> >>> > mode API and moving to a virtual-by-default mode instead. >>> >>> > >>> >>> > The idea is that the multiwiki environment should be the default >>> and, >>> >>> > anyone wanting to use the single-wiki mode (as XE was doing in the >>> past), >>> >>> > will simply not create any subwiki. It is just pointless to have 2 >>> >>> products >>> >>> > for such a simple fact and it also confuses users that have >>> downloaded >>> >>> and >>> >>> > started to use one product and later on realise that they needed >>> the >>> >>> other. >>> >>> > Also, when installing the wiki-manager and/or workspace >>> extension(s) >>> >>> > (because you might want to create subwikis/workspaces), there will >>> be no >>> >>> > need to stop the wiki, enable-virtual mode and restart it; all >>> will be >>> >>> > doable in the browser. >>> >>> > >>> >>> > Therefore, I`m sending this mail to ask your opinion about this >>> topic, in >>> >>> > case you might have something to say against it, and also to >>> brainstorm >>> >>> on >>> >>> > the required changes and implications on existing code so that the >>> >>> > transition is as smooth and invisible as possible. >>> >>> > >>> >>> > Proposed changes: >>> >>> > - Remove "xwiki.virtual" from xwiki.cfg(.vm) >>> >>> > -- remove the usage of the "$xwikiCfgVirtual" maven property from >>> >>> > xwiki-platform (, xwiki-enteprise and xwiki-manager) >>> >>> > - Deprecate boolean com.xpn.xwiki.XWiki.isVirtualMode() (and the >>> >>> api.XWiki >>> >>> > version) >>> >>> > -- change its code to >>> ((getVirtualWikisDatabaseNames(context).size() == >>> >>> 1) >>> >>> > ? true : false) until it is removed by the deprecation process. >>> >>> >>> >>> -1. It means that you are going to be in non virtual mode when >>> >>> starting XEM which is very wrong and the complete opposite of what we >>> >>> want here. We should deprecate and don't touch it's implementation in >>> >>> any way other that returning true by default instead of false when >>> >>> there is nothing in the configuration. Again as you said the goal is >>> >>> to be in virtual mode by default, period. If the UI want to do >>> >>> something different when there is only one wiki the UI should test if >>> >>> there is only one wiki but breaking all extensions counting on the >>> >>> virtual mode is very bad API breakage. >>> >>> >>> >> >>> >> I agree. The isVirtualMode check was supposed to tell you if "there >>> can be >>> >> more than one wiki", while I was suggesting to transform it to "are >>> there >>> >> currently more than one wikis?", which is obviously not equivalent. >>> >> >>> >> >>> >>> > >>> >>> > Possibly needed changes: >>> >>> > - Add main wiki default descriptor to xwiki-enterprise-ui (so that >>> >>> > getVirtualWikisDatabaseNames includes the main wiki and also to >>> avoid DNS >>> >>> > issues (?) caused by how we handle virtual mode) >>> >>> >>> >>> This is useless IMO: >>> >>> * the fact that getVirtualWikisDatabaseNames does not return the main >>> >>> wiki when there is no descriptor for it is a bug that should be fixed >>> >>> >>> >> >>> >> Ok. I have created the jira issue for it: >>> >> http://jira.xwiki.org/browse/XWIKI-8829 >>> >> >>> >> Also, on the same topic, I think that we should also expose the >>> >> getVirtualWikisDatabaseNames method in api.XWiki. Maybe we should >>> rename it >>> >> to something simpler like api.XWiki.getAllWikis() or >>> getAllWikiNames(). >>> > >>> > Yes, "getVirtualWikisDatabaseNames" is not very nice. >>> >>> This name is also pretty wrong btw since that's wiki names and not >>> database names which could be very different. >>> >>> > >>> >> >>> >> >>> >>> * I don't see how having a descriptor with localhost in it will help >>> >>> in any way not having DNS issue, it's not helping much in XEM it's >>> not >>> >>> going to be better in XE. IMO the right solution is to fallback on >>> >>> main wiki by default when the wiki is unknown instead of sending a >>> >>> redirect to some URL which cannot work and only allow to enable this >>> >>> redirect URL as an option >>> >>> >>> >> >>> >> Ok, so we comment out xwiki.virtual.redirect in xwiki.cfg and, by >>> default, >>> >> redirect to the main wiki's Main.WebHome. >>> > >>> > I carefully chose "fallback" and not "redirect" because a real >>> > redirect is impossible here since no URL will really be right or the >>> > main wiki. The idea would be to do exactly the same thing we do with >>> > IP, www.*,. >>> > >>> >> >>> >> An existing jira issue that is very related to this topic is >>> >> http://jira.xwiki.org/browse/XWIKI-479 We could reuse that. >>> > >>> > Yes we can reuse it but not follow the proposal in the comments. >>> > >>> >> >>> >> Thanks, >>> >> Eduard >>> >> >>> >>> >>> >>> > -- or have it generated programmatically at startup if it does not >>> exist >>> >>> > (might be safer this way, since people might be using a different >>> UI than >>> >>> > xwiki-enterprise-ui) >>> >>> > >>> >>> > I will start working on this locally and see if I can spot other >>> issues, >>> >>> > but please share your thoughts. >>> >>> > >>> >>> > Thanks, >>> >>> > Eduard >>> >>> > >>> >>> > ---------- >>> >>> > [1] http://markmail.org/message/o6adfbscpidnn7zr >>> >>> > [2] http://jira.xwiki.org/browse/XWIKI-8822 >>> >>> > _______________________________________________ >>> >>> > 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 >>> >>> >>> >> _______________________________________________ >>> >> devs mailing list >>> >> [email protected] >>> >> http://lists.xwiki.org/mailman/listinfo/devs >>> > >>> > >>> > >>> > -- >>> > Thomas Mortagne >>> >>> >>> >>> -- >>> Thomas Mortagne >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> >> > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
I will be first updating the feature-deprecate-virtual-mode branch with the latest changes from master and then will proceed to merging it into master so that it will be available in 5.0M2. Thanks for all the feedback so far, I hope we have identified most of the main issues: [1] Set virtual=1 by default and deprecate the virtual mode API -- main task [2] Add getWikiNames() method to api.XWiki that exposes the previously private XWiki.getVirtualWikisDatabaseNames() [3] Add convenience hasSubWikis() method to api.XWiki [4] getVirtualWikisDatabaseNames does not include the main wiki when it has no descriptor [5] Promote the wiki-manager's XWiki.XWikiServerClass to "mandatory class" status for the main wiki [6] Remove the autowww disabling configuration option [7] Replace "xwiki.virtual.redirect" with an error template(or page) just like the other errors -- previously referred to as http://jira.xwiki.org/browse/XWIKI-479 For more implementation details, please see the feature branch[8]. Thanks, Eduard ---------- [1] http://jira.xwiki.org/browse/XWIKI-8822 [2] http://jira.xwiki.org/browse/XWIKI-8841 [3] http://jira.xwiki.org/browse/XWIKI-8875 [4] http://jira.xwiki.org/browse/XWIKI-8829 [5] http://jira.xwiki.org/browse/XWIKI-8876 [6] http://jira.xwiki.org/browse/XWIKI-8877 [7] http://jira.xwiki.org/browse/XWIKI-8914 [8] https://github.com/xwiki/xwiki-platform/pull/86/commits On Tue, Mar 5, 2013 at 5:03 PM, Eduard Moraru <[email protected]> wrote:
Hi,
On Mon, Mar 4, 2013 at 8:34 PM, Denis Gervalle <[email protected]> wrote:
Hi Eduard,
On Mon, Mar 4, 2013 at 4:41 PM, Eduard Moraru <[email protected]> wrote:
Hi Denis,
On Sun, Mar 3, 2013 at 1:42 AM, Denis Gervalle <[email protected]> wrote:
Hi Edouard,
On Fri, Mar 1, 2013 at 6:28 PM, Eduard Moraru <[email protected]> wrote:
Hi Denis,
Nice feedback! Please see below...
On Wed, Feb 27, 2013 at 10:23 PM, Denis Gervalle <[email protected]> wrote:
Hi again Eduard,
Regarding point 5., this is where it may get complex to support properly existing configuration file. So, the first question would be to know if we accept to disrupt upgraded wiki that use an old configuration file ? If the answer is yes, than good release notes should allow explaining how to be careful and adapt existing configuration to avoid unreachable wiki.
Personally, causing such disruption has not my preference, since upgrading has not done so until now, AFAIK. Moreover, IMO being able to put by configuration the main wiki unreachable could only cause a negative feeling to newcomers. Option like autowww is probably useless complexity for the benefit. And the worse is the unknown wiki page that is never reach since it come from the main wiki to say it is itself unreachable (XWIKI-479).
What you propose is not so easy, since creating the descriptor implies knowing the hostname when usepath=0 which may happen in old config even if unused. So here is what I would suggest:
1) Follow Thomas proposal: ensure getVirtualWikisDatabaseNames() always return the main wiki, even when no descriptor is available, but not by creating such descriptor. This ensure main wiki availability anytime.
Already done in the feature branch. However, how do we handle point 5, as I have described it wrt. the wiki-manager plugin?
The getAllWikis() method basically returns the list of wiki document descriptors. While for XWiki.getVirtualWikisDatabaseNames() it was easy to add a new string to the list of results, how would we handle it for the wiki-manager plugin, where we have to add an unexistent document (with objects -- what values?) to the list of results?
Do we really need to handle it ? In no way you may create it automatically. If the wiki manager need it, it should handle this missing descriptor properly at UI level, proposing to create the descriptor and allowing the user to complete the required information.
Well, I think you`re right. We could just not handle it, but make sure that it is specified in the documentation that if the main wiki does not have a descriptor, it will not be included in the returned list. It is not clean/consistent but neither is it vital.
If we have 5) and it seems we need it (see below), the wiki manager could propose it as well.
I think that, when reffering to 5), we think of different things :).
For me, 5) is about handling the fact that wikiManager should return a descriptor for the main wiki when there is none. AFAIU, we agreed that it should just state in the documentation that the main wiki descriptor can be missing from the list if it does not exist.
For you, AFAIU, it's about XWIKI-479, autowww and (more generally) accessing the wiki.
Hope I got it right :) Even if they are related in concept ("what do we do about the main wiki's descriptor?"), let's try to keep them separate for now.
2) Stop using a redirect to reach the unknown wiki page. This is
also
annoying for a simple typo in an URL since you loose that URL from the address bar. I see no usual need for going to a page outside XWiki, so stop using that configuration and eventually provide a configuration for deciding the page name of the main wiki that will be rendered. Anyway, use a .vm like other error to render that (optional) page or a default. This way, you leave a workaround for anyone wishing to restore the old behavior (you may even suggest commented code for that in the .vm)
I like this idea of using a vm instead of a redirect.
3) Never proceed to unknown wiki page when there is only one wiki, considering any unknown as the main.
While I theoretically agree with this, in practice it might be a bit confusing for some users that explicitly wrote a subwiki (in domain based) or maybe they have a bookmark but they end up on the main wiki, where they could continue working without realizing that they are not on the wiki they have requested.
Considering this, I think I prefer to display an explicit error.
I do not understand your use case ?
What I have said is that if there is only a single main wiki, and no subwiki, never display the unknown wiki page, but reach the main wiki whatever the domain name is. If you don't, you do not fix several potential unreachable wiki issue that may arise by simple enabling virtual mode. I do not see the point of showing an error when there is only one available wiki.
I don`t like the fact that we are making an assumption... an you know what they say about when you "ass-u-me" :)
A "confusing" example may be the following: 1. The XWiki instance has the main wiki and 1 subwiki 2. The subwiki is removed 3. A user accesses the inexistent subwiki with outdated bookmarks (or who enters directly the url): subwiki.domain.com/xwiki/bin/view/Documentation/SomeDocumentation 3.1 He wants to add a paragraph at the end of the document and he is in a hurry 4. The space/page combination also exists on the main wiki, but it is diferent from what existed in the old subwiki. 5. The user edits the page and saves 6. The document is now inconsistent because the user did not pay attention to the URL and there was no visual indication (skin, panels, etc.) that he is on the wrong wiki
Remember that if *right now* there is only 1 wiki, it does not mean that there never were other wikis in the past.
An explicit error would have made the user alert and aware of what is going on.
I understand your point, however this is a crucial point for moving to virtual per default. Worse than your example is the one where a single wiki user upgrading does not reach its (main) wiki anymore. Seems having 5) is no more the icing on the cake but a required solution to avoid this really bad situation.
As far as I can see in the code [1], when talking about wiki access, autowww allows an upgrading user to access his wiki using the ip address or, AFAIU, using www.domain.com (which was what he would have been using already in 90% of time). Coupled with the warnings/notices in the upgrading instructions, this sounds acceptable.
Did I get it wrong?
Thanks, Eduard
---------- [1] https://github.com/xwiki/xwiki-platform/blob/0c75e74502357d791876a991558a685...
4) Deprecate the autowww option, which is now useless
I have just came across this feature, so I`m not really familiar
with
the
details and implications. As far as I understand it, by default, we allow the main wiki to be accessed trough the "www" subdomain (if tomcat is properly configured as well, I assume), "localhost" or ip address without having a descriptor. For all other cases, we proceed to get the descriptor and, if none is found, we redirect to whatever "xwiki.virtual.redirect" says.
Which part of this (except point 3 which we cleared above) are you suggesting to deprecate? The default behaviour or the option to disable this default behaviour? Please detail this a bit.
This exactly what it does, ensure accessibility to the main wiki through the IP, www subdomain and localhost, whatever the descriptor of the main wiki is. By default that feature is enable, so the option allow disabling. As you said yourself, you do not really understand that feature. This is why I am proposing to phase it out (no real change in code for now, simply stating this is deprecated). After a second thought, there may be one case where you need it, when you want to have a subwiki on www. Why not simply checking that no descriptor works for www before going to the main in that special case. For the IP and localhost, I do not see any reason to disable them.
Sounds good. Deprecate autowww and, additionally check if a subwiki named "www" exists.
5) Optional, but would be a nice to have for global admin, allow
fixing
the
main wiki descriptor from the unknown wiki page.
What do you mean by "fixing the main wiki descriptor from the unknown wiki page"? Please details this a bit as well.
Well, if the user is a global admin, provide through the unknown wiki error page a suggestion to access the main wiki or a way to fix up the main wiki descriptor to reestablish its access easily. I dislike the idea of having a dead end. But it is the icing on the cake.
I see now what you mean. Sounds good.
Thanks, Eduard
Thanks,
Thanks, Eduard
With those changes, you will fix most issue regarding the
reachability
of
wikis in virtual mode, and therefore, having virtual as the default should not be an issue anymore, whatever your configuration is.
WDYT ?
On Wed, Feb 27, 2013 at 10:21 AM, Eduard Moraru < [email protected] >wrote:
> Hi devs, > > To further fuel this discussion, I will mention some points that are more > or less problematic when removing the notion of virtual mode (checks for > xwiki.isVirtualMode()), since a direct change would leave a some pieces of > code dead (never called) or just need a bit of discussion on them: > > 1. c.x.x.s.XWikiHibernateBaseStore.initHibernate(XWikiContext context) [1] > > That piece of code seems to only run when the wiki is not in virtual mode. > From what I managed to understand from Thomas [2], it's probably this case: > "in your hibernate configuration if you set a database which is not called > 'xwiki'. In virtual mode this configuration is not taken into account and > you have to indicate the name of the database in xwiki.cfg". > I think we need to review this behavior. IMO, we should do take this > configuration into account in virtual mode as well, as long as there is no > other technical impediment. It is a configuration for the main wiki after > all, and it should still be valid. > > 2. c.x.x.XWiki.onPluginPreferenceEvent(Event event, XWikiDocument doc, > XWikiContext context) [3] > > This piece of code seems to reload the plugins if the "plugins" property > changed in XWikiPreferences, but only if the wiki is not in virtual mode. I > think we need to change this to happen for any wiki and the plugins need to > be reloaded only for that specific wiki for which the change happened (if > it is possible). > > 3. extension.vm - extensionActionButton macro [4] > > This UI code decides when to displays the (Un)Install button of an > extension for the current wiki or for the entire farm. Removing the virtual > mode check will always show the (un)install on farm button. I think Marius > had some concerns about his one. > > 4. distribution.vm - displayMainUiStep_unknownPreviousUI [5] > > This code assumes that if virtualMode is true, then the product is XEM, > otherwise it's XE. This is used to propose old version names for the 2 > products. Obviously this is needs to be refactored and use a different way > of determining which is which. > > 5. c.x.x.p.w.WikiManager > public List<Wiki> getAllWikis(XWikiContext context) throws > XWikiException [6] > > We have decided that c.x.x.XWiki.getVirtualWikisDatabaseNames will also > return the main wiki's name. However, the WikiManager plugin can not do > this so easily because the main wiki's descriptor may not exist. How could > we handle this, in order to be consistent? Would creating programmatically > the main wiki's descriptor with default values on ApplicationReady event do > any good? Will it do any harm? > > Thanks, > Eduard > > ---------- > [1] > >
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
> [2] > >
https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8...
> [3] > >
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
> [4] > >
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
> [5] > >
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
> [6] > >
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb...
> > > On Fri, Feb 22, 2013 at 3:48 PM, Eduard Moraru < [email protected]
> wrote: > > > Hi devs, > > > > To be more precise, the essence of my proposed change [1] is to actually > > always return "true" in the isVirtualMode() method, ignoring any > > configuration and marking the method as @deprecated, to be removed in > > future versions. > > > > Is there any reason not to do this? (Why) Would we want to preserve the > > possibility of going back to a non-virtual mode? (mostly addressed to > > Thomas, but to others as well) > > > > Thanks, > > Eduard > > > > ---------- > > [1] > > >
https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c8...
> > > > > > > > > > On Fri, Feb 22, 2013 at 3:39 PM, Eduard Moraru < [email protected] > >wrote: > > > >> Hi devs, > >> > >> As some of you have already noticed and already started providing > >> feedback (thank you), I have pushed a feature branch [1] that proposes > the > >> removal of the virtual mode concept (making it enabled and fixed by > >> default). > >> > >> I have also gone trough the code in xwiki-platform and removed, in the > >> feature branch, dead code (code branches that will never be reached > because > >> of this change). Some tests were also adapted to the new change. I have > >> also tried a build of xwiki-platform with these changes and it built > >> successfully. > >> > >> First of all, I want to make sure that we agree on the change, since > >> Thomas already mentioned that he does not agree (but I need more > details). > >> > >> Second, if we agree, please take the time to look over the changes > >> (particularly in the modules that you each have experience in) and > double > >> check that the logic of the code was not altered in any way. > >> > >> I will not be merging this branch until I get a general green light from > >> the committers, and until everybody is happy :) > >> > >> Please share your opinion both on this mail and/or on the specific > >> changes in the github commits. > >> > >> Thanks, > >> Eduard > >> > >> ---------- > >> [1] > >> >
https://github.com/xwiki/xwiki-platform/commits/feature-deprecate-virtual-mo...
> >> > >> > >> > >> On Mon, Feb 18, 2013 at 4:53 PM, Thomas Mortagne < > >> [email protected]> wrote: > >> > >>> On Mon, Feb 18, 2013 at 3:48 PM, Thomas Mortagne > >>> <[email protected]> wrote: > >>> > On Mon, Feb 18, 2013 at 3:38 PM, Eduard Moraru < [email protected] > > > >>> wrote: > >>> >> Hi Thomas, > >>> >> > >>> >> On Mon, Feb 18, 2013 at 3:45 PM, Thomas Mortagne > >>> >> <[email protected]>wrote: > >>> >> > >>> >>> On Mon, Feb 18, 2013 at 2:07 PM, Eduard Moraru < > [email protected] > >>> > > >>> >>> wrote: > >>> >>> > Hi devs, > >>> >>> > > >>> >>> > According to the Roadmap of 5.0 [1][2] we will be deprecating the > >>> virtual > >>> >>> > mode API and moving to a virtual-by-default mode instead. > >>> >>> > > >>> >>> > The idea is that the multiwiki environment should be the default > >>> and, > >>> >>> > anyone wanting to use the single-wiki mode (as XE was doing in > the > >>> past), > >>> >>> > will simply not create any subwiki. It is just pointless to have > 2 > >>> >>> products > >>> >>> > for such a simple fact and it also confuses users that have > >>> downloaded > >>> >>> and > >>> >>> > started to use one product and later on realise that they needed > >>> the > >>> >>> other. > >>> >>> > Also, when installing the wiki-manager and/or workspace > >>> extension(s) > >>> >>> > (because you might want to create subwikis/workspaces), there > will > >>> be no > >>> >>> > need to stop the wiki, enable-virtual mode and restart it; all > >>> will be > >>> >>> > doable in the browser. > >>> >>> > > >>> >>> > Therefore, I`m sending this mail to ask your opinion about this > >>> topic, in > >>> >>> > case you might have something to say against it, and also to > >>> brainstorm > >>> >>> on > >>> >>> > the required changes and implications on existing code so that > the > >>> >>> > transition is as smooth and invisible as possible. > >>> >>> > > >>> >>> > Proposed changes: > >>> >>> > - Remove "xwiki.virtual" from xwiki.cfg(.vm) > >>> >>> > -- remove the usage of the "$xwikiCfgVirtual" maven property from > >>> >>> > xwiki-platform (, xwiki-enteprise and xwiki-manager) > >>> >>> > - Deprecate boolean com.xpn.xwiki.XWiki.isVirtualMode() (and the > >>> >>> api.XWiki > >>> >>> > version) > >>> >>> > -- change its code to > >>> ((getVirtualWikisDatabaseNames(context).size() == > >>> >>> 1) > >>> >>> > ? true : false) until it is removed by the deprecation process. > >>> >>> > >>> >>> -1. It means that you are going to be in non virtual mode when > >>> >>> starting XEM which is very wrong and the complete opposite of what > we > >>> >>> want here. We should deprecate and don't touch it's implementation > in > >>> >>> any way other that returning true by default instead of false when > >>> >>> there is nothing in the configuration. Again as you said the goal > is > >>> >>> to be in virtual mode by default, period. If the UI want to do > >>> >>> something different when there is only one wiki the UI should test > if > >>> >>> there is only one wiki but breaking all extensions counting on the > >>> >>> virtual mode is very bad API breakage. > >>> >>> > >>> >> > >>> >> I agree. The isVirtualMode check was supposed to tell you if "there > >>> can be > >>> >> more than one wiki", while I was suggesting to transform it to "are > >>> there > >>> >> currently more than one wikis?", which is obviously not equivalent. > >>> >> > >>> >> > >>> >>> > > >>> >>> > Possibly needed changes: > >>> >>> > - Add main wiki default descriptor to xwiki-enterprise-ui (so > that > >>> >>> > getVirtualWikisDatabaseNames includes the main wiki and also to > >>> avoid DNS > >>> >>> > issues (?) caused by how we handle virtual mode) > >>> >>> > >>> >>> This is useless IMO: > >>> >>> * the fact that getVirtualWikisDatabaseNames does not return the > main > >>> >>> wiki when there is no descriptor for it is a bug that should be > fixed > >>> >>> > >>> >> > >>> >> Ok. I have created the jira issue for it: > >>> >> http://jira.xwiki.org/browse/XWIKI-8829 > >>> >> > >>> >> Also, on the same topic, I think that we should also expose the > >>> >> getVirtualWikisDatabaseNames method in api.XWiki. Maybe we should > >>> rename it > >>> >> to something simpler like api.XWiki.getAllWikis() or > >>> getAllWikiNames(). > >>> > > >>> > Yes, "getVirtualWikisDatabaseNames" is not very nice. > >>> > >>> This name is also pretty wrong btw since that's wiki names and not > >>> database names which could be very different. > >>> > >>> > > >>> >> > >>> >> > >>> >>> * I don't see how having a descriptor with localhost in it will > help > >>> >>> in any way not having DNS issue, it's not helping much in XEM it's > >>> not > >>> >>> going to be better in XE. IMO the right solution is to fallback on > >>> >>> main wiki by default when the wiki is unknown instead of sending a > >>> >>> redirect to some URL which cannot work and only allow to enable > this > >>> >>> redirect URL as an option > >>> >>> > >>> >> > >>> >> Ok, so we comment out xwiki.virtual.redirect in xwiki.cfg and, by > >>> default, > >>> >> redirect to the main wiki's Main.WebHome. > >>> > > >>> > I carefully chose "fallback" and not "redirect" because a real > >>> > redirect is impossible here since no URL will really be right or the > >>> > main wiki. The idea would be to do exactly the same thing we do with > >>> > IP, www.*,. > >>> > > >>> >> > >>> >> An existing jira issue that is very related to this topic is > >>> >> http://jira.xwiki.org/browse/XWIKI-479 We could reuse that. > >>> > > >>> > Yes we can reuse it but not follow the proposal in the comments. > >>> > > >>> >> > >>> >> Thanks, > >>> >> Eduard > >>> >> > >>> >>> > >>> >>> > -- or have it generated programmatically at startup if it does > not > >>> exist > >>> >>> > (might be safer this way, since people might be using a different > >>> UI than > >>> >>> > xwiki-enterprise-ui) > >>> >>> > > >>> >>> > I will start working on this locally and see if I can spot other > >>> issues, > >>> >>> > but please share your thoughts. > >>> >>> > > >>> >>> > Thanks, > >>> >>> > Eduard > >>> >>> > > >>> >>> > ---------- > >>> >>> > [1] http://markmail.org/message/o6adfbscpidnn7zr > >>> >>> > [2] http://jira.xwiki.org/browse/XWIKI-8822 > >>> >>> > _______________________________________________ > >>> >>> > 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 > >>> >>> > >>> >> _______________________________________________ > >>> >> devs mailing list > >>> >> [email protected] > >>> >> http://lists.xwiki.org/mailman/listinfo/devs > >>> > > >>> > > >>> > > >>> > -- > >>> > Thomas Mortagne > >>> > >>> > >>> > >>> -- > >>> Thomas Mortagne > >>> _______________________________________________ > >>> devs mailing list > >>> [email protected] > >>> http://lists.xwiki.org/mailman/listinfo/devs > >>> > >> > >> > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs >
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (7)
-
Caleb James DeLisle -
Denis Gervalle -
Eduard Moraru -
Guillaume Lerouge -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol