[ https://jira.jboss.org/jira/browse/JBDS-1103?page=com.atlassian.jira.plug... ] Brian Fitzpatrick commented on JBDS-1103: ----------------------------------------- I was able to reproduce this today. Works fine in a Tomcat, but fails with the same errors in the log as the log that's attached. For some reason, during deployment it is requiring an Eclipse JST library to be deployed, which is bizarre... org.eclipse.jst.ws.util.JspUtils This class seems to not appear in any recent WST/JST jar and why we'd be deploying an Eclipse jar into an appserver is beyond me. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBDS-1103?page=com.atlassian.jira.plug... ] Rob Stryker commented on JBDS-1103: ----------------------------------- I don't know exactly how the tomcat deployer works. I'd really have to dig into the code to see what exactly is going on here. However it seems blatently obvious to me by reading the exception that the APPLICATION is expecting an eclipse jar to be on the runtime's classpath. You can verify this by looking at workspace.zip\JBDS-CR3\AxisWSClient\WebContent\sampleServiceProxy\Result.jsp which CLEARLY tries to access an eclipse jar. However none of the component.xml files in the workspace show any inclination to add this jar into the result jar / war / ear / client jar etc. Even the .classpath file does not show any exported classpath entries that would be expected to be exported when published. I'd have to really really investigate how the Tomcat adapter handles this, but at first glance this is not a project that I would ever expect to work on our servers unless the project exported and published the utilities class / jar as a library on the classpath. Seems to me like the project shouldn't work. Not sure how it does on tomcat. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBDS-1103?page=com.atlassian.jira.plug... ] Max Rydahl Andersen commented on JBDS-1103: ------------------------------------------- Looking at the workspace sent to me webservicesutils.jar is actually in the AxisWSClient/WEB-INF/lib directory and org/eclipse/jst/ws/util/JspUtils.class exist inside it. Libor, is that jar maybe not deployed to the server ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBDS-1103?page=com.atlassian.jira.plug... ] Libor Zoubek commented on JBDS-1103: ------------------------------------ When I add new method to my service implementation class and regenerate WSDL and client proxy by New->Web Service wizard, the old (first method) works, but when testing the new one I get java.lang.NoSuchMethodError: ws.test.AxisServiceProxy.method2() it really seams that wizard somehow badly deploys the client proxy. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBDS-1103?page=com.atlassian.jira.plug... ] Max Rydahl Andersen updated JBDS-1103: -------------------------------------- Workaround Description: Touch the client war to trigger a module restart to pickup the changed jars/classes. Restarting the appserver also works but is overkill. Workaround: [Workaround Exists] Putting for for .1 release since we should investigate what the wizard actually needs - and how this works for JBossWS examples? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBDS-1103?page=com.atlassian.jira.plug... ] Denis Golovin updated JBDS-1103: -------------------------------- Component/s: SOA Platform -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBDS-1103?page=com.atlassian.jira.plugin.sy... ] Rob Stryker commented on JBDS-1103: ----------------------------------- If the server has loaded a deployment, and I copy a jar into that exploded deployment, the runtime does not pick it up. I would need to force the application to restart if a jar or similar extension file that I know the runtime won't pick up is changed. However I've so far hesitated to do this because I don't like the idea of restarting the module all the time. I'm sure I can add this in for unzipped wtp-based deployments but it may require some digging how to do properly based on the current codebase. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBDS-1103?page=com.atlassian.jira.plugin.sy... ] Rob Stryker resolved JBDS-1103. ------------------------------- Fix Version/s: 4.0.0.Helios Resolution: Done Committed to trunk and jbt 3.1.x branch streams, manually tested -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBDS-1103?page=com.atlassian.jira.plugin.sy... ] Rob Stryker commented on JBDS-1103: ----------------------------------- Why is this exactly a bad thing? Once a web.xml or other file is touched, the entire module is reloaded, not just part of the module. So if you're going to touch the primary descriptor, also touching the other xml files is no harm at all. I fail to see why this is a bad thing or why this should be reverted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBDS-1103?page=com.atlassian.jira.plugin.sy... ] Rob Stryker commented on JBDS-1103: ----------------------------------- Only touching the relevant descriptor would require several things. 1) First it would require an extension point so that new WTP-style flexible project types can have an API to designate which paths are their default descriptors. 2) Second, this would require that the projects creating a new project type (ie, esb, bpel, etc) actually USE this API. 3) Third, it would make people using a Utility project in some custom fashion (for whatever reason they have) to be left with a completely nonfunctional module restart during this usecase, since a utility project by definition has no default descriptor. Touching the relevant descriptor forces the app server to undeploy and redeploy the changed deployment. Therefore, by definition, the server has to get rid of, and reload, the entire deployment. There is therefore zero performance hit (except for the touch call itself) during the module restart if the relevant deployment descriptor is touched vs if all are touched. I'll do it since you're making me, but I find your logic completely nonsensical. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBDS-1103?page=com.atlassian.jira.plugin.sy... ] Rob Stryker resolved JBDS-1103. ------------------------------- Resolution: Done -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBDS-1103?page=com.atlassian.jira.plugin.sy... ] Max Rydahl Andersen updated JBDS-1103: -------------------------------------- Fix Version/s: 4.0.0.M2 (was: 4.0.0.M1) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBDS-1103?page=com.atlassian.jira.plugin.sy... ] Rob Stryker resolved JBDS-1103. ------------------------------- Resolution: Done Just committed a patch to touch the folder if the descriptor file doesn't exist. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBDS-1103?page=com.atlassian.jira.plugin.sy... ] Rob Stryker updated JBDS-1103: ------------------------------ Fix Version/s: 3.0.2.GA (was: 3.0.x) (was: 4.0.0.M2) This is still in the branch, and will make it into 3.0.2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBDS-1103?page=com.atlassian.jira.plugin.sy... ] Libor Zoubek closed JBDS-1103. ------------------------------ verified on 4.0.0.v201012070137R-H33-Beta2 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira