[ http://jira.jboss.com/jira/browse/JBWS-1762?page=all ] Thomas Diesler updated JBWS-1762: --------------------------------- Fix Version/s: jbossws-2.0.1 (was: jbossws-2.1.0) -- 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

[ http://jira.jboss.com/jira/browse/JBWS-1762?page=all ] Thomas Diesler reopened JBWS-1762: ---------------------------------- Please explain why we need to restore web.xml -- 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

[ 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. -- 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

[ http://jira.jboss.com/jira/browse/JBWS-1762?page=comments#action_12377972 ] Thomas Diesler commented on JBWS-1762: -------------------------------------- In memory modification would be possible for jboss50, but not for jboss4x A web.xml rollback should not be necessary if the algorithm that does the modification detects that web.xml already contains the required modification s. The user should be able to provide an already modified web.xml for example to use an endpoint servlet other than th e one we provide. In short, the detection when to modify is wrong/incomplete - rollback should never be necessary. -- 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

[ http://jira.jboss.com/jira/browse/JBWS-1762?page=comments#action_12377983 ] Richard Opalka commented on JBWS-1762: -------------------------------------- Thomas Diesler wrote:In memory modification would be possible for jboss50, but not for jboss4x . What about me there's only one solution that comes in my mind. I could modify DeployerHooks to detect modified web.xml files as web archives and repair all the aspects that fail when such archive is redeployed. Do you agree with me Thomas? -- 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

[ http://jira.jboss.com/jira/browse/JBWS-1762?page=comments#action_12378522 ] Richard Opalka commented on JBWS-1762: -------------------------------------- I've modified non EJB JAXWS and JAXRPC deployer hooks in the following way: If there's the web.xml.org on the classpath, this file is inspected and all servlets defined within it are used instead of servlets defined in passed WebMetaData structure. WebMetaData structure is created by JBoss runtime and contains data that are useless for us in this specific usecase. -- 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

[ http://jira.jboss.com/jira/browse/JBWS-1762?page=comments#action_12378574 ] Thomas Diesler commented on JBWS-1762: -------------------------------------- Lets continue to discuss this here http://www.jboss.org/index.html?module=bb&op=viewtopic&t=119629 -- 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

[ http://jira.jboss.com/jira/browse/JBWS-1762?page=all ] Thomas Diesler updated JBWS-1762: --------------------------------- Fix Version/s: jbossws-2.0.3 (was: jbossws-2.0.2) Assignee: Thomas Diesler (was: Richard Opalka) -- 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

[ http://jira.jboss.com/jira/browse/JBWS-1762?page=comments#action_12383386 ] Richard Opalka commented on JBWS-1762: -------------------------------------- Created JAX-WS based test matrix for this issue: ./build.sh -Dtest=jaxws/jbws1762 test -- 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

[ http://jira.jboss.com/jira/browse/JBWS-1762?page=all ] Thomas Diesler updated JBWS-1762: --------------------------------- Comment: was deleted -- 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

[ http://jira.jboss.com/jira/browse/JBWS-1762?page=all ] Heiko Braun updated JBWS-1762: ------------------------------ Workaround Description: Use packed war structures. This problem only applies to unpacked war files, which may be nested. Workaround: [Workaround Exists] -- 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

[ http://jira.jboss.com/jira/browse/JBWS-1762?page=comments#action_12392406 ] Heiko Braun commented on JBWS-1762: ----------------------------------- Cannot be fixed for 4.0.5, because this would require changes to the AS web meta data to access the servlet init params. -- 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