Bugzilla – Full Text Bug Listing
| Summary: | need to adjust to restrictions in help plugin | ||
|---|---|---|---|
| Product: | [WebTools] WTP Java EE Tools | Reporter: | David Williams <david_williams> |
| Component: | jst.j2ee | Assignee: | jst-inbox <jst-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | blocker | ||
| Priority: | P3 | CC: | cbrealey, curtispd, Florian.Muller, gilberta, kathy, Mike_Wilson, pradeepbhargav, p_saville, simon_kaegi, sojoknuckle, thatnitind, wbeckwith |
| Version: | unspecified | ||
| Target Milestone: | 1.5 RC1 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 111985 | ||
|
Description
David Williams
*** Bug 136952 has been marked as a duplicate of this bug. *** David, from the standpoint of the Web services component, specifically the Web Services Explorer (and you got the name right), I wasn't feeling all that embarrased about our use of the Help system's Web App launch mechanism, and bug 31837 should help explain why. Note that the JspC compiler used by the WSE's build-war.xml script and the servlet classes the WSE itself depends on are (or were) being drawn from the Tomcat plugin, not the Help plugin. Will you be adding org.eclipse.equinox.servlet.api to our builds, as part of WST (not JST) - See item #1 below :) - So that we can try to raise the WSE from the ashes? This would seem to be the first step. I suspect our build-war.xml JspC build script will continue to work just fine since it pumps jars, not plugins as such, directly into the hands of Ant. Adding a dependency on org.eclipse.equinox.servlet.api may be all we need. Re. your exploration of the code, a few comments to consider: 1. The WSE is a WST component, not a JST component. It provides purely XML oriented support for publishing, discovering and invoking Web services. There is nothing J2EE about what it does, and we need to be careful not to confuse the scope of the tool (Web with not a hint of Java) from how it is implemented (servlets). The org.eclipse.equinox.servlet.api plugin provides classes that the developer of a Web based Eclipse tool (like the WSE or the Help system) would need, and does not itself constitute Eclipse WTP JST end-user tooling. 2. The WSE is almost, but not quite, standalone. It actually does integrate with Eclipse API and cannot be built without it, and relies on the "development time" Eclipse VM. For example, there are links in the WSE that cause it to save and load resources using the Eclipse resource API, still other links in the WSE that cause it to launch our Web service wizards, and services of lower level Eclipse WTP Web service plugins (eg. org.eclipse.wst.ws) the WSE calls. In a nutshell, the WSE was designed many moons ago to run as an "integrated Eclipse Web app". For better or worse, in theory or in practice, it can't be built simply as a standalone Web app. All that said, we may get there one day (see RFE bug 89101), but not in WTP 1.5. Thanks, Chris, for all the background. I have not had a chance to look too deep, but, seems to me the web app in org.eclipse.wst.ws.explorer is the *only* think that needs the servlet API? Its not like its part of your "interface" to others, right? So, perhaps easiest fix is to have you do exactly what the help system was doing (and still is, in some form) ... have the jar in your plugin, add is as an "extra classpath" entry for the build. I'm not sure if your custom build scripts will need to be updated or (hopefully) they are set up so they'll magicaly pick all this up without change. I would still like to have an equinox servlet api bundle in JST (seem appropriate there ... guess it was just us in JSP land that should have been embarrased :) FYI, I've added the jar to wsexplorer, added the extrapasspath entry, and released for a "blind" build. (That is, I did not modify any of your custom build scripts .. if you need that ... you'll have to call in the ant experts :) I've versioned it as v200604171515 So, if you need to revert, feel free. BTW, does wsexplorer-src actually need to be part of the Eclipse's proejcts source folder? Or, was that doen as a convenience? Sort of an "embedded" proeject? No biggy, but that did seem the only source that required the tomcat api. Hi David, I'd like to try and help if I can. I'm trying to do a build here to make sure everything is working alright. What I've done is modified the org.eclipse.jst.jsp.core plugins' manifest to: 1) removed the org.eclipse.tomcat from the Require-Bundle section. 2) added Import-Package: javax.servlet.jsp.tagext; version="1.2.0" Are any other plugins affected? (I noticed the axis plugin which maybe needs updating?) -- Chris, I suspect that at least in the short term your build will still need to reference the tomcat plugin (which still contains all the various jars) because you need a lot more than just what equinox servlet api contains. As you mentioned, you're just using the jars and shouldn't be affected at build time. (In reply to comment #5) > > I'd like to try and help if I can. > Those are the sweetest words I love to hear! :) [its been a rough day :) ] Given that the latest build has its "access" warnings back low, http://download.eclipse.org/webtools/committers/ I'd say that my "quick and dirty" build tricks may be working ... But, since Junit tests are not working, I have no idea if its a correct build. So, feel free to give the last "committer and early tester" build a shake. http://download.eclipse.org/webtools/committers/drops/S-1.5RC1-200604171924/ The basics are working for me too ... using Eclipse RC1 SDK with the build you mentioned. I'm still a bit suspicious of the Axis component and am a bit concerned if it needs to reference anything from the Servlet API it'll get ClassNotFounds. I'll try a few things myself, but if you know of an easy way to "really" exercise the axis stuff I could try that out. Chris, Simon's right ... org.apache.axis had
org.eclipse.tomcat
in it manifest, and if someone really was tryng to use it, they
would get a runtime (access) exception.
However, I removed it from the manifest.mf (no compile errors, as you'd expect, since that we don't compile anything! in org.apache.axis) and a text search shows it is no where else in our plugins -- my guess is someone put it in accidently.
So, I'll remove from org.apache.axis, and if really was needed somehow, will still be a runtime error, but now "class not found" ... and I think only would be if there is odd special introspected class loading going on ... perhaps someone is using Class.forName("org." + "eclipse" + "tomcat"...) ... oh, my "bad jokes" have hit an all time low :)
BTW, I have opened bug 137108 to track some work we in WTP should to to inspect our other 3rd party plugins ... especially those which "contain" other jars! As a good example, Chris and team rightfully to not listed the "common-logging" jars that are part of Axis ... otherwise, it would be bug 136954 all over again :) *** Bug 137470 has been marked as a duplicate of this bug. *** *** Bug 137726 has been marked as a duplicate of this bug. *** As far as I can tell we're done, at least with the "adjustment" part of this issue. All seems in order. (any new issues found should have new bugs opened). FYI, the "IP process" part of (re)using the org.eclipse.equinox.servlet.api bundle has been captured in bug 128808. Thanks everyone for your help reacting and resolving this. *** Bug 138392 has been marked as a duplicate of this bug. *** *** Bug 139306 has been marked as a duplicate of this bug. *** Closing. I was linked over here from bug 137726. I have the exact same problem described there...if I edit a JSP file, I get a constant error about NoClassDefFoundError. I read through all of the discussion here, and although it was rather interesting, I didn't see what I as an end-user of Eclipse needed to do to fix the problem. Do I need to throw the servlet-api.jar file in my classpath or something? Please advise as to the corrective course of action... |