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 >> >> > > >
