jbossws packaging/deployment

[hbraun]

I am almost done with eventing beta, the next step would be to package the eventing stuff with the jbossws archives. Eventing comes some soap endpoints, which should be deployed with the jbossws.war . Unfortunatly, the way it is now, when the war gets deployed inside the sar, the deployer doesn't pick up the webservices. It works when the war is deployed separately, i.e:

deploy
 |_ jbossws.sar
 |_ jbossws.war

I can picture three solutions to the problem:

A,) Use the packaging structure mentioned above
B,) Make the sar deployer pick up webservices from russian doll archives
C,) Separately deploy eventing

I would vote for option A.

[thomas.diesler]

It should be like this

deploy
 |_ jbossws.sar
 |_ jbossws.war
 |_ jbossws-eventing.war
 |_ jbossws-whatever.war

Is this your option B? If it is, we need to create/fix the issue that does not pick up the endpoints.

[thomas.diesler]

More generally, it should be possible to deploy WS endpoints along with with the WS service. Whether this can be done with *.war deployments or not is a secondary issue.

[hbraun]

http://jira.jboss.org/jira/browse/JBWS-669

[hbraun]

Deploying webservices along with the service archive brings up a problem:

The webservice deployment interceptors are attached to the subdeployers when the interceptor is started, but the deployment of bundeled artefacts (a war for instance) is actually invoked prior to that. At that time the deployer in charge isn't aware of the deployment interceptor.

Any ideas how we can solve this?

[thomas.diesler]

Have you tried the depends clause in jboss-web?

[hbraun]

The depends clause orders the deployment as expected, still the WebserviceDeployer is not invoked:

[...]
2006-02-09 10:44:20,943 DEBUG [org.jboss.ws.server.WebServiceDeployerJSE] Interceptor attached to: 'jboss.web:service=WebServer'
2006-02-09 10:44:20,943 DEBUG [org.jboss.ws.server.WebServiceDeployerJSE] Started jboss.ws:service=WebServiceDeployerJSE
2006-02-09 10:44:20,943 DEBUG [org.jboss.system.ServiceController] Starting dependent components for: jboss.ws:service=WebServiceDeployerJSE dependent components: [ObjectName: jboss.web.deployment:war=jbossws-eventing.war,id=1488570753
 State: CREATED
 I Depend On:
 jboss.ws:service=WebServiceDeployerJSE
]

2006-02-09 10:44:20,943 DEBUG [org.jboss.system.ServiceController] starting service jboss.web.deployment:war=jbossws-eventing.war,id=1488570753
2006-02-09 10:44:20,943 DEBUG [org.jboss.web.WebModule] Starting jboss.web.deployment:war=jbossws-eventing.war,id=1488570753
[...]
2006-02-09 10:44:22,015 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/jbossws-eventing]] Servlet /jbossws-eventing threw load() exception
java.lang.ClassCastException: org.jboss.ws.eventing.SubscriptionManagerEndpointImpl

As you can see, the interceptor is now attached to the subdeployer prior to starting the deployment of the war file. Maybe the subdeployer has become stale due to some synchronization issues within the main deployer.

[jason.greene]

One approach that could work in the time being is to create a sub directory like so

server/default/deploy/jbossws/jbossws.sar
server/default/deploy/jbossws/jbossws-eventing.war

This would deploy the units together and in the proper order.

-Jason

[hbraun]

+1

[starksm64]

I think we need to look into the real issue here as having to rely on fragile elements like subdirectories and proper naming to get things to work is not what we want. Can you create a jira issue in JBAS that highlights the dependency problem so Dimitris can look into it?

[hbraun]

http://jira.jboss.org/jira/browse/JBAS-2796

[thomas.diesler]

No, this is not the solution. We can already deploy the endpoint outside of the jbossws.sar.

* endpoint deployment together with the sar should be fixed

* eventually we should support mbean endoints, which should also work when packaged with jbossws.sar

[dimitris]

So what happens is the following: We have (in HEAD)

jbossws.sar\
jbossws.jar
jbossws.war
jbossws-eventing.war
wsdl4j.jar
xmlsec.jar

WebServiceDeployerJSE was attaching its interceptor to the EJBDeployer during the startService() stage, so initialy I though this was the reason, the interceptor was missing the SubDeployer.create(DeploymentInfo) call to the tomcat deployer, for the jbossws-eventing.war.

So I changed WebServiceDeployerJSE (actually WebServiceDeployer) to attach the interceptor in the createService() stage. However, it still doesn't intercept the SubDeployer.create(DeploymentInfo) call.

The reason is that although jbossws-eventing.war "depends" on WebServiceDeployerJSE, the dependency is really the following:

jboss.web.deployment:war=jbossws-eventing.war,id=99026174 depends on jboss.ws:service=WebServiceDeployerJSE

This mbean is created during the Tomcat5 deployer create(DeploymenInfo -> jbossws-eventing.war) processing, so by the time WebServiceDeployerJSE.createService() is executed (and the interceptor gets registered) the call we want to intercept has already happened.

So the dependency won't solve the problem. Maybe jason's solution would work, but I didn't try it.

[jason.greene]

So what happens is the following: We have (in HEAD)

This mbean is created during the Tomcat5 deployer create(DeploymenInfo -> jbossws-eventing.war) processing, so by the time WebServiceDeployerJSE.createService() is executed (and the interceptor gets registered) the call we want to intercept has already happened.

So the dependency won't solve the problem. Maybe jason's solution would work, but I didn't try it.

The JBoss Portal WSRP implementation is affected by this very same problem because they deploy a war style webservice as a nested deployment in a sar file. So if the portal sar deploys before the jbossws sar file it can never succeed.

Was there a reason why we can't intercept the call to start instead of create? From the 2 minutes I spent looking through the code I can't see why this wouldn't work?

-Jason

[dimitris]

We do intercept the call to start(DeploymentInfo).

If the WebServiceDeployerJSE *stuff* can be safely moved from the

protected Object create(Invocation invocation, DeploymentInfo di) throws Throwable

to the

protected Object start(Invocation invocation, DeploymentInfo di) throws Throwable

phase, I guess this would solve the problem.