Jakarta Server Pages
Home Page: http://eclipse.org/ee4j/jsp
License: Other
This repository contains the code for Jakarta Pages.
Note that this concerns the API only. An implementation is needed in addition to this.
Jakarta Pages can be built by executing the following from the project root:
mvn clean package
The API jar can then be found in /api/target and the specification document in /spec/target.
To make changes, fork this repository, make your changes, and submit a pull request.
Jakarta Pages defines a template engine for web applications.
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
Last CTS runs indicate no failures in this component. It's time to make a public release. Before the release make sure that Eclipse Release Review is passed and all dependencies have been released.
JDTCompiler currently depends on the eclipse java compiler 3.1.1 which was
released in September 2005.
That version of the eclipse java compiler is packaged as an eclipse plugin.
It works as a jar but it cannot be loaded in an OSGi container: its manifest
declares mandatory dependencies on various eclipse-rcp-plugins.
Starting with eclipse-3.2.0, the java compiler is provided as a new osgi bundle
that has no dependencies at all. It is packaged as ecj.jar. Its symbolic name is
"org.eclipse.jdt.core.compiler.batch"
When it is used as a replacement of core-3.1.1.jar jasper throws this exception:
java.lang.NoSuchMethodError:
org.eclipse.jdt.internal.compiler.CompilationResult.getProblems()[Lorg/eclipse/jdt/core/compiler/IProblem;
at
org.apache.jasper.compiler.JDTJavaCompiler$2.acceptResult(JDTJavaCompiler.java:442)
at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:417)
at
org.apache.jasper.compiler.JDTJavaCompiler.compile(JDTJavaCompiler.java:503)
at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:368)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:437)
at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:608)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:360)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:486)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:380)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
It is because of line 420:
IProblem[] problems = result.getProblems();
result.getProblems() returns CategorizedProblem[] since 3.2.0.
With 3 trivial changes to JDTCompiler it is possible to fix this issue and make
JDTCompiler compatible with all versions of the eclipse compiler including 3.1.1
and 3.5.0
This will also help make jasper more easily executed by OSGi containers if ecj
becomes a recommended implementation of the eclipse compiler.
Here is the jetty bug where we started to work on this issue for your reference:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=289406
Operating System: All
Platform: All
[current]
Failed to compile jsp files in which custom tags are nested.
In this jsp, following custom tags are used.
**MyTag.tld**<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE taglib
PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2//EN"
"http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd"> <taglib>
<tlib-version>1.0</tlib-version>
<jsp-version>1.2</jsp-version>
<short-name>sample</short-name>
<tag>
<name>sample</name>
<tag-class>sample.SampleTag</tag-class>
<tei-class>sample.SampleTagExtraInfo</tei-class>
<body-content>JSP</body-content>
<attribute>
<name>sampleVarStr</name>
<required>false</required>
</attribute>
<attribute>
<name>sampleVarInt</name>
<required>false</required>
</attribute>
<attribute>
<name>sampleVarArray</name>
<required>false</required>
</attribute>
<attribute>
<name>sampleVarUserCls</name>
<required>false</required>
</attribute>
</tag>
</taglib>
**index.jsp**<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>test</title>
</head>
<body>
<H1>test</H1>
<s:sample>
layer 0: java.lang.String:<%= sampleVarStr %><br>
layer 0: java.lang.Integer:<%= sampleVarInt %><br>
layer 0: Array:<%= sampleVarArray[0] + sampleVarArray[1] %><br>
layer 0: User Defined:<%= sampleVarUserCls.getString() %><br>
<hr>
<s:sample>
layer 1: java.lang.String:<%= sampleVarStr %><br>
layer 1: java.lang.Integer:<%= sampleVarInt %><br>
layer 1: Array:<%= sampleVarArray[0] + sampleVarArray[1] %><br>
layer 1: User Defined:<%= sampleVarUserCls.getString() %><br>
<hr>
<s:sample>
layer 2: java.lang.String:<%= sampleVarStr %><br>
layer 2: java.lang.Integer:<%= sampleVarInt %><br>
layer 2: Array:<%= sampleVarArray[0] + sampleVarArray[1] %><br>
layer 2: User Defined:<%= sampleVarUserCls.getString() %><br>
<hr>
<s:sample>
layer 3: java.lang.String:<%= sampleVarStr %><br>
layer 3: java.lang.Integer:<%= sampleVarInt %><br>
layer 3: Array:<%= sampleVarArray[0] + sampleVarArray[1] %><br>
layer 3: User Defined:<%= sampleVarUserCls.getString() %><br>
<hr>
</s:sample>
</s:sample>
</s:sample>
</s:sample>
</body>
</html>
**SampleTag.java**package sample;
import javax.servlet.jsp.JspException;
import javax.servlet.jsp.tagext.TagSupport;
import sample.MyClass;
public class SampleTag extends TagSupport {
public String getSampleVarStr() {
return sampleVarStr;
}
public Integer getSampleVarInt() {
return sampleVarInt;
}
public String[] getSampleVarArray() {
return sampleVarArray;
}
public MyClass getSampleVarUserCls() {
return sampleVarUserCls;
}
private String sampleVarStr = "";
private Integer sampleVarInt = Integer.valueOf(0);
private String[] sampleVarArray = null;
private MyClass sampleVarUserCls = null;
public int doStartTag() throws JspException {
this.pageContext.setAttribute("sampleVarStr", "java.lang.String");
this.pageContext.setAttribute("sampleVarInt", new Integer(99999));
this.pageContext.setAttribute("sampleVarArray", new String[]{"script variable", "array"});
this.pageContext.setAttribute("sampleVarUserCls", new MyClass("script variable:user defined"));
return 1;
}
public void setSampleVarStr(String varstr) {
this.sampleVarStr = varstr;
}
public void setSampleVarInt(Integer varint) {
this.sampleVarInt = varint;
}
public void setSampleVarArray(String[] vararray) {
this.sampleVarArray = vararray;
}
public void setSampleVarUserCls(MyClass varusercls) {
this.sampleVarUserCls = varusercls;
}
}
**SampleTagExtraInfo.java**package sample;
import javax.servlet.jsp.tagext.TagData;
import javax.servlet.jsp.tagext.TagExtraInfo;
import javax.servlet.jsp.tagext.VariableInfo;
public class SampleTagExtraInfo extends TagExtraInfo {
public VariableInfo[] getVariableInfo(TagData data) {
return new VariableInfo[]{new VariableInfo("sampleVarStr", "java.lang.String", true, 1),
new VariableInfo("sampleVarInt", "java.lang.Integer", true, 1),
new VariableInfo("sampleVarArray", "java.lang.String[]", true, 1),
new VariableInfo("sampleVarUserCls", "sample.MyClass", true, 1)};
}
}
**MyClass.java**package sample;
public class MyClass {
String s;
public MyClass(String str) {
this.s = str;
}
public String getString() {
return this.s;
}
public void setString(String s) {
this.s = s;
}
}
This is the patch for this problem.
**org.apache.jasper.compiler.Generator.java saveScriptingVars** if (varInfos.length > 0) {
for (int i = 0; i < varInfos.length; i++) {
if (varInfos[i].getScope() != scope)
continue;
// If the scripting variable has been declared, skip codes
// for saving and restoring it.
if (n.getScriptingVars(scope).contains(varInfos[i]))
continue;
String varName = varInfos[i].getVarName();
String tmpVarName = JspUtil.nextTemporaryVariableName();
n.setTempScriptingVar(varName, tmpVarName);
out.printin(varInfos[i].getClassName());
+ out.print(" ");
out.print(tmpVarName);
out.print(" = ");
out.print(varName);
out.println(";");
}
} else {
for (int i = 0; i < tagVarInfos.length; i++) {
if (tagVarInfos[i].getScope() != scope)
continue;
// If the scripting variable has been declared, skip codes
// for saving and restoring it.
if (n.getScriptingVars(scope).contains(tagVarInfos[i]))
continue;
String varName = tagVarInfos[i].getNameGiven();
if (varName == null) {
varName =
n.getTagData().getAttributeString(
tagVarInfos[i].getNameFromAttribute());
} else if (tagVarInfos[i].getNameFromAttribute() != null) {
// alias
continue;
}
String tmpVarName = JspUtil.nextTemporaryVariableName();
n.setTempScriptingVar(varName, tmpVarName);
- out.printin("String ");
+ out.printin(tagVarInfos[i].getClassName());
+ out.print(" ");
out.print(tmpVarName);
out.print(" = ");
out.print(varName);
out.println(";");
}
}
[current]
The jsp-api-2.1 jar dependency in the pom does not incorporate the changes
to javax.el.ExpressionFactory that is present in the glassfish sources,
resulting in a compilation error on javax.el.ExpressionFactory.newInstance().
Operating System: All
Platform: All
[current]
An undefined EL identifier in a JSP page has a default value of "", making it difficult to debug EL expressions evaluation in s JSP page. The spec should allow an option to raise an error in this case.
The RI should also be fixed to send back a message in the response in this case. The message should include the offending EL expression and undefined identifier.
EL 3.0 requires JSP to support referenced static fields for imported classes. However, this point has not been included in the JSP spec. and might need to be included. Also, the behavior is not backward compatible with previous versions of the JSP spec. and a switch may be needed to allow backward compatibility avoiding any undesirable behavior or performance differences.
The following class is handling the static fields: javax.servlet.jsp.el.ScopedAttributeELResolver
With the jspc command, custom tag pooling is always enabled.
For some applications it would be nice if it were possible to disable tag pooling.
Operating System: All
Platform: All
[current]
Dongbin Nie:
EL 3.0 Spec says: "When a lambda expression is assigned, it can be referenced and invoked indirectly, ■ v = (x,y)->x+y; v(3,4) evaluates to 7”,
in order to support this lambda expression feature in JSP, the JSP compiler need to relax the compilation time validation rule for function described in JSP.2.10.4 Semantics:"• If the function has no prefix, the default namespace is used. If the function has
a prefix, assume the namespace as that associated with the prefix.
Let ns be the namespace associated with the function, and f be the name of the
function.
• Locate the TLD associated with ns. If none can be found, this shall be a translation-
time error.
• Locate the function element with a name subelement with value f in that TLD.
If none can be found, this shall be a translation-time error."I find Glassfish’s Jasper compiler had already done this, so will the JSP Specification be updated to conform this EL lambda feature in future?
javax.servlet.jsp version 2.3.4
Running with a system security manager results in an ClassNotFound exception, as the JspRuntimeLibrary$PrivilegedIntrospectHelper class has been removed. This occurs during the boot process when the JspServlet is initialised. A stack trace is attached.
stacktrace.log
The javax.servlet.jsp-api-2.3.0 jar in maven central repo released on 12 January does not contain any dtds or xsds. There does not appear to be any other jsp related jar from which to obtain them.
[current]
Uptake new Eclipse versions of dependencies (if any). Use GlassFish 5.1 Release Tracker wiki to find components versions to use.
Release to OSSRH staging repository
Update GlassFish 5.1 Release Tracker with released version number.
I think that there is a bug in either the JSP API docs for javax.servlet.jsp.JspFactory.getPageContext().
The API Docs for JspFactory.getPageContext() states this for the buffer arg.
buffer - size of buffer in bytes, PageContext.NO_BUFFER if no buffer, PageContext.DEFAULT_BUFFER if implementation default.
The above should be changed to JSPWriter.NO_BUFFER and JSPWriter.DEFAULT_BUFFER.
NA
[current]
Dependency eclipse-jdtcore-2.1.0 needs to be updated to 3.1.0 (or higher) to
compile successfully if JDTJavaCompiler needs is included in the compilation.
Operating System: All
Platform: All
[current]
During a wider discussion on the Servlet EG mailing list [1], it was observed that the JSP specification implies that containers override HttpServlet.service() for JSPs rather than the individual doXxx() methods. This creates problems when applications apply different security constraints to different HTTP verbs as JSPs will respond to any verb - potentially bypassing the security constraint.
A very useful addition to the JSP specification would be a mechanism to control which HTTP verbs a JSP should respond to.
My first idea for implementing this is as a page directive. Something along the lines of:
<@page httpMethods="GET,HEAD,POST" %>
with a corresponding support in web.xml such as
<jsp-property-group>
<http-methods>GET,HEAD,POST</http-methods>
...
</jsp-property-group>
My initial thoughts for a default value is "GET,HEAD,POST"
This is an initial idea of how this could be implemented. I'm sure there are other ways to achieve the same result.
Mark
[1] http://java.net/projects/servlet-spec/lists/jsr340-experts/archive/2012-09/message/8
The project web page has a link to an old URL for getting the sources. I selected Webtier->JSP from
From there, on the section "Get Involved" is a link "building". Clicking on that, got me to:
http://jsp.java.net/build.html
This is the incorrect page. Using the navigation menu on the left and chosen the "Subversion repository" link navigates to the correct place.
Rather than have a hard code dependency on ant via the AntJavaCompiler, it could
perhaps be loaded dynamically, like the JDT java compiler. That way, the number
of jar dependencies for Jasper could be reduced a little, as it would be
possible to distribute either the eclipse jdt jar or the ant jar (or even
neither if using jdk1.6) , but not both.
regards
Jan
Operating System: All
Platform: All
[current]
Passing Release Review is a required step before making a first public release. Deadline for passing the review is Nov 30th, 2018. Release review takes some time to complete, so it makes sense initiating it as soon as possible.
Additional information:
When a JSP page is interwoven with JSF snippets it calls PageContext.getOut().flush() to stream out the part already processed. This is supposed to make sure the response is already partially written back to the browser. This however does not seem to be done when the flush is called, and thus it causes an error to be propagated where it should not have been.
All current API libraries shipped must be distributed to Maven Central under a sub-package of the jakarta groupId. Before the first release Maven coordinates of this project must be changed as it's described here.
The same issue has already been fixed in Tomcat's Jasper:
https://issues.apache.org/bugzilla/show_bug.cgi?id=55552
http://svnsearch.org/svnsearch/repos/ASF/search?revision=1522512
The coercion rules changed in EL 3.0, causing a null value of expected type java.lang.Boolean to be returned as null instead of coerced to a Boolean.TRUE.
JspUtil.interpreterCall needs an update to reflect this. I'll attach a patch with a proposed solution based in Tomcat's fix.
This is a place holder issue for Pull request from javaee/javaee-jsp-api#58
Add setExpressionFactory method to JspApplicationContextImpl
the packages: com/sun/appserv, com/sun/common/, com/sun/el/ and
com/sun/org/apache/commons/logging/* need to be on the classpath at runtime - is
this a dependency that can be removed to make the jsp module more generic?
Operating System: All
Platform: All
[current]
Hi,
Could you help me by answering the following questions about jsp-api library:
Is the library compatible with Java 11 ? (Y/N)
Is the library supported with Java 11? (Y/N)
(If “N” in compatibility or support) What is the version that would be compatible and Supported?
Date of support availability?
Thanks
The generated jar doesn't seem to include the property files, which results
in runtime errors eg org/apache/jasper/resources/messages.properties is missing.
Operating System: All
Platform: All
[current]
Currently the JSP impl and api are set to source/target 1.7
However, there are no functional requirement or features of the 1.7 JRE used.
The only current problem is that javax.el project is currently also compiled at 1.7 and this poses a build problem for this api/impl.
However, after experimentation, there seems to be also no cause for el to be at 1.7.
See EL_SPEC-20
[milestone 1]
cd api
maven clean install
results in a bunch of Javadoc errors. These need fixing.
The Java EE 8 signature tests failed for the following JSP related packages.
javax.servlet.jsp.el(static mode)
javax.servlet.jsp.el(reflection mode)
javax.servlet.jsp(static mode)
javax.servlet.jsp(reflection mode)
javax.servlet.jsp.tagext(static mode)
javax.servlet.jsp.tagext(reflection mode)
The failures seems to be caused due to the usage of Generics in API methods contained in jar files - jakarta.servlet.jsp-api.jar
javax.servlet.jsp.JspContext: getExpressionEvaluator():anno 0 java.lang.Deprecated()
--- affected javax.servlet.jsp.PageContext
javax.servlet.jsp.JspContext: getVariableResolver():anno 0 java.lang.Deprecated()
--- affected javax.servlet.jsp.PageContext
javax.servlet.jsp.JspException: getRootCause():anno 0 java.lang.Deprecated()
--- affected javax.servlet.jsp.SkipPageException,javax.servlet.jsp.JspTagException
javax.servlet.jsp.el.ExpressionEvaluator: method public abstract java.lang.Object javax.servlet.jsp.el.ExpressionEvaluator.evaluate(java.lang.String,java.lang.Class,javax.servlet.jsp.el.VariableResolver,javax.servlet.jsp.el.FunctionMapper) throws javax.servlet.jsp.el.ELException
javax.servlet.jsp.el.ExpressionEvaluator: method public abstract javax.servlet.jsp.el.Expression javax.servlet.jsp.el.ExpressionEvaluator.parseExpression(java.lang.String,java.lang.Class,javax.servlet.jsp.el.FunctionMapper) throws javax.servlet.jsp.el.ELException
javax.servlet.jsp.el.ImplicitObjectELResolver: method public java.lang.Class javax.servlet.jsp.el.ImplicitObjectELResolver.getType(javax.el.ELContext,java.lang.Object,java.lang.Object)
javax.servlet.jsp.el.ExpressionEvaluator: method public abstract java.lang.Object javax.servlet.jsp.el.ExpressionEvaluator.evaluate(java.lang.String,java.lang.Class,javax.servlet.jsp.el.VariableResolver,javax.servlet.jsp.el.FunctionMapper) throws javax.servlet.jsp.el.ELException
javax.servlet.jsp.el.ExpressionEvaluator: method public abstract javax.servlet.jsp.el.Expression javax.servlet.jsp.el.ExpressionEvaluator.parseExpression(java.lang.String,java.lang.Class,javax.servlet.jsp.el.FunctionMapper) throws javax.servlet.jsp.el.ELException
javax.servlet.jsp.el.ImplicitObjectELResolver: method public java.lang.Class<?> javax.servlet.jsp.el.ImplicitObjectELResolver.getType(javax.el.ELContext,java.lang.Object,java.lang.Object)
javax.servlet.jsp.el.ELException: anno 0 java.lang.Deprecated()
--- affected javax.servlet.jsp.el.ELParseException
javax.servlet.jsp.el.Expression: anno 0 java.lang.Deprecated()
javax.servlet.jsp.el.ExpressionEvaluator: anno 0 java.lang.Deprecated()
javax.servlet.jsp.el.FunctionMapper: anno 0 java.lang.Deprecated()
javax.servlet.jsp.el.VariableResolver: anno 0 java.lang.Deprecated()
javax.faces.webapp.AttributeTag: method public final static javax.servlet.jsp.tagext.Tag javax.servlet.jsp.tagext.TagSupport.findAncestorWithClass(javax.servlet.jsp.tagext.Tag,java.lang.Class)
javax.faces.webapp.ConverterELTag: method public final static javax.servlet.jsp.tagext.Tag javax.servlet.jsp.tagext.TagSupport.findAncestorWithClass(javax.servlet.jsp.tagext.Tag,java.lang.Class)
javax.faces.webapp.ConverterTag: method public final static javax.servlet.jsp.tagext.Tag javax.servlet.jsp.tagext.TagSupport.findAncestorWithClass(javax.servlet.jsp.tagext.Tag,java.lang.Class)
javax.faces.webapp.FacetTag: method public final static javax.servlet.jsp.tagext.Tag javax.servlet.jsp.tagext.TagSupport.findAncestorWithClass(javax.servlet.jsp.tagext.Tag,java.lang.Class)
javax.faces.webapp.ValidatorELTag: method public final static javax.servlet.jsp.tagext.Tag javax.servlet.jsp.tagext.TagSupport.findAncestorWithClass(javax.servlet.jsp.tagext.Tag,java.lang.Class)
javax.faces.webapp.ValidatorTag: method public final static javax.servlet.jsp.tagext.Tag javax.servlet.jsp.tagext.TagSupport.findAncestorWithClass(javax.servlet.jsp.tagext.Tag,java.lang.Class)
javax.faces.webapp.AttributeTag: method public final static javax.servlet.jsp.tagext.Tag javax.servlet.jsp.tagext.TagSupport.findAncestorWithClass(javax.servlet.jsp.tagext.Tag,java.lang.Class)
javax.faces.webapp.ConverterELTag: method public final static javax.servlet.jsp.tagext.Tag javax.servlet.jsp.tagext.TagSupport.findAncestorWithClass(javax.servlet.jsp.tagext.Tag,java.lang.Class)
javax.faces.webapp.ConverterTag: method public final static javax.servlet.jsp.tagext.Tag javax.servlet.jsp.tagext.TagSupport.findAncestorWithClass(javax.servlet.jsp.tagext.Tag,java.lang.Class)
javax.faces.webapp.FacesServlet: method public final void javax.faces.webapp.FacesServlet.initializeAllowedKnownHttpMethods(java.util.List)
javax.faces.webapp.FacetTag: method public final static javax.servlet.jsp.tagext.Tag javax.servlet.jsp.tagext.TagSupport.findAncestorWithClass(javax.servlet.jsp.tagext.Tag,java.lang.Class)
javax.faces.webapp.ValidatorELTag: method public final static javax.servlet.jsp.tagext.Tag javax.servlet.jsp.tagext.TagSupport.findAncestorWithClass(javax.servlet.jsp.tagext.Tag,java.lang.Class)
javax.faces.webapp.ValidatorTag: method public final static javax.servlet.jsp.tagext.Tag javax.servlet.jsp.tagext.TagSupport.findAncestorWithClass(javax.servlet.jsp.tagext.Tag,java.lang.Class)
These API changes must be reverted back to make the Eclipse GlassFish 5.1.0 to pass the Java EE 8 TCK.
The generated jar doesn't seem to include the property files, which results
in runtime errors eg org/apache/japser/resources/messages.properties is missing.
Operating System: All
Platform: All
[current]
I noticed that four arguments are specified in the code for the following
message, but the 4th is not displayed:
jsp.error.beans.property.conversion=PWC6338: Cannot convert "
{0}" for the
attribute {2} of the bean {1}
The fourth argument is the IllegalArgumentException's message. This message is
the same as {0}
in case the exception was thrown by setAsText, but when the
property editor not registered with the PropertyEditorManager, it will show the
message mapped to the key "jsp.error.beans.propertyeditor.notregistered".
However, this key is not defined.
I would suggest adding the fourth argument to the message and include a message
for the message key above.
Operating System: All
Platform: All
[current]
When I deployed a jsp application to GlassFish4.1.1, an error occurred as follows.
C:\glassfish-4.1.1\glassfish4\glassfish\bin>asadmin start-domain
Waiting for domain1 to start ..............
Successfully started the domain : domain1
domain Location: C:\glassfish-4.1.1\glassfish4\glassfish\domains\domain1
Log File: C:\glassfish-4.1.1\glassfish4\glassfish\domains\domain1\logs\server.log
Admin Port: 4848
Command start-domain executed successfully.
C:\glassfish-4.1.1\glassfish4\glassfish\bin>asadmin deploy --precompilejsp --target cluster d:\tmp\jsptestear.ear
Application deployed with name jsptestear.
Command deploy executed successfully.
C:\glassfish-4.1.1\glassfish4\glassfish\bin>asadmin deploy --precompilejsp --target cluster d:\tmp\jsptestear.ear
remote failure: Error occurred during deployment: Application with name jsptestear is already registered. Either specify that redeployment m
ust be forced, or redeploy the application. Or if this is a new deployment, pick a different name. Please see server.log for more details.
Command deploy failed.
My ear application has a war file which has a tag file and a tld file in WEB-INF/lib jar.
ex)
aaa.ear
bbb.war
index.jsp
WEB-INF
lib
ccc.jar
META-INF
tags
ddd.tag
eee.tld
In my analysis, class loader for jsp compile is not released
because ClassLoaderUtil.releaseLoader is not called.
**org.apache.jasper.JspC.java execute()** } finally {
// START S1AS 5032338
if (loader != null) {
// XXX APACHE-COMMONS-LOGGING-PATCH
// LogFactory.release(loader);
// START SJSAS 6258619
// ClassLoaderUtil.releaseLoader(loader);
// END SJSAS 6258619
}
Windows
[current]
Currently the Jsr199JavaCompiler does not behave appropriately in some environments (e.g. pure OSGi framework).
The reason being that the current JavaFileManager implementations have no awareness into the runtime challenges presented by the dynamic nature of OSGi environment.
By making this class extendable, we can inject an OSGi aware JavaFileManager implementation (such as https://github.com/rotty3000/phidias) so that all assumptions are held true (and there is no need for a static pre-assemblage of the classpath).
Any
[current]
This task is for creating a basic build CI/CD pipeline for this project on Eclipse infrastructure. More information is here: https://ci.eclipse.org/.
It's not currently possible to specify an alternate Compiler implementation.
The origin/upstream sources of Tomcat Jasper allow for this.
This is an improvement request to integrate this possibility so that third party consumers of the org.glassfish.web.javax.servlet.jsp bundle can do the same.
[Ref] http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_29/java/org/apache/jasper/EmbeddedServletOptions.java (see "compilerClassName")
Any JSP compilation
[current]
Dongbin Nie:
JSP 2.3 clarifies:
"The JSP container must render a JSP page for the HTTP methods GET, POST, and HEAD, with identical responses. The behavior of the JSP container is undefined for other methods."
RFC2616 HTTP Protocols says:
"The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request."
Currently Glasshfish 4.1 and Weblogic's web container only response Http Headers without any Http body to client according to RFC2616's requirement, through the JSP engine will process "HEAD" method without difference for "GET" and "POST" method.
Is the exactly mean of JSP 2.3 clarification for "HEAD" method that it must process the JSP page as same as "GET" and "POST" method, but only Http headers can be returned to client by web container?
org.apache.jasper.compiler.Compiler#initJavaCompiler detects if javax.tool.Tool exists or if the jdk is >= 1.6.
In that case it uses the Jsr199JavaCompiler.
http://java.net/projects/jsp/sources/svn/content/trunk/impl/src/main/java/org/apache/jasper/compiler/Compiler.java?rev=1383 around line 754
It is currently not possible to setup jasper to use a different implementation of the JavaCompiler
Here is the reason why in jetty running in OSGi we need to use the JDTJavaCompiler.
The difficulty with the Jsr199JavCompiler is that it requires the classpath for compilation to be passed as a list of files.
When we use Jasper in an OSGi runtime for a web-bundle it is not possible to compute such a classpath. For example a web-bundle can dynamically import classes or it can depend on a bundle that is a jar that contains some inner jars. This type of dependency cannot be expressed in a classpath made of a list of java.io.File.
With the previous version of glassfish's jasper we were using the eclipse JDTCompiler. It uses a classloader to compiler the jsp classes. This works very well for an OSGi runtime.
At the moment, I have setup a small system property and changed 3 lines in the Compiler class:
private void initJavaCompiler() throws JasperException {
boolean disablejsr199 = Boolean.TRUE.toString().equals(
System.getProperty("org.apache.jasper.compiler.disablejsr199"));
Double version =
Double.valueOf(System.getProperty("java.specification.version"));
if (!disablejsr199 && (version >= 1.6 || getClassFor("javax.tools.Tool") != null)) {
It would help us at jetty@eclipse if this was supported in the jasper project here.
OSGi
[current]
#72 must be finished before starting working on this task.
javax.servlet.jsp is something that is expected.
javax.servlet.jsp-api is not. It suggests that there is a bundle javax.servlet.jsp-impl and that are classes inside the api bundles are in javax.servlet.jsp-api package which is not exactly true. Bundle name should match the packages, too.
NetBeans uses the JSP engine as an embedded piece of software and it configures
the parser using:
ParserUtils.setSchemaResourcePrefix("/resources/schemas/");
ParserUtils.setDtdResourcePrefix("/resources/dtds/");
However, this does not work, schemas are not found correctly. Attaching a patch.
Operating System: All
Platform: Macintosh
[current]
hi everyone,
i'am using a tag file library that works properly in tomcat 6.0.29 but doesn't
work in jetty jetty-distribution-7.1.6.v20100715.zip
the files are below to recreate the problem!!
body.tag
[code]
<%@ attribute name="jsCode" %>
<jsp:doBody var="html"/>
{jsCode}
</script> ${html}
[/code]setParentProperty.tag
[code]
<%@ attribute name="tag" required="true"
type="javax.servlet.jsp.tagext.SimpleTagSupport" %>
<%@ attribute name="property" required="true" type="java.lang.String" %>
<%@ attribute name="value" required="true" type="java.lang.String" %>
<%@ tag
import="
org.apache.commons.beanutils.BeanUtils,
javax.servlet.jsp.tagext.SimpleTagSupport,
javax.servlet.jsp.tagext.SimpleTag" %>
<%
SimpleTagSupport targetTag =
(SimpleTagSupport)findAncestorWithClass(tag,SimpleTag.class);
String parentPropertyValue = (String)BeanUtils.getProperty(targetTag,property);
if (parentPropertyValue!=null)
{ value = parentPropertyValue + value; }
BeanUtils.setProperty(targetTag,property,value);
//Both servers prints write this out
out.println("
property => "property" =
"+(String)BeanUtils.getProperty(targetTag,property));
%>
[/code]
jsCode.tag
[code]
<jsp:doBody var="code"></jsp:doBody>
<util:setParentProperty tag="<%=this%>" property="jsCode"
value="$
"></util:setParentProperty>
[/code]
index.jsp
[code]
html:body
html:jsCode
alert('hi');
</html:jsCode>
</html:body>
[/code]
Is it a bug ? or in jetty way there are more things to do??
Sorry about my poor english!!
Operating System: All
Platform: All
[current]
When I send the request to jsp several times, NullPointerException is thrown if deployed application includes glassfish-web.xml and doesn't include precompiled classes.
**glassfish-web.xml**<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE glassfish-web-app PUBLIC
"-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN"
"http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd"> <glassfish-web-app>
<jsp-config>
<property name="usePrecompiled" value="true" />
</jsp-config>
</glassfish-web-app>
This is the patch for the problem.
**org.apache.jasper.JspCompilationContext.java** public void incrementRemoved() {
if (removed > 1) {
+ if(jspCompiler != null) {
jspCompiler.removeGeneratedFiles();
+ }
if( rctxt != null )
rctxt.removeWrapper(jspUri);
}
[current]
Update the scope statement for the project: https://projects.eclipse.org/projects/ee4j.jakartaee-platform/governance
See https://docs.google.com/spreadsheets/d/1FPLjo_DJDOQngVtdrYgaDk98d9NBG-0ODgdmOG3LOsI/edit?usp=sharing for examples.
The following JSP 2.2 spec bug is reported by Mark Thomas:
I noticed that the new omit attribute defined in table JSP.5-7 is not
included in the EBNF in JSP.1.3.10.1
I assume that the correction would be changing:
AttributeBody ::= ATTR[ !name, trim ] S? ...
to
AttributeBody ::= ATTR[ !name, trim, omit ] S? ...
I would be grateful if you could confirm that this is the case and
included in the fix in the errata / next maintenance release etc.
Cheers,
Mark
Operating System: All
Platform: Sun
[current]
dependency eclipse-jdtcore-2.1.0 needs to be updated to 3.1.0 (or higher) to
compile successfully if JDTJavaCompiler needs is included in the compilation.
Operating System: All
Platform: All
[current]
There are some grey areas in the JSP specification regarding when and how scripting variables associated with actions are declared that need to be clarified.
Consider the following from JSP.9.4.4
<x:tag>
foo
</x:tag>
Equivalent Text:
declare AT_BEGIN variables
{
declare NESTED variables
transformation of foo
}
declare AT_END variables
If <x:tag> declares an AT_BEGIN scripting variable myVar of type String then the equivalent text becomes (ignoring the required variable synchronization to make the example clearer)
String myVar = null;
{
transformation of foo
}
If our original code is extended to:
<x:tag>
foo
</x:tag>
<x:tag>
foo
</x:tag>
then the equivalent text becomes
String myVar = null;
{
transformation of foo
}
String myVar = null;
{
transformation of foo
}
Clearly this is problematic since it is illegal to declare the same variable multiple times in the same scope.
There are a couple of ways to handle this. The first is to insert an outer code block around the code for each tag. However, that makes little sense since it makes the declaration of AT_END variables pointless as the following example shows. There is no point declaring the AT_END variables in this case since they instantly go out of scope.
{
declare AT_BEGIN variables
{
declare NESTED variables
transformation of foo
}
declare AT_END variables
}
{
declare AT_BEGIN variables
{
declare NESTED variables
transformation of foo
}
declare AT_END variables
}
Another alternative is to pre-process the tags and to ensure that duplicate scripting variables are not defined. The equivalent text for multiple tag instances then becomes:
String myVar = null;
{
transformation of foo
}
{
transformation of foo
}
The pre-processing approach works in most cases but it can break if scriptlets are present. Consider the following original text:
<% try { %>
<x:tag>
foo
</x:tag>
<% } catch (IllegalArgumentException iae) { %>
<x:tag>
foo
</x:tag>
<% } %>
With pre-processing this becomes:
try {
String myVar = null;
{
transformation of foo
}
} catch (IllegalArgumentException iae) {
{
transformation of foo
}
}
which will break if the transformation of foo refers to myVar (which it almost certainly will) because myVar is now out of scope for the second instance of the tag.
I do not believe it is reasonable or practical for JSP containers to parse scriplets surrounding actions to determine the scope of any declared scripting variables and then adjust the declaration of those scripting variables accordingly.
One potential solution is to move the declaration of all scripting variables for actions (AT_BEGIN, NESTED and AT_END) to immediately after the declaration of the implicit scripting variables so the scripting variables for actions are always declared once only and are always in scope during the execution of the page.
It is necessary for the JSP specification to clarify how scripting variables declared by actions should be handled. It should be noted that there are variations on this problem such as when tags are nested.
For background on the Tomcat bug report that prompted this issue see:
https://issues.apache.org/bugzilla/show_bug.cgi?id=56516
Also see:
https://issues.apache.org/bugzilla/show_bug.cgi?id=42390
https://issues.apache.org/bugzilla/show_bug.cgi?id=48616
NullPointerException is thrown if tld file doesn't include tag.
[2016-10-31T13:36:13.698+0900] [glassfish 4.1] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=34 _ThreadName=http-listener-1(2)] [timeMillis: 1477888573698] [levelValue: 900] [[
StandardWrapperValve[jsp]: Servlet.service() for servlet jsp threw exception
java.lang.NullPointerException
at org.apache.jasper.compiler.TagLibraryInfoImpl.toString(TagLibraryInfoImpl.java:129)
at java.lang.String.valueOf(String.java:2994)
at java.lang.StringBuilder.append(StringBuilder.java:131)
at java.util.concurrent.ConcurrentHashMap.toString(ConcurrentHashMap.java:1321)
at test.filter.ServletContextDumpFilter.doFilter(ServletContextDumpFilter.java:31)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:316)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:416)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:283)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
at java.lang.Thread.run(Thread.java:745)
]]
This is the patch for this problem. The same problem was modified by the following commit for Tomcat.
https://svn.apache.org/viewvc?view=revision&revision=306188
**org.apache.jasper.compiler.TagLibraryInfoImpl toString** public String toString() {
StringWriter sw = new StringWriter();
PrintWriter out = new PrintWriter(sw);
print("tlibversion", tlibversion, out);
print("jspversion", jspversion, out);
print("shortname", shortname, out);
print("urn", urn, out);
print("info", info, out);
print("uri", uri, out);
- print("tagLibraryValidator", tagLibraryValidator.toString(), out);
+ print("tagLibraryValidator", "" + tagLibraryValidator, out);
for(int i = 0; i < tags.length; i++)
out.println(tags[i].toString());
for(int i = 0; i < tagFiles.length; i++)
out.println(tagFiles[i].toString());
for(int i = 0; i < functions.length; i++)
out.println(functions[i].toString());
return sw.toString();
}
[current]
Hi everyone,
There is an old post from Matt Raible regarding an XSS vulnerability present in
all tomcat installations by default:
http://raibledesigns.com/rd/entry/java_web_frameworks_and_xss
The JSP I have attached shows a quick-and-dirty test to inject arbitrary HTML
into your page using EL expressions like $
{foobar}
. I know that "<c:out>" can
be used as a workaround, but it is quite verbose and easy to miss.
As part of my job as a developer of Loom
(http://www.loom.extrema-sistemas.com/) I have prepared a patch so XML content
obtained from EL expressions can be configured to
be escaped defaulting to true but can also be deactivated in order to keep
current behavior.
Regards
Rafa
Operating System: All
Platform: All
[current]
The jsp-api-2.1 jar dependency in the pom does not incorporate the changes
to javax.el.ExpressionFactory that is present in the glassfish sources,
resulting in a compilation error on javax.el.ExpressionFactory.newInstance().
Operating System: All
Platform: All
[current]
We need to create a release CI/CD pipeline for this project.
Use these documents as a reference:
The following question was raised in https://issues.apache.org/bugzilla/show_bug.cgi?id=57142
Should an import declared via the import page directive be visible to EL as if it had beed added via ImportHandler or should an explicit call to the ImportHandler be required?
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.