26 May
2009
26 May
'09
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()