Issues 71-74 seem to point to a general disability in OneJar when the contained code is working with classloaders. This issue cites another case where classloading seems to have gone awry. It's particularly significant because jars that talk to web services are likely to be an relatively common use case.
I built a web service client (which talks to web services deployed on salesforce). This client is working and in production in a servlet environment, and is based on Axis 1.6.2. I then recently tried to use the same web service client as part of a command line tool to be packaged as a onejar. The attached stack trace results when I run the tool.
Tracking that down in the axis code I find:
which has this javadoc:
/** * Get the meta factory instance for the Axiom implementation with a given feature. If multiple * Axiom implementations declare the same feature, then the method will return the meta factory * for the implementation that declares the highest priority for that feature in its * <tt>META-INF/axiom.xml</tt> descriptor. * * @param feature * the requested feature * @return the meta factory instance for the Axiom implementation with the given feature. * @throws OMException * if no Axiom implementation with the requested feature could be located */
digging even deeper I find that this is ultimately loaded by an object constructed in org.apache.axiom.locator.DefaultOMMetaFactoryLocator#DefaultOMMetaFactoryLocator
ClassLoader classLoader = DefaultOMMetaFactoryLocator.class.getClassLoader(); Loader loader = new DefaultLoader(classLoader);
The axiom-impl.jar is included in the onejar, and it does contain META-INF/axiom.xml. Furthermore if I promote axiom.xml to a META-INF at the very top of the onejar (instead of the one inside the axiom-impl.jar, or main.jar) The file is now found and the code runs without error.