Failing after first reboot

Help / Discuss
#1

I installed on ubuntu 20.04 using the ppa

I completed the setup (standard flavor) and created some users. It was working fine. Then I rebooted my VM to increase memory and cpu (it was slow) and now when I visit the xwiki URL, I get the banner “XWiki is initializing (x%)…” but it stops at 50% and after a long while I get a java exception output in the browser.

java.lang.NoClassDefFoundError: Could not initialize class org.xwiki.xml. "XMLUtils"

Any ideas on how to fix this? I Googling this offered little help. it seems that maybe org.xwiki.xml is from an extension.

A little more background…

This is the second install on this VM. The first went fine, Making some content but then experimented by installing the Leiothrix skin (it was one of the first listed in the extensions manager searching for skin).

The skin overwrote my content and was broken. I uninstalled it and everything was messed up so I uninstalled/purged the xwiki*, tomcat* and mysql* packages, removed all of the left over folders and then reinstalled.

It seemed to work, but now after the reboot it is no longer working.

–BobG

#2

Would help if you could show the full errors you get in the xwiki logs (i.e. your servlet container logs). See https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Logging#HLogLocation

Note that this is a very old skin contributed by someone. I don’t even know if it still works. Best is to choose recommended extensions if you want to make sure to get good quality extensions. Or extensions with recent updates.

Note that if you check that Skin’s documentation page (https://extensions.xwiki.org/xwiki/bin/view/Extension/Leiothrix+Skin) it says:

This skin no longer works in XWiki 7.x+.

There’s no reason that when you uninstall an extension that anything would be broken. Maybe you just didn’t configure your wiki to use the previous skin and it was still pointing to Leiothrix which wasn’t not existing anymore? Note that you can force a skin using ?skin=flamingo in the URL at the end.

#3

FYI, I abandoned the VM and started over. I am now back to where I was before installing the skin which destroyed my site.

I liked the general story behind what xwiki is and I am trying to like it, but its not making it easy.

I installed that skin because it was the second one in the list after something with debug in the title. I did not mean to install a non-recommended skin. I did that because I made a copy of the flamingo skin following a page in the help but i was not showing up as an option. I just wanted to see if a skin installed by extension manager created a folder next to flamingo. It did not (!?). Why is a skin in the extension store allowed to provide content in the first place? That’s not what skins (should) do. The installer did stop on a “continue” prompt which was probably warning me that it was going to destroy my content but I was numb to hitting continue in the weird, non-standard UI.

Later I found that the list of skins does not correspond to the names of the folders of skins that you install in the filesystem nor the name of the skin in extension manager! ‘flamingo’ is not even an option in the drop down! By default there are two generically names “Skin (default)” and “skin bla bla bla” (which I assume is the user friendly name of flamingo). After installing Leiothrix skin, another option called something like “Public Site” show up in the list. I found through trail and error that I can enter the name of a skin folder (like flamingo) manually even though its not an option in the dropdown…

This seems like a naming issue. In an attempt to make the skin names in the admin UI “user friendly” a level of indirection was added that made it seem broken to me as I tried to introduce a new theme.

Now I am dealing with another more fundamental naming issue for pages. I created a nest page from from home called Team. Home.Team has nested pages for each person in that team. i.e. Home.Team.Bobg. I then included {{include page=./Team}} in Home but that breaks the Home.Team.Bobg link which now shows as a page that needs creation. If I create a new page via that link, not only do a get a new duplicate BobG page, but the Navigation Application shows it as a new duplicate top level Home node with a duplicate Team and BobG underneath it.

The page index reveals that the new page is Main/Team/BobG even though the Navigation Application shows it as a duplicate Home->Team->BobG hirearchy. Note that despite the link in the Team page being fully qualified as doc:Home.Team.BobG.WebHome (where the heck does WebHome come from?), it is interpreted differently based on whether you visit Team directly or the Team content is rendered inside of the Home page.

I have tried including the Wiki name in the link and with and without that weird ‘WebHome’ suffix.

Sometimes the path separator is ‘/’ and sometimes its ‘.’ but they are not interchangeable! You cant use ‘/’ in the link syntax yet the page index UI uses ‘/’ to show you the fully qualified page ID/location!

The page picker UI has this weird behavior that it shows the first level page tree initially but pages that contain nested pages do not show as folders that can be expanded. You have to select that page as if its the page you want and then re-enter the picker which will then show only the next level of choices, and repeat until you get to where you want to go.

These inconsistencies make it hard for me to have faith that I will be able to build a non-trivial site with xwiki with any sort of reasonable efficiency.

–BobG

#4

FYI, I figured out what was going on with the nested links.

The top level page that Standard Flavor left me with looks like its name is “Home” but actually its name is “Main” – not to be confused with the “Main wiki”, whose actual name is “xwiki”, pretty name is “Home” and description is “Main wiki” :slight_smile:

So the real, fully qualified name of my page is Main.Home.Team.BobG.WebHome and now it works as expected.

I am only doing a few sections as included nested ‘section’ pages like this and I was glad to see when not doing that, the links can indeed be simple and terse and nesting works in a sane way.

Things are looking up (a bit anyway). Now if I can just get my head around when “.WebHome” is needed :slight_smile:

–BobG

#5

The wiki home page is configurable. By default it i’s Main.WebHome.

Yeah all this is because the references are technical and don’t mean much for end users. Thus the UI tries to use more layman’s terms such as Home. We’re supposed to have pickers everywhere so that you don’t need to know the references (except if you’re in wiki mode).

We also went through 14 years of history and we haven’t boken backward compatibility (or tried to, it’s very important to us, for our users).

See:

Hope it helps

#6

I dont buy the notion that references are technical and users need something else. Its all information theory which comes down to [state, behaviour, and identity]. The problem here is that the coding is too far away from the application. There should not be a separate nomenclature for programmers and users and a superfluous system for translating between them. Why would the code even care what the entry level page is called? It sounds like some programmers called that member variable reference “main” and someone mistakenly used that token as the root of the page name reference instead of the dynamic name that the page actually is. Absolute vs relative identitfying references should not be determined by the name that comes first but by a well know token (often the delemiter) appearing first.

Naming and organizing wiki content is the same type of thing as programming. Wiki references should transparently reflect that structure.

Sorry for the rant. I am just disappointed.
–BobG

#7

Well it happened again. After rebooting the vm, I am greeted with a java exception in the browser.

After my last fresh install I did reboot and observed that it did still work. Now after entering a little content yesterday, I rebooted this morning for an unrelated issue concerning php and after the reboot I get the following error ( I wil attach the files after I post this).

I confirmed that I can access the mysql db with the configured username/password that are in the hibernate.cfg.xml file.

Well, I can not find a way to attach a file and the error alone, is too big to paste in the post. Oh well.

#8

Wild idea: what have you configured as the xwiki permanent directory?

See https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Configuration/#HConfiguringDirectories

EDIT: if you’ve used https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation/InstallationViaAPT/ then it should be fine. I was worried you could have left the perm directory into a temporary directory that was reset at reboot.

#9

I have never heard of something like that. Is the exception the same as the one you indicated above? I don’t see how pasting a stack trace is too large. We need the first stack trace from the logs after you start XWiki (the following ones are usually repeats and are usually not significative). You can also any external tool to upload files if you need (gist, pastebin, etc).

In any case, it’s hard to help you without details (logs, details about your configuration, how to reproduce, etc).

#10

I’m sorry you don’t buy it. So to be more clear there are 2 concepts:

  • Page titles (displayed in the UI in most places)
  • Page references (technical id of the page, used in the URLs and in API when you need to reference a page).

For the default home page:

  • title = Home
  • reference = `Main.WebHome``

See also https://www.xwiki.org/xwiki/bin/view/FAQ/How%20can%20I%20get%20the%20reference%20of%20a%20page

Now, in order to make it easy for users, the create page UI for simple users only propose to set the title of the page (and creates the page reference based on the title). Advanced users can choose a page reference different than the title, though, see https://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/DocumentLifecycle/#HByusingtheAddPageaction

#11

I was just now going to capture the startup log to share in a gist but it worked.

FYI, before I restarted tomcat I noticed that as it sat idle for a day, tomcat had an out of memory exception. I have -Xmx1024m included in JAVA_OPTS.

   Exception in thread "Active Installs Ping Thread" java.lang.OutOfMemoryError: GC overhead limit exceeded

I will continue my evaluation now.

Thank you for your attention. Its a big plus for xwiki that I do feel that if we have problems in production later, we would be able to get help here.

re: Page references.
Now that my wiki is working again I had a chance to explore – changing titles and renaming pages. Here are my thoughts for what its worth…

  1. Page Main (aka Home) is special
    • this is unlike any other page I create because I can not rename it and unless I set the title to ‘Main’, the title has to be different from the name.
    • there is no good programming/design reason why it needs to be. Any programming usecase that thinks it must be special can be refactored to make it not special. The wiki should store the name of the entry point page as a property and the page that it points to could be any page.
    • because this page is the root of all pages created from it (which may be all user created pages in some wikis), and this page typically will not have its title and name the same, users are forced to confront the fact that references are not what they appear to be as soon as they have to create an absolute reference.
  2. Title vs name (I am using ‘name’ as the page part of a reference)
    • It seems like you are trying to make the title be the identity of the page because …
      • when you rename the page, it forces both the title and name to be set to the new name – not even an option to keep the title text that the user might have entered previously.
      • the UI (breadcrumbs, nav tree, pickers…) uses only the Title as the identity of the page that is presented to the user.
      • once the title is different from the name, the Page name is hidden from the user and you need to create a FAQ to tell them how to find it.
    • yet, you encourage users to make the title different from the page’s identity by making it a very prominent feature when editing a page.
    • IMHO, its good to allow the page title to be different from its name but you should present the name more prominently in the UI.
      • the UI should always present the name first (mandatory) and then use the title as extra information (optional), sometimes as a tooltip (e.g. breadcrumbs), sometimes as a generated label that adds the title to the label when its different from the name like <name>: <title> (e.g. picker), and sometimes as a separate field (e.g. page index and page edition).
      • The one exception is the actual rendered page’s Title. That should be the title text and you do not need to display the name in the rendered page context or if you do, it should be less prominent – maybe a toolip in the actual title.
      • The Title should be thought of as an optional clarification or prettier version of the name when the user thinks that the name does not stand on its own.
      • In edit mode, they should both be shown as fields but the name would not editable. It would probably include some indication that the user could change its value by renaming the page.
      • When creating a page, the user should be able to enter the title and have the name filled in automatically from the title but the user should be able to override that and name it what ever they want before creating the page.
        • some users will choose to always have the title and name be the same and it will work pretty much as it does today except it will be more clear that they have to rename the page to change the title if they want them to be the same.
        • other users may create a terse, mnemonic structure for names like programming variables and then use long titles for presentation and clarification of what the terse name means.
  3. .WebHome does not add any semantic meaning in the usecases I have implemented so far so why must users deal with it as mandatory for common use cases and see it in the page reference in the information tab?
    • it appears the .WebHome refers to the (rendered?) page content.
    • If there are alternative semantic meanings that must be distinguished they should have mandatory qualifiers and .WebHome should always be a optional qualifier.

These three things make references unintuitive and as a result, you need to create features for finding out what a page’s reference is as if its some cryptic stuff that the user should not normally concern themselves with. You had to create a FAQ Page to tell users how to access those features because its unintuitive.

References are not a technical programming thing in a wiki because they are intrinsically part of the content that the user creates and maintains. That was one of the two original breakthroughs that wikis brought to the table.

–BobG