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 <zbedell@nycourts.gov>:
> 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
>
>
|