For the main components the discovery mechanism is not critical. For the extension mechanism tho it provides valuable function. Selectively removing it would be fine I think. Sent from my Verizon Wireless BlackBerry
-----Original Message----- From: Ugo Cei <[email protected]> Date: Thu, 4 Jun 2009 10:57:00 To: <[email protected]> Subject: Re: Missing constructor in LRUCacheFactory? 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
