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/0c75e74502357d791876a991558a6853157aacc0/xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/XWiki.java#L534 > >> >> >> > >> > > >> > > > >> > > > > 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/3019c6e0df112adf980641c75aaaffb2f0b17c6f/xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/store/XWikiHibernateBaseStore.java#L214 >> > > > > > [2] >> > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c869ccce74478#commitcomment-2679994 >> > > > > > [3] >> > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb2f0b17c6f/xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/XWiki.java#L6521 >> > > > > > [4] >> > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb2f0b17c6f/xwiki-platform-core/xwiki-platform-web/src/main/webapp/templates/extension.vm#L971 >> > > > > > [5] >> > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb2f0b17c6f/xwiki-platform-core/xwiki-platform-web/src/main/webapp/templates/distribution.vm#L194 >> > > > > > [6] >> > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaffb2f0b17c6f/xwiki-platform-core/xwiki-platform-wiki-manager/xwiki-platform-wiki-manager-api/src/main/java/com/xpn/xwiki/plugin/wikimanager/WikiManager.java#L223 >> > > > > > >> > > > > > >> > > > > > 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/ce3d9d28aefdb327d407ef179a4c869ccce74478 >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > 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-mode >> > > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> 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 >> > > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
