Bugzilla – Full Text Bug Listing
| Summary: | tomcat restarts even when editing an html, css, js, etc | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP Java EE Tools | Reporter: | aash | ||||
| Component: | jst.j2ee | Assignee: | Rob Stryker <stryker> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Chuck Bridgham <cbridgha> | ||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | ahfeel+eclipse, andrey.melentyev, ccc, jasonpet, larryisaacs, stryker, thatnitind | ||||
| Version: | 3.2 | Flags: | cbridgha:
review+
|
||||
| Target Milestone: | 3.2.3 | ||||||
| Hardware: | Macintosh | ||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
aash
Do you really mean Tomcat server restarts, or does Tomcat just reload the affected webapp? If just reloading, try creating a new Dynamic Web Project and sprinkle a few HTML, CSS, and JS files in it. Then see if this "test" project exhibits the same behavior. There may be a utility project dependency of your web project that is always rebuilding its jar during publishing. This could trigger Tomcat's auto-reload feature. (In reply to comment #1) > Do you really mean Tomcat server restarts, or does Tomcat just reload the > affected webapp? If just reloading, try creating a new Dynamic Web Project and > sprinkle a few HTML, CSS, and JS files in it. Then see if this "test" project > exhibits the same behavior. There may be a utility project dependency of your > web project that is always rebuilding its jar during publishing. This could > trigger Tomcat's auto-reload feature. Yes, I meant reload the webapp instead of restarting. Sorry for not being precise. I created a new project, and everything worked as it should. Then I added a dependent project "common" to the build path, and to the Deployment Assembly (Project -> then selected project common). Now when I edit a css, etc, the context reloads: {{ Sep 30, 2010 11:57:26 AM org.apache.catalina.core.StandardContext reload INFO: Reloading this Context has started Hello servlet loaded. }} There was a problem in the past where some Java EE handling was "monkeying" with the MANIFEST.MF that was going into the jar built for the utility project (see Bug 251262 for details). It made the utility project appear to be perpetually modified. It's possible a new version of this issue is the source of this behavior. Can you check the published jar's MANIFEST.MF and any MANIFEST.MF in your "common" project to see if they are different, especially the Classpath attribute. (In reply to comment #3) > There was a problem in the past where some Java EE handling was "monkeying" > with the MANIFEST.MF that was going into the jar built for the utility project > (see Bug 251262 for details). It made the utility project appear to be > perpetually modified. It's possible a new version of this issue is the source > of this behavior. Can you check the published jar's MANIFEST.MF and any > MANIFEST.MF in your "common" project to see if they are different, especially > the Classpath attribute. I don't have a MANIFEST.MF in my project, but the one created by eclipse is: Manifest-Version: 1.0 Class-Path: commons-codec-1.3.jar commons-httpclient-3.1.jar commons-l ogging-1.1.1.jar httpcore-4.0.jar httpcore-nio-4.0.jar servlet.jar pe rsistence-api-1.0.jar xercesImpl.jar mysql-connector-java-5.1.8-bin.j ar jakarta-oro-2.0.8.jar gson-1.3.jar I'm not sure how the absence of a MANIFEST.MF in your project might affect the behavior of the code added for Bug 251262. Try creating a META-INF folder in your Java source folder and add a MAINIFEST.MF there with the default content of: Manifest-Version: 1.0 Class-Path: Then see if the jar stops rebuilding. Hopefully, it will rebuild one more time after this change, then stop rebuilding for future publishes. Note you don't have to have Tomcat running to test the rebuilding. Just do a publish and see if timestamp on the jar changes (assuming at least a minute has passed). (In reply to comment #5) > I'm not sure how the absence of a MANIFEST.MF in your project might affect the > behavior of the code added for Bug 251262. Try creating a META-INF folder in > your Java source folder and add a MAINIFEST.MF there with the default content > of: > > Manifest-Version: 1.0 > Class-Path: > > Then see if the jar stops rebuilding. Hopefully, it will rebuild one more time > after this change, then stop rebuilding for future publishes. Note you don't > have to have Tomcat running to test the rebuilding. Just do a publish and see > if timestamp on the jar changes (assuming at least a minute has passed). Ok, so I added a META-INF to my java src dir, and put in it a MANIFEST.MF and a mytest.xml... when i look in build/classes i see a META-INF dir, and in that META-INF is MANIFEST.MF and mytest.xml, as expected. However, when eclipse rebuilds the common.jar ('common' is the project), the mytest.xml is in the jar, but the MANIFEST.MF isn't the same! It seems like eclipse is rebuilding that MANIFEST.MF. I copied the exact MANIFEST.MF that eclipse creates over to it, and it still causes the restarts. (of course, you can't tell if eclipse was recreating it, or just using it) So then, I then added Main-Class: com.company.util.Test to the MANIFEST.MF, and it gets copied to build/classes, but still doesn't make it into the common.jar that wst sees. (I also tried several iterations of trying to make the Deployment Assembly and Java Build Path entries do the work for me, but to no avail.) So it seems like the issue is that eclipse is always creating a new MANIFEST.MF? Inspecting source code, it appears the code to address Bug 251262 was removed in revision 1.2 of the org.eclipse.jst.common.internal.modulecore.util.ManifestUtilities.java file. In answer to the comment in revision 1.1, * TODO: why do we check if the file already exists? We should just output to * the file and get rid of this manifestClasspaths map. Utility projects appear perpetually modified with out it, which causes the the behavior in this bug. Sorry for not noticing this regression sooner. Updating product and component. Larry, it would appear the Rob was unfamiliar with the reason for the checking of the MANIFEST.MF's existance/changes. Can you add the check back in? Created attachment 180185 [details]
Patch to restore checking to avoid perpetually modified manifests
Since I don't think I have commit privileges for this code, redirecting back to relevant component. Opps, I mean assign it someone who can commit the code, i.e. Rob. I included comment this time to make it clearer why this checking is present. Rob, if you think of a better what to accomplish this, feel free to try something different. Correction: /what/way/ The patch doesn't look offensive to me. I'd be glad to commit after permission approved Committed this to both streams *** Bug 327431 has been marked as a duplicate of this bug. *** *** Bug 328685 has been marked as a duplicate of this bug. *** |