On Thu, Jan 28, 2010 at 1:16 PM, Bill Herring <[email protected]> wrote: > I'm developing an Eclipse plugin application and have Commons SCXML and > Digester in a plugin/bundle separate from my main project bundle. The > problem with this is that if I'm submitting a list of custom actions to > SCXMLParser.parse() the classloader that digester is using can't find the > custom action classes and throws an exception. The offending line is in > digester.ObjectCreateRule.begin(): > > Class<?> clazz = digester.getClassLoader().loadClass(realClassName); > > The docs for getClassLoader() indicate that I can use setClassLoader() to > use another class loader, which might solve my problem. However, I can't > find a simple way to invoke that function before SCXMLParser.parse() > generates the error. I can use SCXMLParser.getInstance() to get a digester > instance, and then I can call setClassLoader() and then invoke parse() on > the digester directly. Doing that, I have to set up the digester rules > manually before parsing, which appears doable but non-trivial... > <snip/>
Thats one way, if you choose that as a reminder there is a post digester parsing step that needs to be invoked in such scenarios (as mentioned in the Javadoc). > Is there a simpler way to coax the digester used in SCXMLParser.parse() to > employ a different class loader? > <snap/> Indirectly, by resolving this at the framework (OSGi) level. This is a classic example from a set of valid scenarios that are faced when using bundles that expect to see both application / client code as well as their own code (obviously). For such scenarios, its usually possible to use the Eclipse buddy class loading mechanisms. Look up the Eclipse-BuddyPolicy and Eclipse-RegisterBuddy manifest entries to see if that works for you. -Rahul > Thanks, > Bill > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
