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:
Tks ... for now I will use the first option