25 May
2009
25 May
'09
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.