I tried for a few weeks to make XWiki work for me and even though it worked out well in the beginning I will not go into production with it. These are the issues I had to deal with it: 1) Renaming Pages and Spaces leave the wiki somewhat in limbo because the references are not working anymore. Copying around the pages seems to do the trick but I leaves a lingering bad feeling. For Example I can rename the Web Home of a Space but then the Space because empty (? at the end). I cannot rename the WebHome because the new Space already has that Document and then I need to manually copy each document one by one. 2) Upgrade to a new minor release is a nightmare. Even though the WAR file can be easily replaced and seems to work fine the upgrading of documents is a blind flight because there is no list that tells me what should be imported and not. XWiki should now which documents where edited and so should be able to give a hint if they were changes before importing them. I would also like a way to create a diff of the existing file and the one I like to import. 3) I cannot make XWiki work on JBoss without messing around with Classloader settings. This is a no-go because I cannot afford to make existing applications fail. 4) I cannot build the current XWiki code (from SVN) because the XWikiDocument in the Core is messed up. I also have no idea how I can get the code of an existing release (no docu). This means I cannot figure out if I try to fix the classloading. This is the compiler error: /Users/schaefa/Development/xwiki/trunks/core/xwiki-core/src/main/java/ com/xpn/xwiki/doc/XWikiDocument.java:[3273,15] cannot find symbol symbol : method getRenderedContent(java.lang.String,com.xpn.xwiki.XWikiContext) location: class com.xpn.xwiki.doc.XWikiDocument UPDATE: as of tonight I fail now building the WYSIWYG component (Mac OS X 10.5.7, JDK 1.6, Maven 2.0.10): INFO] ------------------------------------------------------------------------ [INFO] Building XWiki Platform - Web - WYSIWYG [INFO] task-segment: [package] [INFO] ------------------------------------------------------------------------ [INFO] [enforcer:enforce {execution: default}] [INFO] [remote-resources:process {execution: xwiki-license-resources}] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [dependency:unpack {execution: unzip-gwt-libs}] [INFO] Configured Artifact: com.google.gwt:gwt-dev:mac-libs:1.5.3:zip [INFO] gwt-dev-1.5.3-mac-libs.zip already unpacked. [INFO] [gwt:compile {execution: generate-javascript}] [INFO] establishing classpath list (buildClaspathList - scope = COMPILE) [INFO] google.webtoolkit.home (gwtHome) *not* set, using project POM for GWT dependencies Removing units with errors [ERROR] Errors in 'file:/Users/schaefa/Development/xwiki/trunks/ web/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/client/util/ Attachment.java' [ERROR] Line 27: No source code is available for type com.xpn.xwiki.gwt.api.client.Attachment; did you forget to inherit a required module? [ERROR] Errors in 'file:/Users/schaefa/Development/xwiki/trunks/ web/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/client/ WysiwygService.java' [ERROR] Line 136: No source code is available for type com.xpn.xwiki.gwt.api.client.XWikiGWTException; did you forget to inherit a required module? [ERROR] Errors in 'file:/Users/schaefa/Development/xwiki/trunks/ web/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/client/Wysiwyg.java' [ERROR] Line 49: No source code is available for type com.xpn.xwiki.gwt.api.client.app.XWikiGWTDefaultApp; did you forget to inherit a required module? [ERROR] Line 67: No source code is available for type com.xpn.xwiki.gwt.api.client.app.XWikiAsyncCallback; did you forget to inherit a required module? [ERROR] Errors in 'file:/Users/schaefa/Development/xwiki/trunks/ web/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/client/plugin/sync/ SyncPlugin.java' [ERROR] Line 438: No source code is available for type com.xpn.xwiki.gwt.api.client.dialog.MessageDialog; did you forget to inherit a required module? [ERROR] Line 438: No source code is available for type com.xpn.xwiki.gwt.api.client.dialog.Dialog; did you forget to inherit a required module? [ERROR] Line 452: No source code is available for type com.xpn.xwiki.gwt.api.client.XWikiGWTException; did you forget to inherit a required module? 4b) In the same direction I was not able to check out the source of my current released version. 5) Handling of images is cumbersome. If I have a lot of images to be added to a page like a walkthrough then uploading the images is a hercules task. I would expect that I could add x number of files or mark a number of file before hitting upload or delete. This works in the JSPWiki. I also saw that with JIRA I can add an image directly from the clipboard into the web page. I am not a Web Expert and so I don't know how difficult that is. 6) I tried to keep the images in one document and reference them in the pages containing the text. But I can only use get the reference in the WYSIWYG editor when the images are in the same page. I expect that I can at least list all the image names from the entire space or from another document. Sometimes I need to reuse the images or I want to reuse the page without having to reupload all the images. 7) The Trail is broken in my installation bringing up an error page even though the page is available. This is because I copied some pages around and the trail is now pointing to the old defunct space. 8) How can I delete a space 9) In case I want to clean up my somewhat messy wiki and only export a given Space so that I can recreate the Wiki and then import only that given Space. Currently it seems I can only export everything and then only select the space I want to be imported. I would prefer to do it the other way around. 10) I see really strange reaction from the system when a Space name (maybe even regular documents) contain a dot at the end. If that is an issue why is the application no displaying a warning or error when that happens (see my issue with the Trail). I think that is bugging me the most right now. I still like XWiki the most so far and would be disappointed if I could not use it. I also would be willing to help dealing with the JBoss classloading issue if I can get the build to compile. Andreas Schaefer CEO of Madplanet.com Inc. Email: [email protected] [email protected] Twitter; andy_mpc AIM: [email protected]
Hi Andreas, sorry to hear you have these problems. See below. Andreas Schaefer wrote:
I tried for a few weeks to make XWiki work for me and even though it worked out well in the beginning I will not go into production with it. These are the issues I had to deal with it:
1) Renaming Pages and Spaces leave the wiki somewhat in limbo because the references are not working anymore. Copying around the pages seems to do the trick but I leaves a lingering bad feeling.
For Example I can rename the Web Home of a Space but then the Space because empty (? at the end). I cannot rename the WebHome because the new Space already has that Document and then I need to manually copy each document one by one.
http://code.xwiki.org/xwiki/bin/view/Snippets/RenameSpaceSnippet (linked from http://platform.xwiki.org/xwiki/bin/view/Features/Spaces) I guess a problem is that it is not clear enough that spaces are not real, there is no "Space" entity. A space is just a common prefix for documents. As long as there are documents with a given space, that space exists. A special case is the WebHome document, which is considered to be the homepage of the space. So renaming the WebHome of a space causes the space to still exist, but it's index does not exist anymore.
2) Upgrade to a new minor release is a nightmare. Even though the WAR file can be easily replaced and seems to work fine the upgrading of documents is a blind flight because there is no list that tells me what should be imported and not.
http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Installation#HUpgradingw... It is generally a good idea not to modify default documents, except Main.WebHome. This way, upgrading the XAR is as simple as uploading it, unselecting 4 documents (Main.WebHome, XWiki.XWikiPreferences, XWiki.XWikiAllGroup and XWiki.AdminGroup), and importing the rest of the documents.
XWiki should now which documents where edited and so should be able to give a hint if they were changes before importing them. I would also like a way to create a diff of the existing file and the one I like to import.
Yes, this is a planned improvement, but since upgrades are not such a frequent operation, other issues have been given priority.
3) I cannot make XWiki work on JBoss without messing around with Classloader settings. This is a no-go because I cannot afford to make existing applications fail.
Well, since XWiki works fine with Tomcat and Jetty, without any classpath changes, then I'd say the fault is also partially on the JBoss side. Still, we're willing to solve as much as we can on our side. Can you please create bug reports on jira.xwiki.org ?
4) I cannot build the current XWiki code (from SVN) because the XWikiDocument in the Core is messed up. I also have no idea how I can get the code of an existing release (no docu). This means I cannot figure out if I try to fix the classloading. This is the compiler error:
Did you try updating the code? The build works fine for all the developers, and it also works on our automatic build server (http://hudson.xwiki.org/job/xwiki-platform-core/ shows one failed build during the last 10 builds). If you're trying to build just a snapshot module from old sources, the newer versions of the dependencies are downloaded from the web, coming with a changed API.
/Users/schaefa/Development/xwiki/trunks/core/xwiki-core/src/main/java/ com/xpn/xwiki/doc/XWikiDocument.java:[3273,15] cannot find symbol symbol : method getRenderedContent(java.lang.String,com.xpn.xwiki.XWikiContext) location: class com.xpn.xwiki.doc.XWikiDocument
UPDATE: as of tonight I fail now building the WYSIWYG component (Mac OS X 10.5.7, JDK 1.6, Maven 2.0.10):
I also get this error sometimes, but only when building it from inside the trunks folder, and only with Maven 2.1.0. Try building directly from the web/wysiwyg folder.
Removing units with errors [ERROR] Errors in 'file:/Users/schaefa/Development/xwiki/trunks/ web/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/client/util/ Attachment.java'
4b) In the same direction I was not able to check out the source of my current released version.
Since XWiki is not just one project, but a stack consisting of a core platform, plugins, applications and a final product on top of it, the sources are distributed in several modules. I think http://dev.xwiki.org/xwiki/bin/view/Community/SourceRepository explains it pretty well. The sources for released versions of the platform are at http://svn.xwiki.org/svnroot/xwiki/platform/core/tags/ , just select which one you want and "svn checkout" it. If you want the sources for just one module, we also have source jars generated during releases, for example: http://maven.xwiki.org/releases/com/xpn/xwiki/platform/xwiki-core/1.8.4/xwik... http://maven.xwiki.org/releases/org/xwiki/platform/xwiki-core-rendering-api/...
5) Handling of images is cumbersome. If I have a lot of images to be added to a page like a walkthrough then uploading the images is a hercules task. I would expect that I could add x number of files or mark a number of file before hitting upload or delete. This works in the JSPWiki. I also saw that with JIRA I can add an image directly from the clipboard into the web page. I am not a Web Expert and so I don't know how difficult that is.
Since 1.9M2 it is possible to upload more files in a request, using the attachment upload form in view mode. Using the WYSIWYG editors it is also possible to upload files directly when editing the document.
6) I tried to keep the images in one document and reference them in the pages containing the text. But I can only use get the reference in the WYSIWYG editor when the images are in the same page. I expect that I can at least list all the image names from the entire space or from another document. Sometimes I need to reuse the images or I want to reuse the page without having to reupload all the images.
Did you read the documentation for the image macro? http://code.xwiki.org/xwiki/bin/view/Macros/ImageMacro lists the "document" parameter, which indicates the source document, so: {image:file.png|document=Main.Pictures} should insert the "file.png" image from the "Main.Pictures" document. The new WYSIWYG editor, available for documents in the xwiki/2.0 syntax, which will be the default syntax starting with 1.9, also allows selecting images from other documents. Indeed, the old WYSIWYG editor did not have this functionality.
7) The Trail is broken in my installation bringing up an error page even though the page is available. This is because I copied some pages around and the trail is now pointing to the old defunct space.
The rename function does not update the parent field yet (http://jira.xwiki.org/jira/browse/XWIKI-1082 ), so this is a known bug. Still, why do you rename things so often? Renaming should only happen once in a while, when you just realized that a page is wrongly named. Few people complained about Rename problems so far, although we are aware of such problems.
8) How can I delete a space
http://code.xwiki.org/xwiki/bin/view/Snippets/DeleteSpaceSnippet (linked from http://platform.xwiki.org/xwiki/bin/view/Features/Spaces)
9) In case I want to clean up my somewhat messy wiki and only export a given Space so that I can recreate the Wiki and then import only that given Space. Currently it seems I can only export everything and then only select the space I want to be imported. I would prefer to do it the other way around.
You can try using http://code.xwiki.org/xwiki/bin/view/Applications/ImportExportApplication
10) I see really strange reaction from the system when a Space name (maybe even regular documents) contain a dot at the end. If that is an issue why is the application no displaying a warning or error when that happens (see my issue with the Trail).
Dots are not allowed in document names, since the dot separates the space from the document (as in Space.Document). We strip dots from most document creation forms that come with the default XE. If you know of such a form that doesn't strip points, please report it.
I think that is bugging me the most right now. I still like XWiki the most so far and would be disappointed if I could not use it. I also would be willing to help dealing with the JBoss classloading issue if I can get the build to compile.
I really hope that these problems can be clarified/solved and have you as a user. We're willing to work with you to solve these issues. As an open source project, we are always listening to the community and try to solve the problems encountered. As a company, we can offer you a support contract to have these issues fixed with a higher priority, or even give the administration burden to one of our admins. See http://www.xwiki.com/ for more details. -- Sergiu Dumitriu http://purl.org/net/sergiu/
Hi Sergiu First I want to thank you for answering all my question. It for sure made me feel much better and confident to keep on working on XWiki.
Andreas Schaefer wrote:
I tried for a few weeks to make XWiki work for me and even though it worked out well in the beginning I will not go into production with it. These are the issues I had to deal with it:
1) Renaming Pages and Spaces leave the wiki somewhat in limbo because the references are not working anymore. Copying around the pages seems to do the trick but I leaves a lingering bad feeling.
For Example I can rename the Web Home of a Space but then the Space because empty (? at the end). I cannot rename the WebHome because the new Space already has that Document and then I need to manually copy each document one by one.
http://code.xwiki.org/xwiki/bin/view/Snippets/RenameSpaceSnippet (linked from http://platform.xwiki.org/xwiki/bin/view/Features/Spaces)
I guess a problem is that it is not clear enough that spaces are not real, there is no "Space" entity. A space is just a common prefix for documents. As long as there are documents with a given space, that space exists. A special case is the WebHome document, which is considered to be the homepage of the space. So renaming the WebHome of a space causes the space to still exist, but it's index does not exist anymore.
Well, that explains a lot. Finally I start to understand what is going on.
2) Upgrade to a new minor release is a nightmare. Even though the WAR file can be easily replaced and seems to work fine the upgrading of documents is a blind flight because there is no list that tells me what should be imported and not.
http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Installation#HUpgradingw...
It is generally a good idea not to modify default documents, except Main.WebHome. This way, upgrading the XAR is as simple as uploading it, unselecting 4 documents (Main.WebHome, XWiki.XWikiPreferences, XWiki.XWikiAllGroup and XWiki.AdminGroup), and importing the rest of the documents.
Thanks. I will try this out later.
XWiki should now which documents where edited and so should be able to give a hint if they were changes before importing them. I would also like a way to create a diff of the existing file and the one I like to import.
Yes, this is a planned improvement, but since upgrades are not such a frequent operation, other issues have been given priority.
That is probably true but it is a crucial one when deciding if XWiki is being adopted. I checked out the Wiki but the documentation was not consistent and I could not upgrade w/o losing some changes even though this was minor stuff.
3) I cannot make XWiki work on JBoss without messing around with Classloader settings. This is a no-go because I cannot afford to make existing applications fail.
Well, since XWiki works fine with Tomcat and Jetty, without any classpath changes, then I'd say the fault is also partially on the JBoss side. Still, we're willing to solve as much as we can on our side. Can you please create bug reports on jira.xwiki.org ?
Of course you can say that but I have already a JBoss server running and having another JVMs running for tomcat/jetty instances might not work out even though lately I hardly see much value in using JBoss except that I have in-depth knowledge making debugging easier. On the other hand the line in questions where XWiki.java starts to load the Hibernate instance and therefore the underlying datasource is loaded using "Class.forName()" which should not be used inside a JavaEE/J2EE environment. The reason why this is failing is because the JNDI context used by JBoss relies on the class loader to find the bound Datasource. I am not quite sure why this works with Tomcat/Jetty but maybe they don't have local/private JNDI namespaces which are are located by the class loader. Therefore I don't think it is a JBoss problem. Other applications like Blojsom are using Datasources and Hibernate as well as there it work without issues.
4) I cannot build the current XWiki code (from SVN) because the XWikiDocument in the Core is messed up. I also have no idea how I can get the code of an existing release (no docu). This means I cannot figure out if I try to fix the classloading. This is the compiler error:
Did you try updating the code? The build works fine for all the developers, and it also works on our automatic build server (http://hudson.xwiki.org/job/xwiki-platform-core/ shows one failed build during the last 10 builds). If you're trying to build just a snapshot module from old sources, the newer versions of the dependencies are downloaded from the web, coming with a changed API.
Yes, I updated the code quite often. The reason of the failure shifted because of that. I will try again.
/Users/schaefa/Development/xwiki/trunks/core/xwiki-core/src/main/ java/ com/xpn/xwiki/doc/XWikiDocument.java:[3273,15] cannot find symbol symbol : method getRenderedContent(java.lang.String,com.xpn.xwiki.XWikiContext) location: class com.xpn.xwiki.doc.XWikiDocument
UPDATE: as of tonight I fail now building the WYSIWYG component (Mac OS X 10.5.7, JDK 1.6, Maven 2.0.10):
I also get this error sometimes, but only when building it from inside the trunks folder, and only with Maven 2.1.0. Try building directly from the web/wysiwyg folder.
Building the web/wysiwyg alone works but then I have to build the rest of XWiki module by module. BTW where do I find the deployable WAR file (web/standard?)
Removing units with errors [ERROR] Errors in 'file:/Users/schaefa/Development/xwiki/trunks/ web/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/client/util/ Attachment.java'
4b) In the same direction I was not able to check out the source of my current released version.
Since XWiki is not just one project, but a stack consisting of a core platform, plugins, applications and a final product on top of it, the sources are distributed in several modules. I think http://dev.xwiki.org/xwiki/bin/view/Community/SourceRepository explains it pretty well.
The sources for released versions of the platform are at http://svn.xwiki.org/svnroot/xwiki/platform/core/tags/ , just select which one you want and "svn checkout" it. If you want the sources for just one module, we also have source jars generated during releases, for example: http://maven.xwiki.org/releases/com/xpn/xwiki/platform/xwiki-core/1.8.4/xwik... http://maven.xwiki.org/releases/org/xwiki/platform/xwiki-core-rendering-api/...
5) Handling of images is cumbersome. If I have a lot of images to be added to a page like a walkthrough then uploading the images is a hercules task. I would expect that I could add x number of files or mark a number of file before hitting upload or delete. This works in the JSPWiki. I also saw that with JIRA I can add an image directly from the clipboard into the web page. I am not a Web Expert and so I don't know how difficult that is.
Since 1.9M2 it is possible to upload more files in a request, using the attachment upload form in view mode. Using the WYSIWYG editors it is also possible to upload files directly when editing the document.
Great, I am looking forward to that.
6) I tried to keep the images in one document and reference them in the pages containing the text. But I can only use get the reference in the WYSIWYG editor when the images are in the same page. I expect that I can at least list all the image names from the entire space or from another document. Sometimes I need to reuse the images or I want to reuse the page without having to reupload all the images.
Did you read the documentation for the image macro? http://code.xwiki.org/xwiki/bin/view/Macros/ImageMacro lists the "document" parameter, which indicates the source document, so: {image:file.png|document=Main.Pictures} should insert the "file.png" image from the "Main.Pictures" document.
The new WYSIWYG editor, available for documents in the xwiki/2.0 syntax, which will be the default syntax starting with 1.9, also allows selecting images from other documents. Indeed, the old WYSIWYG editor did not have this functionality.
Cool. Yes, I read the documentation but I had a hard time to make it work because of the huge number of image I used the WYSIWYG editor to enter images and not the wiki.
7) The Trail is broken in my installation bringing up an error page even though the page is available. This is because I copied some pages around and the trail is now pointing to the old defunct space.
The rename function does not update the parent field yet (http://jira.xwiki.org/jira/browse/XWIKI-1082 ), so this is a known bug. Still, why do you rename things so often? Renaming should only happen once in a while, when you just realized that a page is wrongly named. Few people complained about Rename problems so far, although we are aware of such problems.
Well, I am still figuring out how XWiki works and so I do make mistakes in setting up the Wiki. In addition writing about a topic I don't have much experience with (iPhone Dev.) will lead to many changes and so I have to rename pages. Mostly I do not rename but copy pages because it is easier to remove Images than re-add them when I split a page. Is there a way to change the parent field because I still have pages where this is broken?
8) How can I delete a space
http://code.xwiki.org/xwiki/bin/view/Snippets/DeleteSpaceSnippet (linked from http://platform.xwiki.org/xwiki/bin/view/Features/Spaces)
Yes, that did work - thanks. It was a plunge because I was not quite sure where to go with the snippet but then I tried it in the sandbox and it worked.
9) In case I want to clean up my somewhat messy wiki and only export a given Space so that I can recreate the Wiki and then import only that given Space. Currently it seems I can only export everything and then only select the space I want to be imported. I would prefer to do it the other way around.
You can try using http://code.xwiki.org/xwiki/bin/view/Applications/ImportExportApplication
Will definitively look into that.
10) I see really strange reaction from the system when a Space name (maybe even regular documents) contain a dot at the end. If that is an issue why is the application no displaying a warning or error when that happens (see my issue with the Trail).
Dots are not allowed in document names, since the dot separates the space from the document (as in Space.Document). We strip dots from most document creation forms that come with the default XE. If you know of such a form that doesn't strip points, please report it.
Actually I had the dot in the Space name.
I think that is bugging me the most right now. I still like XWiki the most so far and would be disappointed if I could not use it. I also would be willing to help dealing with the JBoss classloading issue if I can get the build to compile.
I really hope that these problems can be clarified/solved and have you as a user. We're willing to work with you to solve these issues. As an open source project, we are always listening to the community and try to solve the problems encountered. As a company, we can offer you a support contract to have these issues fixed with a higher priority, or even give the administration burden to one of our admins. See http://www.xwiki.com/ for more details.
Well, my company does not make money from hosting Wikis etc. I intend to use a Wiki to document what I learned during coding as well as creating a Wiki for iPhone Development. Thanks for you help. -Andy
Hi Andreas, On May 25, 2009, at 8:16 AM, Andreas Schaefer wrote:
Hi Sergiu
First I want to thank you for answering all my question. It for sure made me feel much better and confident to keep on working on XWiki.
Andreas Schaefer wrote:
I tried for a few weeks to make XWiki work for me and even though it worked out well in the beginning I will not go into production with it. These are the issues I had to deal with it:
1) Renaming Pages and Spaces leave the wiki somewhat in limbo because the references are not working anymore. Copying around the pages seems to do the trick but I leaves a lingering bad feeling.
For Example I can rename the Web Home of a Space but then the Space because empty (? at the end). I cannot rename the WebHome because the new Space already has that Document and then I need to manually copy each document one by one.
http://code.xwiki.org/xwiki/bin/view/Snippets/RenameSpaceSnippet (linked from http://platform.xwiki.org/xwiki/bin/view/Features/ Spaces)
I guess a problem is that it is not clear enough that spaces are not real, there is no "Space" entity. A space is just a common prefix for documents. As long as there are documents with a given space, that space exists. A special case is the WebHome document, which is considered to be the homepage of the space. So renaming the WebHome of a space causes the space to still exist, but it's index does not exist anymore.
Well, that explains a lot. Finally I start to understand what is going on.
Just to let you know we have planned to introduce "real" Space entities in the future when we refactor the model layer of XWiki. http://dev.xwiki.org/xwiki/bin/view/Design/XWikiModel20
2) Upgrade to a new minor release is a nightmare. Even though the WAR file can be easily replaced and seems to work fine the upgrading of documents is a blind flight because there is no list that tells me what should be imported and not.
http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Installation#HUpgradingw...
It is generally a good idea not to modify default documents, except Main.WebHome. This way, upgrading the XAR is as simple as uploading it, unselecting 4 documents (Main.WebHome, XWiki.XWikiPreferences, XWiki.XWikiAllGroup and XWiki.AdminGroup), and importing the rest of the documents.
Thanks. I will try this out later.
Again we've identified upgrading apps as a pain and we're going to start working on an Application Manager in the 2.0 timeframe. Since it's a complex piece of code and we want to do it right it's probably going to take some time before it's usable (think end of the year IMO). See http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationManager
XWiki should now which documents where edited and so should be able to give a hint if they were changes before importing them. I would also like a way to create a diff of the existing file and the one I like to import.
Yes, this is a planned improvement, but since upgrades are not such a frequent operation, other issues have been given priority.
That is probably true but it is a crucial one when deciding if XWiki is being adopted. I checked out the Wiki but the documentation was not consistent and I could not upgrade w/o losing some changes even though this was minor stuff.
Yes. I started documenting application changes in past release notes but we've dropped this good habit. I think we should do it again, i.e. simply list the pages that have been modified, while waiting for the proper application manager.
3) I cannot make XWiki work on JBoss without messing around with Classloader settings. This is a no-go because I cannot afford to make existing applications fail.
Well, since XWiki works fine with Tomcat and Jetty, without any classpath changes, then I'd say the fault is also partially on the JBoss side. Still, we're willing to solve as much as we can on our side. Can you please create bug reports on jira.xwiki.org ?
Of course you can say that but I have already a JBoss server running and having another JVMs running for tomcat/jetty instances might not work out even though lately I hardly see much value in using JBoss except that I have in-depth knowledge making debugging easier.
On the other hand the line in questions where XWiki.java starts to load the Hibernate instance and therefore the underlying datasource is loaded using "Class.forName()" which should not be used inside a JavaEE/J2EE environment. The reason why this is failing is because the JNDI context used by JBoss relies on the class loader to find the bound Datasource. I am not quite sure why this works with Tomcat/Jetty but maybe they don't have local/private JNDI namespaces which are are located by the class loader. Therefore I don't think it is a JBoss problem. Other applications like Blojsom are using Datasources and Hibernate as well as there it work without issues.
yes we should probably use the context class loader instead: ClassLoader cl = Thread.currentThread().getContextClassLoader(); Can you create a jira issue for this?
4) I cannot build the current XWiki code (from SVN) because the XWikiDocument in the Core is messed up. I also have no idea how I can get the code of an existing release (no docu). This means I cannot figure out if I try to fix the classloading. This is the compiler error:
Did you try updating the code? The build works fine for all the developers, and it also works on our automatic build server (http://hudson.xwiki.org/job/xwiki-platform-core/ shows one failed build during the last 10 builds). If you're trying to build just a snapshot module from old sources, the newer versions of the dependencies are downloaded from the web, coming with a changed API.
Yes, I updated the code quite often. The reason of the failure shifted because of that. I will try again.
If you want something real stable you should use the 1.8 branches. If you want something slightly less stable but with new features you should use the 1.9 branch if you want cutting edge you should use trunk. Obviously trunk is the less stable even though it should almost always build fine (we rarely leave it unstable for more than a couple of minutes).
/Users/schaefa/Development/xwiki/trunks/core/xwiki-core/src/main/ java/ com/xpn/xwiki/doc/XWikiDocument.java:[3273,15] cannot find symbol symbol : method getRenderedContent(java.lang.String,com.xpn.xwiki.XWikiContext) location: class com.xpn.xwiki.doc.XWikiDocument
UPDATE: as of tonight I fail now building the WYSIWYG component (Mac OS X 10.5.7, JDK 1.6, Maven 2.0.10):
I also get this error sometimes, but only when building it from inside the trunks folder, and only with Maven 2.1.0. Try building directly from the web/wysiwyg folder.
Building the web/wysiwyg alone works but then I have to build the rest of XWiki module by module.
BTW where do I find the deployable WAR file (web/standard?)
yes: http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/standard/ [snip]
7) The Trail is broken in my installation bringing up an error page even though the page is available. This is because I copied some pages around and the trail is now pointing to the old defunct space.
The rename function does not update the parent field yet (http://jira.xwiki.org/jira/browse/XWIKI-1082 ), so this is a known bug. Still, why do you rename things so often? Renaming should only happen once in a while, when you just realized that a page is wrongly named. Few people complained about Rename problems so far, although we are aware of such problems.
Well, I am still figuring out how XWiki works and so I do make mistakes in setting up the Wiki. In addition writing about a topic I don't have much experience with (iPhone Dev.) will lead to many changes and so I have to rename pages. Mostly I do not rename but copy pages because it is easier to remove Images than re-add them when I split a page.
Is there a way to change the parent field because I still have pages where this is broken?
sure, you can either edit the page (wiki mode) and set the parent you can also do it programmatically using $doc.setParent(...); $doc.save()
8) How can I delete a space
http://code.xwiki.org/xwiki/bin/view/Snippets/DeleteSpaceSnippet (linked from http://platform.xwiki.org/xwiki/bin/view/Features/ Spaces)
Yes, that did work - thanks. It was a plunge because I was not quite sure where to go with the snippet but then I tried it in the sandbox and it worked.
9) In case I want to clean up my somewhat messy wiki and only export a given Space so that I can recreate the Wiki and then import only that given Space. Currently it seems I can only export everything and then only select the space I want to be imported. I would prefer to do it the other way around.
You can try using http://code.xwiki.org/xwiki/bin/view/Applications/ImportExportApplication
Will definitively look into that.
We want to move that into XE by default but we've just not done it yet.
10) I see really strange reaction from the system when a Space name (maybe even regular documents) contain a dot at the end. If that is an issue why is the application no displaying a warning or error when that happens (see my issue with the Trail).
Dots are not allowed in document names, since the dot separates the space from the document (as in Space.Document). We strip dots from most document creation forms that come with the default XE. If you know of such a form that doesn't strip points, please report it.
Actually I had the dot in the Space name.
I think that is bugging me the most right now. I still like XWiki the most so far and would be disappointed if I could not use it. I also would be willing to help dealing with the JBoss classloading issue if I can get the build to compile.
I really hope that these problems can be clarified/solved and have you as a user. We're willing to work with you to solve these issues. As an open source project, we are always listening to the community and try to solve the problems encountered. As a company, we can offer you a support contract to have these issues fixed with a higher priority, or even give the administration burden to one of our admins. See http://www.xwiki.com/ for more details.
Well, my company does not make money from hosting Wikis etc. I intend to use a Wiki to document what I learned during coding as well as creating a Wiki for iPhone Development.
Thanks for you help.
Thanks -Vincent
Hi,
Building the web/wysiwyg alone works but then I have to build the rest
of XWiki module by module.
BTW where do I find the deployable WAR file (web/standard?)
May be this is what you want: http://maven.xwiki.org/releases/com/xpn/xwiki/products/xwiki-enterprise-web/ http://maven.xwiki.org/releases/ <-- official releases of various xwiki modules and products http://maven.xwiki.org/snapshots/ <-- snapshots of same, updated by hudson automatically (latest builds). Thanks. - Asiri
Hi Vincent Thanks for your help. Looking into the JBoss class loading issue it turned out that there is nothing wrong with class loading (at least not in the first place). Looking up the java:/jdbc/XWikiDS fails to return an object but not to find one. I think that is because something is wrong with finding JBoss wrapper classes and inside a class cast exception is thrown (or something alike) and the lookup is just return NULL. End-Result is that I finally had enough using JBoss to host web application and ditch it for Jetty. It took me 3 hours to make the switch including testing and installing on the server. Now the problems should be gone. If you want I can still issue a JIRA bug report but I am not going to waste anymore time on it.
Well, that explains a lot. Finally I start to understand what is going on.
Just to let you know we have planned to introduce "real" Space entities in the future when we refactor the model layer of XWiki. http://dev.xwiki.org/xwiki/bin/view/Design/XWikiModel20
I think that is a great idea.
Thanks. I will try this out later.
Again we've identified upgrading apps as a pain and we're going to start working on an Application Manager in the 2.0 timeframe. Since it's a complex piece of code and we want to do it right it's probably going to take some time before it's usable (think end of the year IMO). See http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationManager
Sweet.
That is probably true but it is a crucial one when deciding if XWiki is being adopted. I checked out the Wiki but the documentation was not consistent and I could not upgrade w/o losing some changes even though this was minor stuff.
Yes. I started documenting application changes in past release notes but we've dropped this good habit. I think we should do it again, i.e. simply list the pages that have been modified, while waiting for the proper application manager.
Couldn't the XAR file has an indicator if the content has changed?
3) I cannot make XWiki work on JBoss without messing around with Classloader settings. This is a no-go because I cannot afford to make existing applications fail.
Well, since XWiki works fine with Tomcat and Jetty, without any classpath changes, then I'd say the fault is also partially on the JBoss side. Still, we're willing to solve as much as we can on our side. Can you please create bug reports on jira.xwiki.org ?
Of course you can say that but I have already a JBoss server running and having another JVMs running for tomcat/jetty instances might not work out even though lately I hardly see much value in using JBoss except that I have in-depth knowledge making debugging easier.
On the other hand the line in questions where XWiki.java starts to load the Hibernate instance and therefore the underlying datasource is loaded using "Class.forName()" which should not be used inside a JavaEE/J2EE environment. The reason why this is failing is because the JNDI context used by JBoss relies on the class loader to find the bound Datasource. I am not quite sure why this works with Tomcat/ Jetty but maybe they don't have local/private JNDI namespaces which are are located by the class loader. Therefore I don't think it is a JBoss problem. Other applications like Blojsom are using Datasources and Hibernate as well as there it work without issues.
yes we should probably use the context class loader instead: ClassLoader cl = Thread.currentThread().getContextClassLoader();
As said above it turned out not to be the class loader. Both, the class' class loader and the Thread Content CL are the same (WebAppClassLoader). I think this is a problem way inside the JBoss JNDI handling which has it's problem and is really old (still from Richard Oeberg).
Can you create a jira issue for this?
I can if you still want to pursue it. I fixed it once and for all.
Is there a way to change the parent field because I still have pages where this is broken?
sure, you can either edit the page (wiki mode) and set the parent you can also do it programmatically using $doc.setParent(...); $doc.save()
I will try it right away. Cheers - Andy
Hi Andreas, On Tue, May 26, 2009 at 7:22 AM, Andreas Schaefer <[email protected]> wrote:
Hi Vincent
Thanks for your help. Looking into the JBoss class loading issue it turned out that there is nothing wrong with class loading (at least not in the first place). Looking up the java:/jdbc/XWikiDS fails to return an object but not to find one. I think that is because something is wrong with finding JBoss wrapper classes and inside a class cast exception is thrown (or something alike) and the lookup is just return NULL.
End-Result is that I finally had enough using JBoss to host web application and ditch it for Jetty. It took me 3 hours to make the switch including testing and installing on the server. Now the problems should be gone.
If you want I can still issue a JIRA bug report but I am not going to waste anymore time on it.
:-)
Well, that explains a lot. Finally I start to understand what is going on.
Just to let you know we have planned to introduce "real" Space entities in the future when we refactor the model layer of XWiki. http://dev.xwiki.org/xwiki/bin/view/Design/XWikiModel20
I think that is a great idea.
Thanks. I will try this out later.
Again we've identified upgrading apps as a pain and we're going to start working on an Application Manager in the 2.0 timeframe. Since it's a complex piece of code and we want to do it right it's probably going to take some time before it's usable (think end of the year IMO). See http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationManager
Sweet.
That is probably true but it is a crucial one when deciding if XWiki is being adopted. I checked out the Wiki but the documentation was not consistent and I could not upgrade w/o losing some changes even though this was minor stuff.
Yes. I started documenting application changes in past release notes but we've dropped this good habit. I think we should do it again, i.e. simply list the pages that have been modified, while waiting for the proper application manager.
Couldn't the XAR file has an indicator if the content has changed?
It could, and with the application manager it's gonna be **much** better. In the meanwhile, I think a small improvement would be to change the default import setting so that importing pages that already exist adds a new version of the page instead of completely overwriting it. It won't be perfect, but at least getting your "lost" pages back will be much easier. I'll keep you informed as to whether this can be done quickly or not. Guillaume
3) I cannot make XWiki work on JBoss without messing around with
Classloader settings. This is a no-go because I cannot afford to make existing applications fail.
Well, since XWiki works fine with Tomcat and Jetty, without any classpath changes, then I'd say the fault is also partially on the JBoss side. Still, we're willing to solve as much as we can on our side. Can you please create bug reports on jira.xwiki.org ?
Of course you can say that but I have already a JBoss server running and having another JVMs running for tomcat/jetty instances might not work out even though lately I hardly see much value in using JBoss except that I have in-depth knowledge making debugging easier.
On the other hand the line in questions where XWiki.java starts to load the Hibernate instance and therefore the underlying datasource is loaded using "Class.forName()" which should not be used inside a JavaEE/J2EE environment. The reason why this is failing is because the JNDI context used by JBoss relies on the class loader to find the bound Datasource. I am not quite sure why this works with Tomcat/ Jetty but maybe they don't have local/private JNDI namespaces which are are located by the class loader. Therefore I don't think it is a JBoss problem. Other applications like Blojsom are using Datasources and Hibernate as well as there it work without issues.
yes we should probably use the context class loader instead: ClassLoader cl = Thread.currentThread().getContextClassLoader();
As said above it turned out not to be the class loader. Both, the class' class loader and the Thread Content CL are the same (WebAppClassLoader). I think this is a problem way inside the JBoss JNDI handling which has it's problem and is really old (still from Richard Oeberg).
Can you create a jira issue for this?
I can if you still want to pursue it. I fixed it once and for all.
Is there a way to change the parent field because I still have pages where this is broken?
sure, you can either edit the page (wiki mode) and set the parent you can also do it programmatically using $doc.setParent(...); $doc.save()
I will try it right away.
Cheers - Andy _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://guillaumelerouge.com/
Hi Andreas,
UPDATE: as of tonight I fail now building the WYSIWYG component (Mac OS X 10.5.7, JDK 1.6, Maven 2.0.10): I also get this error sometimes, but only when building it from inside the trunks folder, and only with Maven 2.1.0. Try building directly from the web/wysiwyg folder.
Building the web/wysiwyg alone works but then I have to build the rest of XWiki module by module.
Why are you trying to build the WYSIWYG? It is time consuming (no less than 3 minutes on a powerful machine) and Hudson ( http://hudson.xwiki.org ) does this for you. Don't build everything unless you really need to, which I doubt. Build only the module you change and the modules that use it. In some cases you can even skip re-building the modules that use it by dropping the jar in the right place, like WEB-INF/lib. For instance, if you do a small change in xwiki-core then you can just copy the xwiki-core-2.0-SNAPSHOT.jar from the target directory to WEB-INF/lib (taking care to remove the exiting jar) and restart you web server.
BTW where do I find the deployable WAR file (web/standard?)
http://maven.xwiki.org/snapshots/com/xpn/xwiki/platform/xwiki-web-standard/ http://maven.xwiki.org/releases/com/xpn/xwiki/platform/xwiki-web-standard/ Hope this helps, Marius
On May 25, 2009, at 9:35 AM, Marius Dumitru Florea wrote:
Hi Andreas,
UPDATE: as of tonight I fail now building the WYSIWYG component (Mac OS X 10.5.7, JDK 1.6, Maven 2.0.10): I also get this error sometimes, but only when building it from inside the trunks folder, and only with Maven 2.1.0. Try building directly from the web/wysiwyg folder.
Building the web/wysiwyg alone works but then I have to build the rest of XWiki module by module.
Why are you trying to build the WYSIWYG? It is time consuming (no less than 3 minutes on a powerful machine) and Hudson ( http://hudson.xwiki.org ) does this for you. Don't build everything unless you really need to, which I doubt. Build only the module you change and the modules that use it. In some cases you can even skip re-building the modules that use it by dropping the jar in the right place, like WEB-INF/lib. For instance, if you do a small change in xwiki-core then you can just copy the xwiki-core-2.0-SNAPSHOT.jar from the target directory to WEB-INF/lib (taking care to remove the exiting jar) and restart you web server.
Note this is also explained on http://dev.xwiki.org/xwiki/bin/view/Community/Building -Vincent
BTW where do I find the deployable WAR file (web/standard?)
http://maven.xwiki.org/snapshots/com/xpn/xwiki/platform/xwiki-web-standard/ http://maven.xwiki.org/releases/com/xpn/xwiki/platform/xwiki-web-standard/
Hope this helps, Marius
Why didn't I think earlier about this. Anyhow I had to build it once (or at least the web/standard. Thanks it is working now nicely. Andreas Schaefer CEO of Madplanet.com Inc. Email: [email protected] [email protected] Twitter; andy_mpc AIM: [email protected] On May 25, 2009, at 12:35 AM, Marius Dumitru Florea wrote:
Hi Andreas,
UPDATE: as of tonight I fail now building the WYSIWYG component (Mac OS X 10.5.7, JDK 1.6, Maven 2.0.10): I also get this error sometimes, but only when building it from inside the trunks folder, and only with Maven 2.1.0. Try building directly from the web/wysiwyg folder.
Building the web/wysiwyg alone works but then I have to build the rest of XWiki module by module.
Why are you trying to build the WYSIWYG? It is time consuming (no less than 3 minutes on a powerful machine) and Hudson ( http://hudson.xwiki.org ) does this for you. Don't build everything unless you really need to, which I doubt. Build only the module you change and the modules that use it. In some cases you can even skip re-building the modules that use it by dropping the jar in the right place, like WEB-INF/lib. For instance, if you do a small change in xwiki-core then you can just copy the xwiki-core-2.0-SNAPSHOT.jar from the target directory to WEB-INF/lib (taking care to remove the exiting jar) and restart you web server.
BTW where do I find the deployable WAR file (web/standard?)
http://maven.xwiki.org/snapshots/com/xpn/xwiki/platform/xwiki-web-standard/ http://maven.xwiki.org/releases/com/xpn/xwiki/platform/xwiki-web-standard/
Hope this helps, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (6)
-
Andreas Schaefer -
Asiri Rathnayake -
Guillaume Lerouge -
Marius Dumitru Florea -
Sergiu Dumitriu -
Vincent Massol