Re: [xwiki-devs] [Discussion] Set virtual=1 by default and deprecate the virtual mode API

15 Mar 2013

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 &lt;enygma2002(a)gmail.com&gt; wrote:

...
  Hi,

 On Mon, Mar 4, 2013 at 8:34 PM, Denis Gervalle &lt;dgl(a)softec.lu&gt; wrote:

  Hi Eduard,

 On Mon, Mar 4, 2013 at 4:41 PM, Eduard Moraru &lt;enygma2002(a)gmail.com&gt;
 wrote:

  Hi Denis,

 On Sun, Mar 3, 2013 at 1:42 AM, Denis Gervalle &lt;dgl(a)softec.lu&gt; wrote:

  Hi Edouard,

 On Fri, Mar 1, 2013 at 6:28 PM, Eduard Moraru &lt;enygma2002(a)gmail.com&gt;
 wrote:

 > Hi Denis,
 >
 > Nice feedback! Please see below...
 >
 > On Wed, Feb 27, 2013 at 10:23 PM, Denis Gervalle &lt;dgl(a)softec.lu&gt; 
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/0c75e74502357d791876a991558a68…

 >
 > >
 > > > 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 < 
enygma2002(a)gmail.com
  > > >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/3019c6e0df112adf980641c75aaaff…
   > >
> [2]
 > > >
 > > >
 > >
 >

https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c…
   > >
> [3]
 > > >
 > > >
 > >
 >

https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaff…
   > >
> [4]
 > > >
 > > >
 > >
 >

https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaff…
   > >
> [5]
 > > >
 > > >
 > >
 >

https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaff…
   > >
> [6]
 > > >
 > > >
 > >
 >

https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaff…
   > >
>
 > > >
 > > > On Fri, Feb 22, 2013 at 3:48 PM, Eduard Moraru < 
enygma2002(a)gmail.com
 > >
 > > > > 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/ce3d9d28aefdb327d407ef179a4c…
   > >
> >
 > > > >
 > > > >
 > > > >
 > > > > On Fri, Feb 22, 2013 at 3:39 PM, Eduard Moraru <
 enygma2002(a)gmail.com
 > > > >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-m…
  > > > > >>
 > > > > >>
 > > > > >>
 > > > > >> On Mon, Feb 18, 2013 at 4:53 PM, Thomas Mortagne <
 > > > > >> thomas.mortagne(a)xwiki.com&gt; wrote:
 > > > > >>
 > > > > >>> On Mon, Feb 18, 2013 at 3:48 PM, Thomas Mortagne
 > > > > >>> &lt;thomas.mortagne(a)xwiki.com&gt; wrote:
 > > > > >>> > On Mon, Feb 18, 2013 at 3:38 PM, Eduard Moraru
<
 > > > enygma2002(a)gmail.com
 > > > > >
 > > > > >>> wrote:
 > > > > >>> >> Hi Thomas,
 > > > > >>> >>
 > > > > >>> >> On Mon, Feb 18, 2013 at 3:45 PM, Thomas
Mortagne
 > > > > >>> >> &lt;thomas.mortagne(a)xwiki.com&gt;wrote;wrote:
 > > > > >>> >>
 > > > > >>> >>> On Mon, Feb 18, 2013 at 2:07 PM, Eduard
Moraru <
 > > > > enygma2002(a)gmail.com
 > > > > >>> >
 > > > > >>> >>> 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
 > > > >>> >>> > devs(a)xwiki.org
 > > > >>> >>> >
http://lists.xwiki.org/mailman/listinfo/devs
 > > > >>> >>>
 > > > >>> >>>
 > > > >>> >>>
 > > > >>> >>> --
 > > > >>> >>> Thomas Mortagne
 > > > >>> >>> _______________________________________________
 > > > >>> >>> devs mailing list
 > > > >>> >>> devs(a)xwiki.org
 > > > >>> >>> http://lists.xwiki.org/mailman/listinfo/devs
 > > > >>> >>>
 > > > >>> >> _______________________________________________
 > > > >>> >> devs mailing list
 > > > >>> >> devs(a)xwiki.org
 > > > >>> >> http://lists.xwiki.org/mailman/listinfo/devs
 > > > >>> >
 > > > >>> >
 > > > >>> >
 > > > >>> > --
 > > > >>> > Thomas Mortagne
 > > > >>>
 > > > >>>
 > > > >>>
 > > > >>> --
 > > > >>> Thomas Mortagne
 > > > >>> _______________________________________________
 > > > >>> devs mailing list
 > > > >>> devs(a)xwiki.org
 > > > >>> http://lists.xwiki.org/mailman/listinfo/devs
 > > > >>>
 > > > >>
 > > > >>
 > > > >
 > > > _______________________________________________
 > > > devs mailing list
 > > > devs(a)xwiki.org
 > > > http://lists.xwiki.org/mailman/listinfo/devs
 > > >
 > >
 > >
 > >
 > > --
 > > Denis Gervalle
 > > SOFTEC sa - CEO
 > > eGuilde sarl - CTO
 > > _______________________________________________
 > > devs mailing list
 > > devs(a)xwiki.org
 > > http://lists.xwiki.org/mailman/listinfo/devs
 > >
 > _______________________________________________
 > devs mailing list
 > devs(a)xwiki.org
 > http://lists.xwiki.org/mailman/listinfo/devs
 >

 --
 Denis Gervalle
 SOFTEC sa - CEO
 eGuilde sarl - CTO
 _______________________________________________
 devs mailing list
 devs(a)xwiki.org
 http://lists.xwiki.org/mailman/listinfo/devs
  _______________________________________________
 devs mailing list
 devs(a)xwiki.org
 http://lists.xwiki.org/mailman/listinfo/devs

 --
 Denis Gervalle
 SOFTEC sa - CEO
 eGuilde sarl - CTO
 _______________________________________________
 devs mailing list
 devs(a)xwiki.org
 http://lists.xwiki.org/mailman/listinfo/devs

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Re: [xwiki-devs] [Discussion] Set virtual=1 by default and deprecate the virtual mode API