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