When wsgen is called by the Glassfish deployer, it is apparently not being fed
the complete classpath of all component JARs in an EAR. Further, the deployer
that calls wsgen does not seem to respect the component JAR's manifest classpath.
Take an EAR with the following structure:
Because soap.jar and core.jar are components of an EAR, they should be able to
see each others' classes, being in the same application classpath. But when
wsgen is called on soap.jar, and soap.jar somehow depends on core.jar classes
(in my case, the SEI-implementing class has an @Interceptors entry that
references an interceptor class in core.jar), wsgen fails with a
TypeNotPresentExceptionProxy exception. This also occurs even if core.jar is
explicitly listed in soap.jar's manifest classpath.
This must be an issue, as far as I can tell, with how the Glassfish deployer
feeds wsgen classpath information. Running the standalone wsgen utility in
Glassfish's bin directory correctly processes the JARs, both in the case where
the two JARs are manually listed in wsgen's classpath, and when only soap.jar is
listed in wsgen's classpath, and soap.jar references core.jar in the manifest