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