[jbossws-issues] [JBoss JIRA] Commented: (JBWS-1762) web.xml modified to web.xml.org - Subsequent runs fail

[Richard Opalka (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBWS-1762?page=comments#action_12377549 ] 
            
Richard Opalka commented on JBWS-1762:
--------------------------------------

The problem is the following:

There are Hooks registered on server side concretely instances of
AbstractDeployerHookJSE and/or AbstractDeployerHookEJB. These
hooks inspects the provided web.xml file, looks at the defined "servlets"
(these servlets are our webservices i.e. POJOs or EJBs) and checks whether
there are WebService or WebServiceProvider annotations defined on
these classes. If yes, such web archive is detected as webservice archive
and passed to the DeploymentAspectManager.deploy() method.
   This deploy() method calls all registered aspects and one of these aspects
si also our ModifyWebMetaDataDeploymentAspect which modifies the web.xml
file in the following way:

original file content:
...
<servlet> 
  <servlet-name>MyService</servlet-name>  
  <servlet-class>mypackage.POJOService</servlet-class>  
</servlet>  
...
---------------------------------------------------------------------
modified file content:
...
<servlet> 
  <servlet-name>MyService</servlet-name>  
  <servlet-class>org.jboss.wsf.stack.jbws.EndpointServlet</servlet-class>  
  <init-param> 
    <param-name>jboss.ws.endpoint</param-name>  
    <param-value>mypackage.POJOService</param-value> 
  </init-param> 
</servlet>  
...

You can see that our POJO service was replaced with JBossWS endpoint servlet
and passed to it as initialization parameter.

Let's explain why we need to restore web.xml from original one.
If we won't restore web.xml then aforementioned e.g AbstractDeployerHookJSE
will inspect org.jboss.wsf.stack.jbws.EndpointServlet instead of mypackage.POJOService.
This class of course doesn't declare neither WebService nor WebServiceProvider annotation on its class.
Such archive is then recognized as not webservices archive and not passed to the deployment process.

So I decided to provide destroy() method to the ModifyWebMetaDataDeploymentAspect class,
which goal is to restore the original web.xml.

You may ask why this doesn't happen in many JBossWS usecases?
It's because there's 99.99 % of deployments that use packaged war file.
If JBoss deploys packaged war file, it will always create new temporary
directory in its tmp directory and extracts it's content there. Thus all
aforementioned deployment magic happens always on clear temporary
directory.

The problem appears when JBoss deploys unpackaged war file, because for
such file JBoss never creates new temporary directory but uses the
original one. This is the reason why I decided to provide the destroy() method
on the above mentioned aspect. This solution doesn't affect packaged war files
at all, because that worked even before.

> web.xml modified to web.xml.org - Subsequent runs fail
> ------------------------------------------------------
>
>                 Key: JBWS-1762
>                 URL: http://jira.jboss.com/jira/browse/JBWS-1762
>             Project: JBoss Web Services
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: jbossws-2.0.0
>            Reporter: Heiko Braun
>         Assigned To: Richard Opalka
>             Fix For: jbossws-2.0.1,  jbossws-2.0.2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira