On May 22, 2009, at 4:54 PM, [email protected] wrote:
Hmmm sorry about that. For now, adding the do nothing constructor is
the way to go. Next week I will make the discover code a bit more
intelligent.
Thank you.
The discover code still has the nasy habit of trying to load classes
using the current thread's context class loader, however. This tends
to break plugin-based systems like Confluence, for example. In
Confluence, a separate class-loader is used to load plugin classes,
but the thread processing a request has a context class-loader who
does not know anything about classes loaded by child class-loaders.
In order to make my Abdera client code work inside a Confluence
plugin, I have to use tricks like the following:
AbderaClient client;
// Work around Abdera trying to be smart with class loading
ClassLoader originalClassLoader =
Thread.currentThread().getContextClassLoader();
try {
ClassLoader cl = this.getClass().getClassLoader();
Thread.currentThread().setContextClassLoader(cl);
Abdera abdera = new Abdera();
client = new AbderaClient(abdera);
// Do something with client
} finally {
// Restore original classloader
Thread.currentThread().setContextClassLoader(originalClassLoader);
}
I seem to remember that some time ago we added some code to let users
be able to set the class-loader used by the Abdera discovery
mechanism, but I can't find that code anymore.
Personally, I would be in favour of eliminating the whole discovery
mechanism and just use a set of XML/StAX components defined at compile
time and be done with it.
Ugo
