Hi Zachary, if you write a pojo webservice the mapping is taken from the web.xml (define a servlet using the webservice class). Configuration you mention if for EJB webservices only.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2017-06-05 22:32 GMT+02:00 Zachary Bedell <[email protected]>: > 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 > >
