JAX-WS always mapped to root of WAR

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

JAX-WS always mapped to root of WAR

zbedell
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 (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: JAX-WS always mapped to root of WAR

Romain Manni-Bucau
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 <[hidden email]>:

> 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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: JAX-WS always mapped to root of WAR

zbedell
Is it the WAR or the EJB-ness that triggers that?  IE, if I put the POJO's in the ejb-jar instead, would they honor the prefix, or would I also have to put an EJB annotation like @Singleton on them?

I remember finding somewhere a way to affect that mapping on a per ejb-jar basis.  I'd need to set the mapping in such a way that it would overlap actual WAR files in some cases as there are a few places where other web stuff is mounted at /warurl/ and webservices are expected at /warurl/services/.  Do you know if it would cause trouble for webservices in an ejb-jar deployment to claim part of what was otherwise claimed by a WAR?

I'm trying to decide if it will be easier to treat them as EJB's and move them into ejb-jars or split them into their own WAR files and map those in application.xml accordingly.

Thanks,
Zac

> On Jun 5, 2017, at 16:39, Romain Manni-Bucau <[hidden email]> wrote:
>
> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Frmannibucau&data=01%7C01%7Czbedell%40nycourts.gov%7Ce4b947638f164f8d4c5c08d4ac5379b4%7C3456fe92cbd1406db5a35364bec0a833%7C1&sdata=bq%2FeKosy%2FvrD6DYHjxe%2FqhZX%2B5tnPusXjxTjrLE5YiA%3D&reserved=0> |  Blog
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog-rmannibucau.rhcloud.com&data=01%7C01%7Czbedell%40nycourts.gov%7Ce4b947638f164f8d4c5c08d4ac5379b4%7C3456fe92cbd1406db5a35364bec0a833%7C1&sdata=%2FRirXPXUXZ7iYFMXpv5JSMULFZAefc0Na9TX3ghX14U%3D&reserved=0> | Old Blog
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Frmannibucau.wordpress.com&data=01%7C01%7Czbedell%40nycourts.gov%7Ce4b947638f164f8d4c5c08d4ac5379b4%7C3456fe92cbd1406db5a35364bec0a833%7C1&sdata=fG%2FVf2NSwYWNMt%2Bu2GcTNn%2FLtkUn6wKDtK2WISKYFhk%3D&reserved=0> | Github <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frmannibucau&data=01%7C01%7Czbedell%40nycourts.gov%7Ce4b947638f164f8d4c5c08d4ac5379b4%7C3456fe92cbd1406db5a35364bec0a833%7C1&sdata=iuZOsmkNIE%2BnAB6Zw%2BbvyNv5TpwcpR3OclzjUBSSmX4%3D&reserved=0> |
> LinkedIn <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Frmannibucau&data=01%7C01%7Czbedell%40nycourts.gov%7Ce4b947638f164f8d4c5c08d4ac5379b4%7C3456fe92cbd1406db5a35364bec0a833%7C1&sdata=BvUxtvHPc3QwNp3BfRVrJwLy0S3uByFlgkANs57kJtc%3D&reserved=0> | JavaEE Factory
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjavaeefactory-rmannibucau.rhcloud.com&data=01%7C01%7Czbedell%40nycourts.gov%7Ce4b947638f164f8d4c5c08d4ac5379b4%7C3456fe92cbd1406db5a35364bec0a833%7C1&sdata=bBF6yqYbm8xH95%2B5AiyBwt9kEehn1dblaWa1vIEiEd4%3D&reserved=0>
>
> 2017-06-05 22:32 GMT+02:00 Zachary Bedell <[hidden email]>:
>
>> 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 (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: JAX-WS always mapped to root of WAR

Romain Manni-Bucau
IIRC you would need to make them EJB in lib part of the ear. EJB can be
mapped in openejb-jar.xml (see
https://github.com/apache/tomee/tree/master/examples/change-jaxws-url)

Now the overlapping part can be worrying and I wonder if you shouldn't just
map them in web.xml in the related war or use a servlet filter doing the
"redirection" (more a mapping through the filter than a real redirection).

Side note: in any case if you are free to map the packaging on the
deployment you shouldn't hesitate one sec between that and a lot of config
you can find hard to maintain later on.



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:52 GMT+02:00 Zachary Bedell <[hidden email]>:

> Is it the WAR or the EJB-ness that triggers that?  IE, if I put the POJO's
> in the ejb-jar instead, would they honor the prefix, or would I also have
> to put an EJB annotation like @Singleton on them?
>
> I remember finding somewhere a way to affect that mapping on a per ejb-jar
> basis.  I'd need to set the mapping in such a way that it would overlap
> actual WAR files in some cases as there are a few places where other web
> stuff is mounted at /warurl/ and webservices are expected at
> /warurl/services/.  Do you know if it would cause trouble for webservices
> in an ejb-jar deployment to claim part of what was otherwise claimed by a
> WAR?
>
> I'm trying to decide if it will be easier to treat them as EJB's and move
> them into ejb-jars or split them into their own WAR files and map those in
> application.xml accordingly.
>
> Thanks,
> Zac
>
> > On Jun 5, 2017, at 16:39, Romain Manni-Bucau <[hidden email]>
> wrote:
> >
> > 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://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Ftwitter.com%2Frmannibucau&data=01%7C01%
> 7Czbedell%40nycourts.gov%7Ce4b947638f164f8d4c5c08d4ac5379b4%
> 7C3456fe92cbd1406db5a35364bec0a833%7C1&sdata=bq%2FeKosy%
> 2FvrD6DYHjxe%2FqhZX%2B5tnPusXjxTjrLE5YiA%3D&reserved=0> |  Blog
> > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog-
> rmannibucau.rhcloud.com&data=01%7C01%7Czbedell%40nycourts.gov%
> 7Ce4b947638f164f8d4c5c08d4ac5379b4%7C3456fe92cbd1406db5a35364bec0
> a833%7C1&sdata=%2FRirXPXUXZ7iYFMXpv5JSMULFZAefc0Na9TX3ghX14U%3D&reserved=0>
> | Old Blog
> > <https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Frmannibucau.wordpress.com&data=01%7C01%
> 7Czbedell%40nycourts.gov%7Ce4b947638f164f8d4c5c08d4ac5379b4%
> 7C3456fe92cbd1406db5a35364bec0a833%7C1&sdata=fG%2FVf2NSwYWNMt%2Bu2GcTNn%
> 2FLtkUn6wKDtK2WISKYFhk%3D&reserved=0> | Github <https://na01.safelinks.
> protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
> 2Frmannibucau&data=01%7C01%7Czbedell%40nycourts.gov%
> 7Ce4b947638f164f8d4c5c08d4ac5379b4%7C3456fe92cbd1406db5a35364bec0
> a833%7C1&sdata=iuZOsmkNIE%2BnAB6Zw%2BbvyNv5TpwcpR3OclzjUBSSmX4%
> 3D&reserved=0> |
> > LinkedIn <https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fwww.linkedin.com%2Fin%2Frmannibucau&data=
> 01%7C01%7Czbedell%40nycourts.gov%7Ce4b947638f164f8d4c5c08d4ac5379b4%
> 7C3456fe92cbd1406db5a35364bec0a833%7C1&sdata=
> BvUxtvHPc3QwNp3BfRVrJwLy0S3uByFlgkANs57kJtc%3D&reserved=0> | JavaEE
> Factory
> > <https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fjavaeefactory-rmannibucau.rhcloud.com&data=
> 01%7C01%7Czbedell%40nycourts.gov%7Ce4b947638f164f8d4c5c08d4ac5379b4%
> 7C3456fe92cbd1406db5a35364bec0a833%7C1&sdata=bBF6yqYbm8xH95%
> 2B5AiyBwt9kEehn1dblaWa1vIEiEd4%3D&reserved=0>
> >
> > 2017-06-05 22:32 GMT+02:00 Zachary Bedell <[hidden email]>:
> >
> >> 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
> >>
> >>
>
>