1 Reply Latest reply on Jul 9, 2013 4:46 AM by orotas

    CQ5 Sling OSGI XPath Problems

    CQdev416

      I was having a problem with XPATH libraries not loading correctly in CQ.

      I built an OSGI servlet to access an external database using MyBatis 3.2.2.

       

      If I access the servlet directly from its component path,

       

      @SlingServlet(paths="/bin/TestServlet", methods = "GET",extensions = {"html", "do"} )

       

      i.e., "/bin/TestServlet" then it runs fine without any errors.

       

      However if I export functions from the servlet and run then from a component (.JSP),

       

      com.test.Myservice myService = sling.getService(com.test.Myservice.class);

      myService.Foo();

       

      It will trigger an path exception:

       

      Caused by: java.lang.RuntimeException: XPathFactory#newInstance() failed to create an XPathFactory for the default object model: http://java.sun.com/jaxp/xpath/dom with the XPathFactoryConfigurationException: javax.xml.xpath.XPathFactoryConfigurationException: No XPathFactory implementation found for the object model: http://java.sun.com/jaxp/xpath/dom

       

      I have found a solution to this problem by editing the sling.properties config and adding:

       

      sling.system.packages.simple=com.sun.org.apache.xpath.internal.jaxp

       

      Which fixes the problem.

       

      My question is why does this problem not happen when directly accessing the servlet via:

       

      /bin/TestServlet

       

      I don't really understand what is going on here. Is there a difference between running by JSP or directly?

        • 1. Re: CQ5 Sling OSGI XPath Problems
          orotas Level 4

          I am not 100% sure but the most likely this is a class loader issue. The JSPs are executed using a different class loader than OSGI servlets. Depending on what else you may or may not have packaged up in your bundle with your servlet that means that the dependency in question may only be on your servlet's internal bundle class path and not the JSP's class path. For frameworks that allow multiple implementations like the JAXP stuff the factories will leverage the current thread's classpath to find the implementation. Adding the implementation to the sling system packages made it available to the class loader being used by the JSP thread.