Good afternoon, I'm using TomEE 7.0.3 with annotation based JAX-WS POJO webservices. It appears that the settings for both tomee.jaxws.subcontext and tomee.jaxws.oldsubcontext are ignored in my configuration. Webservices are always mapped to the root URL of the WAR that contains them, never with the default /webservices prefix nor with my desired value of /services as specified in tomee.jaxws.subcontext.
Doing a bit of debugging at startup, it appears those system properties would
be parsed in org.apache.tomee.webservices.TomcatWsRegistry in either the
addWsContainer() or addServlet() methods. As my instance starts up, those two
methods are never called (breakpoints never fire), and instead the
setWsContainer() method is called as each WAR that contains JAX-RS POJO's is
deployed. The stacktrace during initialization looks like below. The
setWsContainer() method doesn't read either the tomee.jaxws.subcontext or
tomee.jaxws.oldsubcontext methods.
I *think* my annotations to setup the webservices are pretty straight forward.
Interface & implementation class like:
@WebService(targetNamespace=AuthorizedDeviceV1001.NAMESPACE)
public interface AuthorizedDeviceV1001 {
public static final String NAME = "AuthorizedDeviceV1001";
public static final String NAMESPACE =
"http://X/xmltypes/authorized-device/V1001";;
//...
}
@WebService(
name = AuthorizedDeviceV1001.NAME,
serviceName = AuthorizedDeviceV1001.NAME,
targetNamespace = AuthorizedDeviceV1001.NAMESPACE,
endpointInterface = "ucs.common.authorizeddev.ws.AuthorizedDeviceV1001"
)
public class AuthorizedDeviceServiceV1001 implements AuthorizedDeviceV1001 {
//...
}
These two class files are in a WAR inside an EAR, listed in the EAR's
application.xml. I can't think of anything else out of the ordinary about the
packaging or server configuration. I'm able to confirm the values of
tomee.jaxws.subcontext and tomee.jaxws.oldsubcontext are both as expected by
dumping out system properties once the server is up. The webservices all work
fine once the server is up. They're just mounted at the wrong URL's. We're
trying to maintain wire-compatibility with an existing JBoss server we're
migrating from, so having these URL's change would complicate things a bit.
Does anyone have any ideas what would cause the server initialization process
to take this code path instead of the one that honors these two configuration
properties?
The stacktrace during deployment
Daemon Thread [localhost-startStop-1] (Suspended (breakpoint at line 100 in
TomcatWsRegistry))
owns: StandardContext (id=504)
TomcatWsRegistry.setWsContainer(HttpListener, ClassLoader, String,
String, ServletInfo, String, String, String, String) line: 100
CxfService(WsService).afterApplicationCreated(AppInfo, WebAppInfo)
line: 436
TomeeJaxWsService.afterApplicationCreated(AfterApplicationCreated)
line: 56
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not
available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43
Method.invoke(Object, Object...) line: 498
ObserverManager$MethodInvocation.invoke(Object) line: 406
ObserverManager$InvocationList.invoke(Object) line: 521
ObserverManager.doFire(E) line: 111
ObserverManager.fireEvent(E) line: 100
SystemInstance.fireEvent(E) line: 217
TomcatWebAppBuilder.afterStart(StandardContext) line: 1740
GlobalListenerSupport.lifecycleEvent(LifecycleEvent) line: 116
StandardContext(LifecycleBase).fireLifecycleEvent(String, Object) line:
94
StandardContext(LifecycleBase).setStateInternal(LifecycleState, Object,
boolean) line: 395
StandardContext(LifecycleBase).start() line: 160
ContainerBase$StartChild.call() line: 1419
ContainerBase$StartChild.call() line: 1409
FutureTask<V>.run() line: 266
ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1142
ThreadPoolExecutor$Worker.run() line: 617
Thread.run() line: 748
Best regards,
Zac Bedell
signature.asc
Description: Message signed with OpenPGP
