24 May
2009
24 May
'09
7:21 p.m.
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: andreas.schaefer(a)madplanet.com
schaefera(a)me.com
Twitter; andy_mpc
AIM: schaefera(a)me.com
24 May
24 May
9:51 p.m.
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#HUpgrading…
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/xwi…
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/
25 May
25 May
8:16 a.m.
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.
Thanks. I will try this out later.
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.
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, I updated the code quite often. The reason of the failure shifted
because of that. I will try again.
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?)
Great, I am looking forward to that.
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.
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?
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.
Will definitively look into that.
Actually I had the dot in the Space name.
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
Andreas Schaefer wrote:
Well, that explains a lot. Finally I start to understand what is going
on.
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#HUpgrading…
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/xwi…
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. 
9:35 a.m.
Hi Andreas,
On May 25, 2009, at 8:16 AM, Andreas Schaefer wrote:
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
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.
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?
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).
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]
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()
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.
Will definitively look into that.
We want to move that into XE by default but we've just not done it yet.
Actually I had the dot in the Space name.
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 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.
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
Andreas Schaefer wrote:
Well, that explains a lot. Finally I start to understand what is going
on. 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#HUpgrading…
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. 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. 
10:07 a.m.
Hi,
Building the web/wysiwyg alone works but then I have
to build the rest
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
of XWiki module by module.
BTW where do I find the deployable WAR file (web/standard?)
26 May
26 May
7:22 a.m.
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.
I think that is a great idea.
Sweet.
Couldn't the XAR file has an indicator if the content has changed?
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).
I will try it right away.
Cheers - Andy
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 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 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 ? 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() 
9:41 a.m.
Hi Andreas,
On Tue, May 26, 2009 at 7:22 AM, Andreas Schaefer <schaefera(a)me.com> wrote:
I think that is a great idea.
Sweet.
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
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).
I will try it right away.
Cheers - Andy
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype ID : wikibc
http://guillaumelerouge.com/
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 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 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. 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() 
25 May
25 May
9:35 a.m.
Hi Andreas,
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.
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.
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
9:39 a.m.
On May 25, 2009, at 9:35 AM, Marius Dumitru Florea wrote:
Hi Andreas,
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
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. 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
26 May
26 May
7:10 a.m.
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: andreas.schaefer(a)madplanet.com
schaefera(a)me.com
Twitter; andy_mpc
AIM: schaefera(a)me.com
On May 25, 2009, at 12:35 AM, Marius Dumitru Florea wrote:
Hi Andreas,
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.
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.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5592
days inactive
5594
days old
9 comments
6 participants
participants (6)
-
Andreas Schaefer -
Asiri Rathnayake -
Guillaume Lerouge -
Marius Dumitru Florea -
Sergiu Dumitriu -
Vincent Massol