ReSTEasy bindings context path

[edevera]

Is the context path of ReSTEasy bindings optional? I read that I leave it out, it should default to /.

Can I do this on different bindings in the same application?

Can I do this on different bindings of different applications?

My wish is to be able to determine the context path by using the @Path jax-rs annotation.

[boanergesza11]

Hi Eduardo;

I dont know if this wil help.

Can I do this on different bindings in the same application?

Can I do this on different bindings of different applications?

I think the answer is no. There would be no way for it to determine which impolementation of yours to use for that binding.

My wish is to be able to determine the context path by using the @Path jax-rs annotation.

I found that in the interface you create for that rest binding, you can specify

@Path("/whatever")

public Interface ....

....

...

@Path("/more_whatever")

public String doStuff( ...

So the question is, if you dont specify the contextpath in the SY.xml and also not the Path on the class and only on the method, will you be able to access it ? A quick test would tell I suppose.

[edevera]

Thanks for your answer.

Since in the documentation I can read:

• contextPath : Additional context path for the REST endpoint. Default is none.

I would assume that it is an optional parameter, thus I would expect that it works always.

Could someone from SwitchYard team actually answer this question?

[kcbabo]

Magesh can correct me if I'm wrong here, but contextPath is required when using the SY runtime in EAP.  It's optional for using our embedded test container (it's actually not used at all, from what I can see).  We should default this to application name if it's not supplied in switchyard.xml, but that's not happening now.

[mageshbk]

Magesh can correct me if I'm wrong here, but contextPath is required when using the SY runtime in EAP.  It's optional for using our embedded test container (it's actually not used at all, from what I can see).

Yes that is correct. The contextPath is required because there is already a web context started by the welcome application. In theory we can publish the JAX-RS endpoints to the default context if this welcome app is disabled and with some minor tweaks in SwitchYard code. That would be a feature request for the future. I have created a JIRA here to investigate that.

https://issues.jboss.org/browse/SWITCHYARD-1602

We should default this to application name if it's not supplied in switchyard.xml, but that's not happening now.

Unlike the SOAP Gateway, JAX-RS resources are registered as Singletons. So there is no need to isolate them per application. The same contextPath can be used across applications. To showcase this, I split the rest-binding QS into 2 parts and these can be deployed and test with the instructions of Readme from rest-binding. Attached the split application jars.

[kcbabo]

Ah, that's interesting.  I actually tested this myself and found that it didn't work, but my test might have been a bit different.  I copied two test apps into the deployments directory, then started the server, which failed.  I tried again by deploying each application independently and it worked.  Have you tried the startup/restart scenario in your environment?  My suspicion here is that parallel deployment of apps during startup is exposing a lack of synchronization the singleton which registers the context.

Here's the stack at the point of failure:

Caused by: org.switchyard.component.resteasy.RESTEasyPublishException: java.lang.IllegalArgumentException: JBWEB000250: Child container with name /test1 already exists
          at org.switchyard.component.resteasy.InboundHandler.doStart(InboundHandler.java:86)
          at org.switchyard.deploy.BaseServiceHandler.start(BaseServiceHandler.java:60)
          at org.switchyard.deploy.internal.Deployment.deployServiceBindings(Deployment.java:612)
          at org.switchyard.deploy.internal.Deployment.start(Deployment.java:143)
          at org.switchyard.as7.extension.deployment.SwitchYardDeployment.start(SwitchYardDeployment.java:101)
          at org.switchyard.as7.extension.services.SwitchYardService.start(SwitchYardService.java:73)
          ... 5 more
Caused by: java.lang.IllegalArgumentException: JBWEB000250: Child container with name /test1 already exists
          at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:794)
          at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:785)
          at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:353)
          at org.switchyard.as7.extension.resteasy.RESTEasyResourcePublisher.publish(RESTEasyResourcePublisher.java:82)
          at org.switchyard.component.resteasy.InboundHandler.doStart(InboundHandler.java:82)
          ... 10 more

[mageshbk]

Thanks Keith! That is definitely a synchronization issue in our deployer code. However, I do not get this in my environment. Here is another JIRA to follow it up:

https://issues.jboss.org/browse/SWITCHYARD-1603