JBossDeveloper

"dimitris@jboss.org" wrote:
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.

With the current architecture this cannot be fixed.
The WebServiceDeployer interceptor must be attached before the Tomcat5 deployer enters the create state for a *.war deployment, because it must modify the *.war deployment before it is created.

If the *.war deployment has a dependency on WebServiceDeployerJSE and the interceptor has not been attached already it is too late to attach the interceptor to the Tomcat5 deployer when the *.war service is created/started.

I fix this issue by inventing a new *.jse deployment with an associated deployer that simply copies the *.jse to a *.war and deploys it throuh the MainDeployer. WebServiceDeployerNestedJSE has a dependency on WebServiceDeployerJSE. Therefore it is guarantied that the interceptor is installed.

The web.xml file is parsed during start() not create(), so this does work provided that the sequence of events is modified such that all activity in create is moved to start, and that happens before the invokeNext() is called in start(). I prototyped this and it is working although I have other changes in my tree that I need to sort out. I will try and get this done tonight.

-Jason

Actually I ran into problems with this approach after all. I need to investsigate this further.

-Jason

One of the problems is that when dependencies are involved WebServiceDeployer.start() is invoked multiple times. We need to check with ServiceController to verify that the web deployment was actually started.

This problem affects the current create() approach as well.

-Jason

I have refactored WebServiceDeployer and WebServiceDeployerJSE to handle nested deployments.

The sequence of events that normally occurs when dependencies are in effect follows:

1. 
   
2. create() is ran adding interceptors
   
3. start() is called on WebServiceDeployerJSE
   
4. start() is called on AbstractWebContainer
   
5. ServiceController.start() is called on WebModule, but WebModule is not started because dependencies are not yet satisfied.
   
6. start() is completed in WebServiceDeployerJSE
   
7. Some time later, after dependencies are resolved, start() is called on WebModule.
   
   So the issue is that we can not start the service endpoint until step 6 happens, and that is outside of the start() invocation.
   
   The solution I chose was to dynamically add a temporary notication handler on ServiceController that starts the service endpoint whenever the WebModule does not start in step 4.
   
   There is still one last problem to resolve that only affects JSR-181 endpoints. AbstractWebContainer.init() needs to unpack a war if it is a web service. It can use webservices.xml if it is a j2ee 1.4 web service, however, if it is a jsr-181 deployment, webservices.xml is optional.
   
   There is a hack that depends on jbossws.sar being around before the deployment can ever succeed:
   
   

   unpackWebservice |= server.isRegistered(ObjectNameFactory.create("jboss.ws:service=ServiceEndpointManager"));
   

   
   I see two possible solutions to this problem:
   
   1. 
      
   2. Always unpack all wars. Is this really that much of a cost that we don't want this step?
      
   3. Scan the web.xml for servlets that do not implement javax.servlet.Servlet, and if found unpack the war.
      
      Thoughts anyone?
      
      -Jason

To me the issue is trivial:

Any service endpoint deployment should only happen after the WS deployment interceptors are installed. Therefore we must somehow postpone endpoint deployement until the interceptors attach themselves.

Why is the *.jse approach not working for you? See how ws-eventing starts up when nested inside jbossws.sar even in jboss-4.0.x

More generally, we need an approach like this

#1 all interceptors attach to their respective deployers

#2 the deployers start picking up their respective deployments

This should be discussed with Dimitis and Scott.

"thomas.diesler@jboss.com" wrote:
To me the issue is trivial:

Any service endpoint deployment should only happen after the WS deployment interceptors are installed. Therefore we must somehow postpone endpoint deployement until the interceptors attach themselves.

Why is the *.jse approach not working for you? See how ws-eventing starts up when nested inside jbossws.sar even in jboss-4.0.x

"jason.greene@jboss.com" wrote:

"thomas.diesler@jboss.com" wrote:
To me the issue is trivial:

Any service endpoint deployment should only happen after the WS deployment interceptors are installed. Therefore we must somehow postpone endpoint deployement until the interceptors attach themselves.

Why is the *.jse approach not working for you? See how ws-eventing starts up when nested inside jbossws.sar even in jboss-4.0.x

The jse approach does work, but do we want another deployment type just to support nesting?

I assumed that we all prefered to support war files with the standard jboss dependency subsystem, which is what I implemented. So I pulled out the nested deployer, and now jbossws-eventing is using a nested war file with a dependency on WebServiceDeployerJSE.

The only thing thats not working atm is nested jsr181 deployments that don't have a webservices.xml. Although we don't have anything that uses that yet. As soon as we fix the init() phase of AbstractWebContainer, this problem goes away.

-Jason

"thomas.diesler@jboss.com" wrote:
More generally, we need an approach like this

#1 all interceptors attach to their respective deployers

#2 the deployers start picking up their respective deployments

This should be discussed with Dimitis and Scott.