4 Mar
2013
4 Mar
'13
7:34 p.m.
Hi Eduard,
On Mon, Mar 4, 2013 at 4:41 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
This
based)
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.
disabling.
error
virtual
the
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaff…
https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c…
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaff…
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaff…
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaff…
https://github.com/xwiki/xwiki-platform/blob/3019c6e0df112adf980641c75aaaff…
providing
by
> > > >> default).
> > > >>
> > > >> I have also gone trough the code in xwiki-platform and removed,
in
change. I
changes
specific
https://github.com/xwiki/xwiki-platform/commits/feature-deprecate-virtual-m…
doing
it;
property
when
> > > >>> >>> starting XEM which is very wrong and the
complete opposite of
should
if
return
enable
> > > this
> > > >>> >>> redirect URL as an option
> > > >>> >>>
> > > >>> >>
> > > >>> >> Ok, so we comment out xwiki.virtual.redirect in
xwiki.cfg and,
do
spot
--
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
Hi Denis,
On Sun, Mar 3, 2013 at 1:42 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
if
the
(XWIKI-479).
as I
automatically.
If we have 5) and it seems we need it (see below), the wiki manager could
propose it as well.
Hi Edouard,
On Fri, Mar 1, 2013 at 6:28 PM, Eduard Moraru <enygma2002(a)gmail.com>
wrote:
> Hi Denis,
>
> Nice feedback! Please see below...
>
> On Wed, Feb 27, 2013 at 10:23 PM, Denis Gervalle <dgl(a)softec.lu>
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 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 > 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 > >
> > 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, 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 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. 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 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 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
wiki
main wiki descriptor from the unknown wiki page.
What do you mean by "fixing the main wiki descriptor from the unknown page"? Please details this a bit as well.
Well, if the user is a global admin, provide through the unknown wiki 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 > > 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
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
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 (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
2
not
> > 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
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]
>
>
> [2]
>
>
> [3]
>
>
> [4]
>
>
> [5]
>
>
> [6]
>
>
> > >
> > >
> > > 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
https://github.com/xwiki/xwiki-platform/commit/ce3d9d28aefdb327d407ef179a4c…
> >
Thomas, but to others as well)
> >
> > Thanks,
> > Eduard
> >
> > ----------
> > [1]
> >
>
> >
>
> > >
> > >
> > >
> > > 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 > >> feedback (thank you), I have pushed a
feature branch [1] that
proposes
> > the
> > >> removal of the virtual mode concept (making it enabled and fixed
the
> > >> feature branch, dead code (code branches that will never be
reached
> > > because
> > > >> of this change). Some tests were also adapted to the new >
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 > > > >> (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 > >> changes in the github commits.
> >>
> >> Thanks,
> >> Eduard
> >>
> >> ----------
> >> [1]
> >>
>
> >
>>
> > >>
> > >>
> > >> On Mon, Feb 18, 2013 at 4:53 PM, Thomas Mortagne <
> > >> thomas.mortagne(a)xwiki.com> wrote:
> > >>
> > >>> On Mon, Feb 18, 2013 at 3:48 PM, Thomas Mortagne
> > >>> <thomas.mortagne(a)xwiki.com> 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
> > >>> >> <thomas.mortagne(a)xwiki.com>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 > 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 > 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 > 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 > > 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 >
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 > > "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 > the
> > > main
> > > >>> >>> wiki when there is no descriptor for it is a bug
that
should
be
not
XEM
> > 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
> > >>> 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 >
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 > 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 >
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 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