Community
Participate
Working Groups
Hi Tim, I think you were expecting a 'geronimo-jetty.xml' configuration file to be gen'd in the WEB-INF directory when we added the project/module to the server and ran it. So this bug can address that. With this fix, I hope to be able to access web apps on the server via a discoverable context root which should be in the geronimo-jetty.xml model. The default behaviour is to use the web.xml web-app id(WebApp_ID by default) as the context root and I'd like to be able to either set it or get the context root from the Geronimo server. My concern is that "WebApp_ID" is not unique when there may be multiple Web modules in multiple projects. Hopefully, having the geronimo-jetty.xml config file will resolve this problem.
Accoriding to the IBM tutorial on WTP and Geronimo, is says that this file should be generated, but I cannot see it anywhere. It obviously worked in M4 and the correct plugin, but broke in M5.
Hi Tim, I'm resettnig the severity to blocker b/c we need this fix in order to get further in adding support for Web services on Geronimo. The runway is pretty short. I believe Wed. July 13 is when WTP goes into must fix mode. If the fix cannot be contained by then, we can probably lower the severity again and target it for the next milestone.
Created attachment 24624 [details] Patch file Now locates the deployment plan correctly
*** Bug 103389 has been marked as a duplicate of this bug. ***
Tim, please review&commit this
Patch reviewed, applied to HEAD, and tagged for next I-build.
Hi Tim, Thanks for the patches. I am able to get further with them. The problem now is that redeployment or deploying another module doesn't quite work 100%. The behaviour I see is that although both modules are deployed, not all of the second module's files cannot be served. Try this: 1) Create a project and index.html, and launch "Run on Server" 2) Create a second project, B, and index.html, and "Run on Server again". 3) Create another "hello.html file" in project B, and "Run on Server". I get a 404 error when launching hello.html. As you know, the Web services wizard causes re-deploys to the server and, in the end-to-end scenario, creates and adds another module to the server also. So, similar to the behaviour after doing the above, we are not able to launch our generated JSPs.
For Tim F. Thanks!
Tim - If you are going to fix this for 0.7, please set the target milestone, accept it, and try to get a fix within the next couple days. If that is not your plan, please drop the priority to P4 and provide some justification for why it can't or shouldn't be fixed now. Blocking defects are being reviewed during 0.7 shutdown and we need to resolve this bug one way or the other soon.
I am not able to reproduce this problem, even using the scenario you describe. I believe that the Geronimo support essentially works now - I do not believe this problem (even if we can find a reproducible scenario) is a blocker for 0.7
Web services are not able to deploy when the server is in the started state. Basically, we get a 404 error because the Axis admin servlet isn't being served. I suppose the scenario I described may have been inconsistent in reproducing the error. Sorry about that. Here's what we have been consistently running into using the Web services wizard to start/stop/re-start the server. 1. Create a Geronimo targetted Web project and add a Java bean. 2. Do a Bottom-Up Java bean Web service (click finish in the wizard to accept defaults). 3. Next, leave the server running, get another Java bean and run the Bottom-Up Java Web service wizard again. A way to check whether or not the Axis admin service is running is by opening the following URL: http://localhost:8080/*WebApp_ID*/services/AdminService Note: After step 3, the URL is no longer valid.
Since basic Geronimo server function is deemed working, I agree that we can defer this to 1.0.
This problem can be marked RESOLVED
Reassigning this bug to Sachin
Fixed in apache repo.
This change is a bulk update of all _un_targeted, fixed, resolved bugs upon release of M5. This particular bug _might_ have been fixed earlier than M5. (Feel free to correct).
Closing