2 Replies Latest reply on Oct 20, 2009 2:07 PM by Daniel Filgueiras

    Problem using WebService from Agent

    Daniel Filgueiras Newbie

      I develop am plugin that must access an WebService, but an exception is throw:

      Caused by: javax.xml.ws.WebServiceException: Provider com.sun.xml.internal.ws.spi.ProviderImpl not found
       at javax.xml.ws.spi.FactoryFinder.newInstance(FactoryFinder.java:33)
       at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:128)
       at javax.xml.ws.spi.Provider.provider(Provider.java:83)
       at javax.xml.ws.Service.<init>(Service.java:56)
       at mobi.v2com.jopr.plugin.v2spy.remote.axa.WsConsultaService.<init>(WsConsultaService.java:42)
       ... 12 more
      Caused by: java.lang.ClassNotFoundException: com.sun.xml.internal.ws.spi.ProviderImpl
       at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
       at java.security.AccessController.doPrivileged(Native Method)
       at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
       at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
       at org.rhq.core.pc.plugin.PluginClassLoader.loadClass(PluginClassLoader.java:63)
       at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
       at javax.xml.ws.spi.FactoryFinder.safeLoadClass(FactoryFinder.java:150)
       at javax.xml.ws.spi.FactoryFinder.newInstance(FactoryFinder.java:30)
       ... 16 more

      Running my plugin directly, works fine (main function)

      I saw many post about this exception on the Web, but I think my problem is in Agent environment.

      The ProviderImpl is in rt.jar (jdk1.6.0_14), I checked.

      Why this exception is throw when running inside rhq-agent ?

        • 1. Re: Problem using WebService from Agent
          mazz Master

          This is due to the way the agent isolates all plugins' classloaders.

          When the agent starts the internal plugin container, it tells the PC what classes it should allow all plugins to have access to in their root plugin classloaders (if you recall, each plugin is assigned its own classloader, the parent of the plugin's classloader tree is called the "root plugin classloader").

          This is necessary to isolate the plugins in such a way that they don't step on each other or use classes from the agent's lib/ directory (which could cause problems if a plugin wants it own implementation of, say, JAXB - different from the agent's version of JAXB).

          The agent looks for a configuration preference called "rhq.agent.plugins.root-plugin-classloader-regex" that consists of a regular expression that matches classes that should be HIDDEN from all plugins. This essentially removes classes from the plugin classloaders.

          If the agent's preference isn't set, you can see where the agent sets up the default regex here in this class:


          ( see http://svn.rhq-project.org/repos/rhq/trunk/modules/enterprise/agent/src/main/java/org/rhq/enterprise/agent/AgentConfiguration.java )

          One of the regex pieces is this:


          So all com.sun.xml.* classes are hidden from all plugins. This is why your plugin can't see it.

          The purpose of this regex was to avoid plugins from picking up the agent's version of JAXB (whose impl is under com.sun.xml.*). Perhaps this was too aggressive and we needed to be more specific about which classes to hide?

          To get around this, you can override this and set that preference in the agent, making the regex hide whatever classes you want. You can take the default regex and remove or change it as you see fit.

          We should probably find out more about what you are trying to load in - unsure if the simpler solution would just be for you to include your version of the ws library you want in your plugin's /lib directory.

          For more information on plugin classloader stuff, see:


          • 2. Re: Problem using WebService from Agent
            Daniel Filgueiras Newbie

            Tks ... for now I will use the first option