Given that we’re now resorting to class loader trickery as a workaround, wouldn’t it actually make more sense to use the specification which solves this properly? The object in question is already a DS component, so requiring a service is about as low effort as possible, and there must be a suitably packaged DocumentBuilder implementation somewhere in Karaf?
Tim > On 27 Mar 2018, at 17:53, Kerry <karaf-u...@avionicengineers.com> wrote: > > I'm a bit puzzled why it works with a Karaf command as this will be executed > with a differing classloader but as I don't have your code it's hard for me > to visualise your imports etc correctly. > > I would temporarily change the classloader to that of a class that is in your > bundle, typically I would make it that of the class which is the entry point > from the 'outside world' into your bundle. Don't forget to reset the > classloader before the thread leaves your bundle and do this inside a finally > clause. > > Kerry > > On 27/03/18 22:16, Nicolas Brasey wrote: >> Ideally I would like to avoid overloading too much from the vanilla karaf to >> avoid too much dependencies to ease the future karaf version upgrades, but >> since I'm blocked at the moment I can give it a try. The best for me would >> be to find a nasty workaround with the classloader just to make it work. >> Which classloader can I set on the current thread to make this work? >> >> Thanks a lot Guillaume for your help! >> >> Cheers, >> Nicolas >> >> >> >> On Tue, Mar 27, 2018 at 8:09 PM, Guillaume Nodet <gno...@apache.org >> <mailto:gno...@apache.org>> wrote: >> You're right, I think the current setup on 4.1 is not optimal and a bit too >> sensitive to the thread context class loader. >> Can you simply remove the xalan and xerces jars from the lib/endorsed folder >> and the corresponding export packages in etc/config.properties ? >> If you want to use xalan and xerces, deploy them as bundles instead. >> Also, please raise a JIRA so that we can fix that. >> >> 2018-03-27 18:35 GMT+02:00 Nicolas Brasey <nicolas.bra...@gmail.com >> <mailto:nicolas.bra...@gmail.com>>: >> Yes that was also my understanding and this is what I'm doing. Like I said >> before, it works well from the karaf command but not when the call is >> initiated from somewhere else. >> >> >> >> On Tue, Mar 27, 2018 at 6:21 PM, Guillaume Nodet <gno...@apache.org >> <mailto:gno...@apache.org>> wrote: >> In Karaf, we ensure that you can use DocumentBuilderFactory#newInstance(). >> That's the standard java api to create a Parser and it works well in Karaf. >> >> 2018-03-27 18:11 GMT+02:00 Nicolas Brasey <nicolas.bra...@gmail.com >> <mailto:nicolas.bra...@gmail.com>>: >> Hi Guillaume, >> >> Thanks for those infos. I'm running Karaf 4.1.2. So I tried to lookup a >> DocumentBuilderFactory service but no one are availably in standard in this >> karaf version. >> >> What do you exactly mean by "it should already work" ? If it can help, I >> actually based my implementation on the example I found in Karaf, in the Kar >> service implementation, the class FeatureDetector. It is parsing an XML >> feature file, which is exactly what I'm trying to do as well. My >> implementation is 1 to 1. >> >> So the code seems perfectly working when a karaf command is calling it, but >> badly failing when coming from a jetty thread (REST endpoint). >> >> I would be happy to get away with a nasty workaround, I'm not looking by a >> by-the-book implementation :-) >> >> Thanks again! >> Nicolas >> >> >> >> >> >> >> >> On Tue, Mar 27, 2018 at 5:02 PM, Guillaume Nodet <gno...@apache.org >> <mailto:gno...@apache.org>> wrote: >> Here's the way to solve the problem for Karaf 4.2, hopefully I can merge it >> before the release is done: >> https://github.com/apache/karaf/pull/481 >> <https://github.com/apache/karaf/pull/481> >> >> For 4.1, the distribution should already work. >> >> The OSGi 133 (Service Loader) and 702 (XML Parser) are clearly not >> sufficient when working with libraries that have not been built solely for >> OSGi and which use the standard way to use the XML apis. >> >> Fwiw, the openjdk code contains code specific to glassfish osgi environment, >> in a similar way than the above PR. >> >> >> 2018-03-27 16:57 GMT+02:00 Nicolas Brasey <nicolas.bra...@gmail.com >> <mailto:nicolas.bra...@gmail.com>>: >> Hi Kerry, >> >> Yes it executes in another thread (jetty http executor thread pool), so the >> context is different. >> >> The code actually fails quite deep in the abyss of the java service loader: >> >> >> Caused by: java.util.ServiceConfigurationError: >> javax.xml.parsers.DocumentBuilderFactory: Provider >> org.apache.xerces.jaxp.DocumentBuilderFactoryImpl not found >> at java.util.ServiceLoader.fail(ServiceLoader.java:239) ~[?:?] >> >> >> I should switch the current thread classloader to use the classloader of the >> class java.util.ServiceLoader? >> >> Thanks!! >> Nicolas >> >> >> >> On Tue, Mar 27, 2018 at 3:38 PM, Kerry <karaf-u...@avionicengineers.com >> <mailto:karaf-u...@avionicengineers.com>> wrote: >> Hazarding a guess at this but when it fails when called by the camel route >> it will be executing on a different thread when then when executed by karaf >> command. You could try and confirm this by surrounding the code that is >> failing with a thread context switch so that it switches to the context of >> the class that has the failing code. >> >> Kerry >> >> Sent from BlueMail <http://www.bluemail.me/r?b=12512> >> On 27 Mar 2018, at 14:17, Nicolas Brasey <nicolas.bra...@gmail.com >> <mailto:nicolas.bra...@gmail.com>> wrote: >> Hi, >> >> I'm feeling frustrated because like everytime I'm adventuring with XML in an >> OSGi context, I end up with classloading issues, and this time is no >> exception :-) So I would like to know what/how you guys are doing it... >> >> My use case is extremely simple, yet I can't figure out what I'm doing >> wrong. I need to use an XML parser to get a Document object from an XML >> file. This XML parsing code is embedded inside a service (DS). The weird >> thing is that If I invoke this service with a karaf command, then it works >> fine. If the same code is invoked through a REST endpoint (another bundle), >> then I get the following class not found: >> >> Caused by: java.util.ServiceConfigurationError: >> javax.xml.parsers.DocumentBuilderFactory: Provider >> org.apache.xerces.jaxp.DocumentBuilderFactoryImpl not found >> at java.util.ServiceLoader.fail(ServiceLoader.java:239) ~[?:?] >> at java.util.ServiceLoader.access$300(ServiceLoader.java:185) ~[?:?] >> at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:372) >> ~[?:?] >> >> >> AFAIK, Karaf is pulling the servicemix implementation of Xerces, and I >> doubled check that the package is available in karaf: >> >> >> dms@root>exports | grep org.apache.xerces.jaxp >> org.apache.xerces.jaxp.datatype >> │ 2.11.0 │ 348 │ >> org.apache.servicemix.bundles.xerces >> org.apache.xerces.jaxp.validation >> │ 2.11.0 │ 348 │ >> org.apache.servicemix.bundles.xerces >> org.apache.xerces.jaxp >> │ 2.11.0 │ 348 │ >> org.apache.servicemix.bundles.xerces >> >> >> >> So, I don't know what I'm doing wrong here. >> >> Any clue ? >> >> >> Thanks, >> Nicolas >> >> >> >> >> >> -- >> ------------------------ >> Guillaume Nodet >> >> >> >> >> >> -- >> ------------------------ >> Guillaume Nodet >> >> >> >> >> >> -- >> ------------------------ >> Guillaume Nodet >> >> >
