So. switching the current thread classloader is fixing the issue. not nice but I can live with this...
@Guillaume: as you requested, I've created a jira about this problem: https://issues.apache.org/jira/browse/KARAF-5682 Thanks one more time everyone for your very helpful support! Best regards, Nicolas On Wed, Mar 28, 2018 at 8:28 AM, Nicolas Brasey <nicolas.bra...@gmail.com> wrote: > Hi Tim, > > I tried yesterday your proposal but unfortunately there > are no provider for DocumentBuilderFactory in karaf. > > Nicolas > > On Tue, Mar 27, 2018 at 11:57 PM, Tim Ward <tim.w...@paremus.com> wrote: > >> 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> >> 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>: >>> >>>> 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#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>: >>>>> >>>>>> 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-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> >>>>>>>>> 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 >>> >>> >> >> >> >
