I retried this with AS 5.0.0.CR2 and JBossWS 3.0.4 and it appears to work . . . most of the time.
The NPE is no longer generated if I restart with the war file still deployed However, two other things go wrong:
i) I get the following warnings during booting as end points are published
. . . 15:22:52,332 INFO [DefaultEndpointRegistry] register: jboss.ws:context=ws-c11,endpoint=Activation Service 15:22:52,335 INFO [DefaultEndpointRegistry] register: jboss.ws:context=ws-c11,endpoint=Registration Service 15:22:52,354 WARN [AbstractServerConfig] Unable to calculate 'WebServicePort', using default '8080' 15:22:52,358 WARN [AbstractServerConfig] Unable to calculate 'WebServicePort', using default '8080' . . .
A block of messages is generated for each war file ans there is one message ffor each end point.
ii) sometimes the server hangs during deployment of the end points and never reaches start up (well,I waited 5 minutes).
I had a little further look into this and found that the errors occur as follows:
During deployment of the endpoints declared in my wars a call is made to AbstractServerConfig.getConnectorPort(). This fetches the WS Server MBean and tries to lookup objects of type "jboss.web:type=Connector,*". At the point where the lookup fails the jboss.web MBean has only one entry for the WebServer.
In the run that I managed to debug the type=Connector entries were added at a later point. So, some of the subsequent calls to getConnectorPort() succeeded and also the AS bootstrap did not hang. I was unable to debug a case where the bootstrap did hang.
So, although this is a lot better than 3.0.3 it looks like there is still a race where the deployers may try to start the endpoints before everything they need is in place.
I managed to debug this a little further and have identified why the startup code is hanging -- it is because of something my code is doing (I'll come to that in a second). I still don't know why the WebService port is being looked up before it is defined so there is still an issue there.
The hang is because I am trying to coordinate initialization of my war apps and the XTS service which deploys them. The problem I face is that the listeners are run in an arbitrary order but the war apps have initialization dependencies. So, I make the war listeners register callbacks in a fixed sequence. If any of them finds that the sequence is complete after regsitering then it runs all the callbacks.
This was ok until I added transaction recovery which requires initialization in the XTS service start() routine before the wars can be initialized. I had assumed that the XTS service start() call happened in parallel with the war listener calls so I added a latch in the callback runner which was released by the XTS service start(). If the runner gets there first it does a wait() and the start() call wakes it with a notfiy(). It appears that the start() and listener call actually run in the same thread in arbitrary order and up until now the start() call has always run first. Now, the sar start() call occasionally gets run last, resulting in a deadlock. I guess I need to make my war apps depend on the XTS service bean.
We know about all these problems adinn.
It should be fixed with next JBossWS release.
You can register for events here: JBWS-2332 and see the progress on this issue.