Community
Participate
Working Groups
I am targetting this 1.0RC2 build: Wed, 7 Dec 2005 -- 09:53 (UTC) with the latest Web service code checked out from CVS. To reproduce: 1. In a new workspace with no projects and no existing servers create a Web project (wp, web 2.4, java 1.4, tomcat 5.0) 2. Import a bean into wp/src and select the bean 3. Launch the Web service wizard and select "Generate a proxy" and "Test ...". 4. Click Next accepting defaults on each page of the wizard. Do not click Finish until you get to the last page. The sample JSP launches but Result.jsp does not compile with the error below. Restarting the server makes the problem go away. HTTP Status 500 - -------------------------------------------------------------------------------- type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception org.apache.jasper.JasperException: Unable to compile class for JSP An error occurred at line: 30 in the jsp file: /sampleEchoProxy/Result.jsp Generated servlet error: D:\Eclipse31\eclipse\runtime-workspace-t6\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\work\Catalina\localhost\wp1208aClient\org\apache\jsp\sampleEchoProxy\Result_jsp.java:87: package org.eclipse.jst.ws.util does not exist String tempResultreturnp3 = org.eclipse.jst.ws.util.JspUtils.markup(String.valueOf(getEndpoint2mtemp)); ^ An error occurred at line: 67 in the jsp file: /sampleEchoProxy/Result.jsp Generated servlet error: D:\Eclipse31\eclipse\runtime-workspace-t6\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\work\Catalina\localhost\wp1208aClient\org\apache\jsp\sampleEchoProxy\Result_jsp.java:140: package org.eclipse.jst.ws.util does not exist String tempResultreturnp14 = org.eclipse.jst.ws.util.JspUtils.markup(String.valueOf(echo13mtemp)); ^ 2 errors org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:84) org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:332) org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:412) org.apache.jasper.compiler.Compiler.compile(Compiler.java:472) org.apache.jasper.compiler.Compiler.compile(Compiler.java:451) org.apache.jasper.compiler.Compiler.compile(Compiler.java:439) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:511) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:295) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) note The full stack trace of the root cause is available in the Apache Tomcat/5.0.28 logs. -------------------------------------------------------------------------------- Apache Tomcat/5.0.28
Kathy, would you please add this to your list of bugs for the WTP 1.0 Web services New and Noteworthy document? The symptom and workaround are easily explained and done. Rupam, reading between the lines of your description, does the problem only occur when you Finish on the last page?
The problem occurs when Finish is clicked on the last or second to last page (i.e. the Web Service Client Test page or the Web Service Publication page). I can't reproduce the problem when I click Finish on the Generate Proxy page or the first page so I'm guessing that clicking Finish on any of the pages in between will also not reproduce the problem. I also need to be in a new workspace.
Also, when the problem occurs, re-publishing the server did not help. I had to restart the server for the problem to go away.
After running through bottom-up and client on the same project that had been added to a started server, when I run a skeleton scenario with client and test, and hit Next to the end of the wizard and then click Finish, I got the error in server console on the Result.jsp: SEVERE: Error compiling file: /D:/eclipse311/eclipse/runtime-workspace_selfhost1208d/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/work/Catalina/localhost/aClient//org/apache/jsp/sampleAreaServiceProxy\Result_jsp.java [javac] Compiling 1 source file D:\eclipse311\eclipse\runtime-workspace_selfhost1208d\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\work\Catalina\localhost\aClient\org\apache\jsp\sampleAreaServiceProxy\Result_jsp.java:87: package org.eclipse.jst.ws.util does not exist String tempResultreturnp3 = org.eclipse.jst.ws.util.JspUtils.markup(String.valueOf(getEndpoint2mtemp)); ^ D:\eclipse311\eclipse\runtime-workspace_selfhost1208d\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\work\Catalina\localhost\aClient\org\apache\jsp\sampleAreaServiceProxy\Result_jsp.java:149: package org.eclipse.jst.ws.util does not exist String tempResultreturnp14 = org.eclipse.jst.ws.util.JspUtils.markup(String.valueOf(calculateRectArea13mtemp)); I check the server's temporary publish directory and see webserviceutils.jar in WEB-INF/lib directory. As noticed before, doing publish did not help. The server state still says "restart". If I restart the server, the result.jsp compiles OK. So the problem does not just happen with new workspace and no server.
*** Bug 120133 has been marked as a duplicate of this bug. ***
*** Bug 120132 has been marked as a duplicate of this bug. ***
Rupam and I was able to reproduce the problem consistently with Rupam's steps, we were not able to reproduce the problem with RC2 1208_1903 after the patch for bug 119997 (changing publish to secondary thread) is applied.
Please try the JAR attached with bug 119997 to see if you are still able to reproduce this problem.
I can't reproduce the problem with the JAR attached to bug 119997. Resolving bug as fixed.
Verified on the 1.0RC3 driver.
With the 1.0RC3 driver, I can't reproduce the bug on Windows but I'm seeing it on SLES 9 with identical steps to reproduce, symptoms, and workaround. Changing the OS to Linux and reopening.
I hit this problem again on RC5 on Windows XP running Tomcat 5.0.28. I restarted the server to fix the problem. Details: My server was running in debug mode. It had already run an html page and a jsp, and debugged the jsp. The Web service itself was deployed correctly AFAIK. I am puzzled why this problem is so hard to fix. Doesn't it seemly required that the utility jar be copied to the Web app and that the server pick up the new content? Maybe Larry Isaacs can look at this. I am cc'ing him.
The various versions of Tomcat can detect and react to certain changes within webapps and not others, depending on the Tomcat configuration. One change that is never detected is the addition of new jars to WEB-INF/lib. In the senario cited at the beginning, the client webapp is not reloaded nor Tomcat restarted after the webserviceutils.jar is created. Thus, it isn't available to the JSP compiler resulting in the error. Note that if the autoDeploy attribute is set false on the <Host> element in Tomcat's server.xml, than this wizard will always fail with a 404 error. The client webapp won't be served until Tomcat is restarted after the client webpp has been published. With autoDeploy set true, which is the shipped default, then a short time after the client webapp is published to the server, a background thread will detect it and auto-deploy it. If you are quick enough (clicking Finish early helps), and with a little luck, the webserviceutils.jar may get published to the server before the auto-deploy occurs. If so, the error is avoided. Given that the timing of this background thread isn't controllable, you can't be certain that the webapp has been completely copied when the auto-deploy occurs. If the webapp isn't all there, such as with the delays that this wizard can inject, errors like the above are the typical result. At the moment, my investigation hasn't reached the point of determining if an attempt to programmatically restart Tomcat is failing, or is assumed to occur on its own due to the publishing that is occuring after Tomcat was started. I'll look further. An actual server restart following the last publish will be necessary to make this wizard work reliably.
The source of the problem, given current implementation, is that StartServerCommand.execute() tests for "publishState != IServer.PUBLISH_STATE_NONE", and if not true, skips the restart. When debugging, I don't see this test ever true at this point in the code, so restarts don't happen. Comments above this test suggest this was added to avoid unnecessary restarts. Unfortunately, it is avoiding a necessary restart in this case. For me, removing this test avoids the 500, or possible 404 error if autoDeploy is turned off. However, I'm not familiar enough with the web services code to say what impact this may have in other use cases. If you have particular use cases where restarts should not be occurring, let me know and I'll investigate to see what might be done.
Thanks for your helpful comments Larry. After some initial debugging/testing, I tend to agree with Larry's assessment that StartServerCommand.execute() should no longer test for "publishState !=IServer.PUBLISH_STATE_NONE" before doing a restart. If my memory serves me correctly, code was added to check this condition in 0.7 because getServerRestartState() was returning true even when all we did was add Java files to the src folder of a Web project on a started Tomcat server. During my testing I also observed that getServerPublishState() is always returing IServer.PUBLISH_STATE_NONE, even after a module has just been added to the server. In 0.7, after a module was added to the server, getServerPublishState() returned IServer.PUBLISH_STATE_UNKNOWN. It seems in 1.0RC5 that Tomcat automatically publishes any modules that are added. Before we can commit this fix, the Web services team needs to do more testing to ensure that a restart occurs when and only when it is necessary.
Please note that the issue with when to restart server and when to publish is related to bug 119969 and bug 118288.
Kathy, assigned to you since you're working the collective solution to this bug + bug 119969 + bug 118288.
*** Bug 118288 has been marked as a duplicate of this bug. ***
*** Bug 119969 has been marked as a duplicate of this bug. ***
Here's the extend of the changes to fix up the checking for server publish and start at the right time and using the right API: Plugin jst.cons.ui: StartServerCommand - Call ((Server)server).shouldRestart() and((Server)server).shouldPublish() rather than checking for server.getServerPublishState() and getServerRestartState(). - Remove forcePublish (which used to be called from the sample JSP launch because the server API was not returning the correct state when publish is required). - Remove the check for (publishState != IServer.PUBLISH_STATE_NONE) before restarting. This is the restrictive case that caused the HTTP 500 error. PublishProjectCommand: - Add the check for ((Server)server).shouldPublish() before calling server publish. StartServerWidget, AddModuleDependenciesCommand and GSTLaunchCommand: - change the constructor for calling StartServerCommand to remove forcePublish. jst.ws.axis.creation.ui: UpdateWEBXMLCommand.java: - Revert back to version 1.20 (bug 118288 - workaround to fix bug 102117) AxisWebService.java: - Change the signature for calling UpdateWEBXMLCommand (bug 118288 - revert back to before bug 102117 was applied). - Remove the call to PublishServerCommand (bug 118288- remove the workaround for bug 119140). The above fixes include fixing the following bugs: - bug 119954 - bug 118288 - bug 119969 Code patches would be attached.
Created attachment 33301 [details] jst.ws.cons.ui patch This also includes the patch for bug 114852.
Created attachment 33302 [details] axis.creation.ui_patch
Created attachment 33303 [details] Updated JAR for jst.ws.cons.ui This JAR should replace the JAR in a recent M-build (e.g. M20060117)
Created attachment 33304 [details] Updated JAR for axis.creation.ui This JAR should replace the JAR in a recent M-build (e.g. M20060117)
The following testing had been done: - scenario reported in bug 119954 (Windows and Linux), 102117, 119140, 118098 - Tomcat 4.0, 4.1, 5.0 (auto-publish on, auto-publish off, default publish), 5.5 with the following combinations of scenarios, server state and module state Scenarios: - client + sample JSP - sample JSP only - service side only - service + client - service + Client + sample JSP server state: not exist / started / stopped Web module state: not added to server, added to server but no Axis servlet, added to server with Axis servlet. We've also tested the fix with servers not shipped in WTP as well. The tests are all running OK with the server publishing and starting/restarting properly. The code changes had been committed and will be released for the M-build on 01/23.
Created attachment 33391 [details] Update JAR for jst.ws.axis.creation.ui Back up the JAR in the plugins directory and replace.
Created attachment 33392 [details] Update JAR for jst.ws.consumption.ui Back up the JAR in the plugins directory and replace.
For some reason, the name of the 2 JARs in the attachment is named org[1].eclipse.jst.ws..... when I tried to detach it even though I had made sure the name of the file I attached was org.clipse.jst.ws... I tried attaching them a second time and the same thing still happened. So, if you are using the update JARs, make sure to rename them from org[1].eclipse.jst.ws to org.clipse.jst.ws. These JARs need to go on top of a recent M101 build (e.g. M200601170000) since jst.ws.axis.creation.ui.jar was build on top of the fix for bug 121199 which has a dependency on an updated wst.command.env.
Released to 101 M and HEAD as v20050123_1000.
Ran into this one in 1.0. Switched to I200602022035 and it went away.
*** Bug 107546 has been marked as a duplicate of this bug. ***
*** Bug 85823 has been marked as a duplicate of this bug. ***
Verified on Windows. Will also verify on Linux.
Closing.
