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>: > 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> > wrote: > >> In Karaf, we ensure that you can use DocumentBuilderFactory#newInst >> ance(). >> 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>: >> >>> 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> >>> 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 >>>> >>>> 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>: >>>> >>>>> 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-user@avionicengineers.c >>>>> om> 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> >>>>>> 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
