tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zachary Bedell <zbed...@nycourts.gov>
Subject JAX-WS always mapped to root of WAR
Date Mon, 05 Jun 2017 20:32:59 GMT
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
View raw message