You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Zachary Bedell <zb...@nycourts.gov> on 2017/06/05 20:32:59 UTC
JAX-WS always mapped to root of WAR
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
Re: JAX-WS always mapped to root of WAR
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <zb...@nycourts.gov>:
> 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 <rm...@gmail.com>
> 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 <zb...@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
> >>
> >>
>
>
Re: JAX-WS always mapped to root of WAR
Posted by Zachary Bedell <zb...@nycourts.gov>.
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 <rm...@gmail.com> 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 <zb...@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
>>
>>
Re: JAX-WS always mapped to root of WAR
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <zb...@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
>
>