Community
Participate
Working Groups
Created attachment 221036 [details] A fragment bundle built using the following bnd file allowed the successfull generation of jsp files org.apache.jasper.glassfish is missing imports of: javax.xml.parsers javax.xml.transform org.w3c.dom org.w3c.dom.ls org.xml.sax org.xml.sax.helpers (and perhaps others) Bundle-Version: 2.2.2.v201112011158 Implementation: equinox (juno) Other dependencies: satisfied (bundle starts and executes without "other" errors)
Created attachment 221059 [details] possible fix Analyzing the class files I came up with the attached patch that adds the necessary imports. I made the ant dependencies optional since we don't use ant tasks provided by jasper in our usage scenarios. I am not sure about the javax.annotation.processing or java.lang.model* packages. I assume these are being used by the copy of ecj we have in the orbit bundle. I am not sure what cases these packages are necessary or if they can be optionally imported. That being said, I don't think it is a problem to make these packages mandatory since these packages are included in JavaSE-1.6 and that is the minimum execution environment for the org.apache.jasper.glassfish bundle anyway.
Looks good to me. Hugues, want to try for Kepler M2? (i.e. in 1 day :/ Also, there is a version 2.1.0 still in active builds that might need similar analysis/changes? Tom, what did you use to "analyze the class files"? I used to use "depends" or something named similar but wonder if there's something better. Or, maybe you just look at with hex editor :) Hugues, it'd be good to update your email in the ip_log xml files as it appears to have changed. Thanks all.
(In reply to David Williams from comment #2) > Tom, what did you use to "analyze the class files"? I used to use "depends" > or something named similar but wonder if there's something better. Or, maybe > you just look at with hex editor :) Wish I could recall for sure. I think I used a bnd tool. Or perhaps I imported the jar as a bundle into PDE and had it calculate the imports.
(In reply to Thomas Watson from comment #3) > (In reply to David Williams from comment #2) > > > Tom, what did you use to "analyze the class files"? I used to use "depends" > > or something named similar but wonder if there's something better. Or, maybe > > you just look at with hex editor :) > > Wish I could recall for sure. I think I used a bnd tool. Or perhaps I > imported the jar as a bundle into PDE and had it calculate the imports. Sorry Tom .. and Raymond. I am just not seeing it. I tried 3 things to try to confirm these were needed, but none of them panned out. Which is not to say I haven't made an error, somewhere, but ... I do at least want to ask "... are you sure?" First I looked at the org.apache.jasper.glassfish bundle used by Jetty 8.x (latest) distribution ... thinking maybe they did the same or similar thing. But, no. pretty much just like ours. (now that we've added the optional JDT core imports). Next, I used "jdeps" (which comes with Java 8) to see what each package requires ... but could not "see" the requirements that are in the patch. (Granted, that is "just java" (not OSGi) but ... I've used it before and it does help find "top level" missing packages ... which, I think is all we need? Next, I used Eclipse itself, imported in various ways, and computed dependencies in various ways, but it never came up with any differences? I will say, the version that is in CVS right now (and has been for a while) has a requirement on Java 5, in the .classpath -- even though the bundle says "Java 6". I will correct that mistake soon (fixing .classpath) but I wonder if that somehow tainted your earlier results? Especially with bnd? (I did not try that) ... but, I did try, with PDE and 'jdeps' using Java 6 and Java 5, and in neither case did it say I needed more. So, either I don't know how to tell ... or ... the Java 5/6 issue messed things up ... or ... something. Are you sure? ... we need this change? (And, if so, can you account for why I don't see it, but you do?)
Oh, this wouldn't be one of the "Vendor" issues would it? I was using Oracle VM in all cases. Were you using IBM's?
(In reply to David Williams from comment #5) > Oh, this wouldn't be one of the "Vendor" issues would it? I was using Oracle > VM in all cases. Were you using IBM's? The VM used didn't seem to matter. (i.e. got same non-results). I've only one more guess ... I am wondering if "bnd' treats the files as a "pseudo feature" and "gathers" everything needed, even by "required" bundles, if the "required" bundles do no contain what they should? Also, the .classpath was incorrect for the bundle in CVS, still saying "1.5" instead of the correct "1.6" -- I've just fixed, as part of bug 442310 -- but, if bnd uses the .classpath, that would certainly give incorrect results.
Gunnar, you are a "big bnd" user, right? If easy for you, was wondering if 1) you'd be willing to double check with bnd to see that it adds to MANIFEST.MF, and 2) if different from what all these other methods find, if you'd be able to explain it?
(In reply to David Williams from comment #7) > Gunnar, you are a "big bnd" user, right? Well, let's put it this way: I realized using bnd is much more reliable for computing packages to import as well as "uses" clauses than PDE that I do trust it more. > If easy for you, was wondering if 1) you'd be willing to double check with > bnd to see that it adds to MANIFEST.MF, and 2) if different from what all > these other methods find, if you'd be able to explain it? For 1) I check the org.apache.jasper.glassfish 2.2.2 bundle published by the Jetty team. It came up with the following. -------------------------- Import-Package: javax.el javax.servlet javax.servlet.descriptor javax.servlet.http javax.servlet.jsp javax.servlet.jsp.el javax.servlet.jsp.tagext javax.tools javax.xml.parsers javax.xml.transform javax.xml.transform.dom javax.xml.transform.stream javax.xml.validation org.eclipse.jdt.core.compiler org.eclipse.jdt.internal.compiler org.eclipse.jdt.internal.compiler.classfmt org.eclipse.jdt.internal.compiler.env org.eclipse.jdt.internal.compiler.problem org.w3c.dom org.w3c.dom.ls org.xml.sax org.xml.sax.ext org.xml.sax.helpers Export-Package: org.apache.jasper uses: javax.servlet javax.servlet.jsp.tagext org.apache.jasper.compiler org.apache.jasper.runtime org.apache.jasper.servlet org.apache.jasper.compiler uses: javax.el javax.servlet javax.servlet.jsp.tagext javax.tools org.apache.jasper org.apache.jasper.compiler.tagplugin org.apache.jasper.servlet org.xml.sax org.apache.jasper.compiler.tagplugin org.apache.jasper.resources org.apache.jasper.runtime uses: javax.el javax.servlet javax.servlet.http javax.servlet.jsp javax.servlet.jsp.el javax.servlet.jsp.tagext org.apache.jasper org.glassfish.jsp.api org.apache.jasper.security org.apache.jasper.servlet uses: javax.servlet javax.servlet.descriptor javax.servlet.http javax.servlet.jsp.tagext org.apache.jasper org.apache.jasper.compiler org.apache.jasper.tagplugins.jstl uses: org.apache.jasper.compiler.tagplugin org.apache.jasper.xmlparser uses: org.apache.jasper org.apache.jasper.compiler org.w3c.dom org.xml.sax org.glassfish.jsp.api uses: javax.servlet.jsp.tagext -------------------------- As for 2), the differences between PDE and bnd are (I'm 100% certain on this) deficiencies in PDE when calculating imports. (In reply to Thomas Watson from comment #1) > Created attachment 221059 [details] > possible fix The patch created by Thomas contains additional imports (Ant, javax.annotation.*, javax.lang.model.*). The Jetty version doesn't seem to contain the ECJ compiler. I did use the download published by Jetty in Maven: http://mvnrepository.com/artifact/org.eclipse.jetty.orbit/org.apache.jasper.glassfish/2.2.2.v201112011158.
Thanks Gunnar, I'm not 100% convinced :) but also comparing to jetty's version would give different results, since they don't have embedded JDT. So ... what I'll do is take Tom's "possible fix" patch, and if/when anyone finds other issues, please open a new bug. Even though this is a "minor" bug, the change will be in Luna SR2, since it will be part of the "blocker" bug 442310.
I am "backing out" this fix, since it seems to cause trouble for consumers, by adding new dependencies. That should be avoided, especially in maintenance streams.
Doing a mass "reset to default assignee" of 21 bugs to help make clear it will (very likely) not be me working on things I had previously planned to work on. I hope this will help prevent the bugs from "getting lost" in other people's queries. Feel free to "take" a bug if appropriate.
It is also missing javax.servlet.jsp.resources as pointed out in https://java.net/projects/glassfish/lists/users/archive/2014-04/message/21 Overall ... i checked out the source in Neon.2 and there are several build errors it is missing e.g. an import-package on * org.apache.tools.ant * org.apache.tools.ant.taskdefs * org.apache.tools.ant.types for org.apache.jasper.compiler.AntJavaCompiler to even compile! Same goes for org.apache.jasper.runtime.PerThreadTagHandlerPool which misses the Tag class import! What is the state of this?! I got this from Neon.2 and it has all this errors?!
I'm not sure that anyone is actually looking at this. The issue isn't linked to any JSP related bug in Equinox. Thus, I think it's best to close it as "cannot do" unless someone shows up with a new recipe.
I am not sure, whether such a bug report would be required. As described in https://www.eclipse.org/forums/index.php/t/1085156/ I was trying to get JSTL with JSP in osgi jetty up an running - and horribly failed after >10h of trying. During my attempts, this was one of the things that seemed to just not fit?! So currently I am trying to get any information on whether anybody managed to use JSLT/JSP in osgi jetty at all!
