tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: JAX-WS always mapped to root of WAR
Date Mon, 05 Jun 2017 20:39:35 GMT
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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message