[SERVLET_SPEC-29] Support @RolesAllowed on a Servlet Created: 03/Dec/11  Updated: 15/Dec/11  Resolved: 15/Dec/11

Status: Closed
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Shing Wai Chan
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Servlets currently support the @RunAS and @DeclareRoles from the common security annotations defined in JSR 250. Missing is the @RolesAllowed annotation.

I would like to propose supporting the @RolesAllowed annotation on Servlets for the following reasons:

  • Harmonize the way security is configured throughout the Java EE platform.
  • Continue the theme of not making deployment descriptors (web.xml here) required for anything.


 Comments   
Comment by Shing Wai Chan [ 15/Dec/11 ]

In Servlet 3.0, we have added an annotation @ServletSecurity.
See http://docs.oracle.com/javaee/6/api/javax/servlet/annotation/ServletSecurity.html

This allows us to put the security constraints without web.xml.
Note that @RolesAllowed can only associated to Java methods, not HTTP methods. And security-constraints are associated to HTTP methods.





[SERVLET_SPEC-23] Help prevent infinite loops Created: 07/Oct/11  Updated: 04/Jan/12  Resolved: 04/Jan/12

Status: Closed
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: markt_asf Assignee: Shing Wai Chan
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

It is possible to create an infinite loop within an application if a wrapper is passed to its own ServletRequestWrapper.setRequest() method. The same problem can occur with ServletResponseWrapper and the HTTP variants.

It would be helpful if the spec required that this was not permitted. The check should probably go further and check for loops (A wraps B wraps C wraps A).



 Comments   
Comment by Shing Wai Chan [ 04/Jan/12 ]

The issue has been discussed in Servlet 3.1 expert group.
Adding the check for infinite loop will help in debugging.
The check should not be complicated or too costly as each corresponding vertex has only one outgoing edge and also in general there is not too many vertex in the corresponding graph.
However, there is a concern that this will introduce an overhead in checking.
So, the spec will not include this check in the spec.





[SERVLET_SPEC-19] Add forward and include events to RequestListener Created: 07/Oct/11  Updated: 06/Mar/13  Resolved: 06/Mar/13

Status: Closed
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: markt_asf Assignee: Rajiv Mordani
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Rajiv Mordani [ 08/Feb/13 ]

Are you looking for requestForwarded(ServletRequestEvent sre) and requestIncluded(ServletRequestEvent sre)? Sounds reasonable. Are there any other such events needed?

Comment by markt_asf [ 08/Feb/13 ]

Yes, that is what I was looking for.

This is the Tomcat bug report that triggered this request:
https://issues.apache.org/bugzilla/show_bug.cgi?id=50789
also
https://issues.apache.org/bugzilla/show_bug.cgi?id=49991

It might be worth checking with the CDI folks if this is sufficient or if there is anything else they'd like.

Comment by Rajiv Mordani [ 05/Mar/13 ]

As discussed in the EG, this would break compatibility with existing listeners. Also it isn't clear to me why CDI needs these events. For now I am not going to add these events to a new listener either.

Comment by markt_asf [ 05/Mar/13 ]

I'm fine with that.

If the CDI folks need this then they need to speak up and make their case.





[SERVLET_SPEC-5] Need to update dispatch forward behavior in 9.4 of the spec. Created: 08/Aug/11  Updated: 22/Dec/11  Resolved: 22/Dec/11

Status: Closed
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In section of 9.4 of Servlet 3.0 spec, it has the following:
"Before the forward method of the RequestDispatcher interface returns without
exception, the response content must be sent and committed, and closed by the
servlet container."

In javadoc of AsyncContext#dispatch, it has the following:
"Control over the request and response is delegated to the dispatch target, and the response will be closed when the dispatch target has completed execution, unless ServletRequest#startAsync() or ServletRequest#startAsync(ServletRequest, ServletResponse) are called."

According to examples illustrated in javadoc of AsyncContext#dispatch, one need to update the information in section 9.4 so that it is consistent with those in AsyncContext#dispatch.



 Comments   
Comment by Shing Wai Chan [ 10/Aug/11 ]

In javadoc of ServletRequest#startAsync(), it would be a good idea to add a link to AsyncContext#dispatch as it indicates one difference between startAsync with and without argument.

Comment by Shing Wai Chan [ 15/Dec/11 ]

The javadoc is updated:
Sending javax.servlet/src/main/java/javax/servlet/AsyncContext.java
Sending javax.servlet/src/main/java/javax/servlet/ServletRequest.java
Transmitting file data ..
Committed revision 51595.

Comment by Shing Wai Chan [ 22/Dec/11 ]

update in spec

Sending dispatchingrequests.fm
Transmitting file data .
Committed revision 2.





[SERVLET_SPEC-71] Unnecessary new special role name of ** for auth-constraints Created: 12/Apr/13  Updated: 12/Apr/13  Resolved: 12/Apr/13

Status: Closed
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: janbartel Assignee: Shing Wai Chan
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Ideally I would re-open issue #34 but I don't have permission to do that.

Please clarify the purpose of adding the special role name "*". A role name of "" already indicates that a user with any role can access the protected resource. If a url is protected by a security constraint, a user must be authenticated before their access to it can be determined. Thus, the role name of "" in a security constraint already means "any authenticated user" may access the user protected by it: the new special role name of "*" is unnecessary.



 Comments   
Comment by janbartel [ 12/Apr/13 ]

Sorry - the wiki markup appears to have messed up the number of stars, making the bug hard to understand.

In the previous comment, what I am trying to say is that the new role name of "star star" is unnecessary because the existing special role name of "star" means the same thing.

Comment by Shing Wai Chan [ 12/Apr/13 ]

According to JSR 115, "*" means any role defined in the application.
Now, "**" means any authenticated users.
The above two concepts are different.





[SERVLET_SPEC-47] Should keep session content rather than session object after programmatic login Created: 05/Oct/12  Updated: 10/Oct/12  Resolved: 10/Oct/12

Status: Closed
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The following issue is raised by Jan Bartel <janb@intalio.com>.
See email discussion in users@servlet-spec.java.net .

In p.141 of 13.10 "Login and Logout" of Servlet 3.0 spec, it has:
"If a developer creates a session while a user is not authenticated, and the container then authenticates the user, the session visible to developer code after login must be the same session object that was created prior to login occurring so that there is no loss of session information."

The session content rather than the session object must be kept.
So, it is a bug in the spec.



 Comments   
Comment by Shing Wai Chan [ 10/Oct/12 ]

I have a second thought on the issue.
Consider the following:
session.setAttribute("a", A);
where A is an object that has a reference to session.
In this case, it would be better to keep the same object instance.





[SERVLET_SPEC-3] Use Generic for Class in javax.servlet.* Created: 27/Jul/11  Updated: 15/Dec/11  Resolved: 15/Dec/11

Status: Closed
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

One has the following:
javax.servlet.ServletRequestWrapper.java:
public boolean isWrapperFor(Class wrappedType) {

javax.servlet.ServletResponseWrapper.java:
public boolean isWrapperFor(Class wrappedType) {

javax.servlet.annotation.HandlesTypes.java:
Class[] value();

One should use Class<?> in above.



 Comments   
Comment by Shing Wai Chan [ 15/Dec/11 ]

Sending src/main/java/javax/servlet/ServletRequestWrapper.java
Sending src/main/java/javax/servlet/ServletResponseWrapper.java
Sending src/main/java/javax/servlet/annotation/HandlesTypes.java
Transmitting file data ...
Committed revision 51594.





[SERVLET_SPEC-4] Clarification on javadoc and spec examples on AsyncContext#dispatch() Created: 27/Jul/11  Updated: 22/Dec/11  Resolved: 22/Dec/11

Status: Closed
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In javadoc of javax.servlet.AsyncContext#dispatch(), we have
...
getRequestDispatcher("/url/B").forward(request,response);
...
getRequestDispatcher("/url/B").forward(request,response);

It should be
request.getRequestDispatcher("/url/B").forward(request,response);
or
servletContext.getRequestDispatcher("/url/B").forward(request,response);

In p.15 of spec pdf file, there is a similar issue.
Also, one may like to add "//" for comment and additional information from javadoc.



 Comments   
Comment by Shing Wai Chan [ 29/Jul/11 ]

In p14 of Servlet 3.0 spec, we have
"public void addListener(asyncListener, req, res) - Registers the
listener for notifications of time out, error and complete with the most ..."

"public void addListener(asyncListener) - Registers the given listener
for notifications of time out, error and complete with the most recent ..."

It should also the onStartAsync here.

Also, in p14, we have "buy may be used in order to release any resources".
The "buy" should be "but" here.

Comment by Shing Wai Chan [ 15/Dec/11 ]

The javadoc is fixed:
Sending javax.servlet/src/main/java/javax/servlet/AsyncContext.java
Sending javax.servlet/src/main/java/javax/servlet/ServletRequest.java
Transmitting file data ..
Committed revision 51595.

Comment by Shing Wai Chan [ 22/Dec/11 ]

Sending servletobjects.fm
Transmitting file data .
Committed revision 3.





[SERVLET_SPEC-151] CLONE - Expose tls_unique as request attribute Created: 16/Dec/15  Updated: 12/Oct/16  Resolved: 12/Oct/16

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: MyHat95111 Assignee: Ed Burns
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
clones SERVLET_SPEC-107 Expose tls_unique as request attribute Open
Duplicate
is duplicated by SERVLET_SPEC-107 Expose tls_unique as request attribute Open

 Description   

>>>>> On Thu, 25 Sep 2014 11:32:41 -0400, Ron Monzillo said:

RM> In addition to the attributes currently required to be supported
RM> when a request has been received over a secure protocol, consider
RM> adding a requirement that that container make the value of
RM> tls_unique availbale via the required to be supported (SSL)
RM> attributes.

RM> tls_unique is defined in http://tools.ietf.org/html/rfc5929

RM> Access to this value will facilitate the practice of creating
RM> cookies and other session identifying tokens that are bound to a
RM> specific TLS connection (iow, that cannot be stolen and reused
RM> outside of the TLS connection under which they were established and
RM> returned).

RM> The attribute could be called: javax.servlet.request.tls_unique

RM> Note that support for this attribute above JSSE will require that
RM> the value of verifyData as conveyed in the TLS finished handshake
RM> message be available from the SSLSession object.






[SERVLET_SPEC-116] Take ownership of CDI-related beans from CDI spec Created: 19/Nov/14  Updated: 21/Nov/14  Resolved: 21/Nov/14

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

CDI Spec section 3.8 [1] places some requirements on CDI implementations when running with Servlet. To better suit user desires for modularity these requirements are better met by moving them to the Servlet spec. Specifically,

A servlet container must provide the following built-in beans, all of which have qualifier @Default:

a bean with bean type javax.servlet.http.HttpServletRequest, allowing injection of a reference to the HttpServletRequest

a bean with bean type javax.servlet.http.HttpSession, allowing injection of a reference to the HttpSession,

a bean with bean type javax.servlet.ServletContext, allowing injection of a reference to the ServletContext,

These beans are passivation capable dependencies, as defined in Passivation capable dependencies.

To put these items in the Servlet spec, we may have to couch them in terms similar to, "when running in an environment that also supports CDI..."

[1] http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#additional_builtin_beans



 Comments   
Comment by Ed Burns [ 19/Nov/14 ]

See <https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bean/builtin/ee/HttpServletRequestBean.java> for some implementation details from Weld.

Some notes from IRC

<edburns> antoine_sd: And the "bean with bean type javax.faces.servlet.http.HttpServletRequest" portion of the requirement is satisfied precisely by this declaration: "CreationalContext<HttpServletRequest>"? Is that correct?
<jharting> edburns: no, the requirement you quoted is met by HttpServletRequestBean.getTypes() returning a set containing HttpServletRequest.class
<edburns> jharting: Thanks, that exactly what I was looking for.
<jharting> edburns: it's not obvious as it is a bit hidden deeper in the class hierarchy
<edburns> jharting: I suppose getTypes() is inherited from AbstractStaticallyDecorableBuiltInBean<HttpServletRequest>?

Comment by Ed Burns [ 19/Nov/14 ]

Corresponding issue in CDI tracker: https://issues.jboss.org/browse/CDI-492.

Comment by Ed Burns [ 21/Nov/14 ]

>>>>> On Wed, 19 Nov 2014 15:55:43 -0500 (EST), Stuart Douglas said:

[...]

SD> I think however there may be some backwards compatibility issues for
SD> the standalone servlet container case.

SD> Say I have an application that packages Weld (or OWB) that I have
SD> deployed on a Servlet 3.1 container, and I now want to move it to a
SD> Servlet 4.0 container. The older version of Weld will still provide
SD> the HttpServletRequest beans (as it is required to do by spec) and
SD> the servlet container will also provide these beans (as we are
SD> required to do by spec) and as a result if you try and inject them
SD> you will get a bean resolution error as two beans resolve to the
SD> injection point.

SD> This also works in reverse, if you deploy a new version of CDI to an
SD> older servlet container then no beans will be registered, however I
SD> think this is less of an issue.

SD> For servers that don't actually provide CDI API jars there may also
SD> be some linking issues. The producers need to be linked against the
SD> CDI API which in this case will be provided by the deployment, so it
SD> won't really be possible to just have them as a global library.

>>>>> On Fri, 21 Nov 2014 14:06:24 +1100, Greg Wilkins said:
[...]

GW> I share Stuarts concerns about classloading confusion. More over,
GW> I'm concerned that by making CDI to servlet mapping a responsibility
GW> of the servlet container, then we are going to have to do a
GW> container to CDI adaptation for every CDI implementation out there.

GW> The servlet specification already provides servlet container initializers,
GW> which have all the power required for CDI implementations to implement
GW> these CDI v Servlet cross concerns. Thus I think these things must
GW> remain a CDI impl responsibility as they are able to write container
GW> portable code that will handle these concerns. The inverse is not true if
GW> we make them container concerns.

Excellent points. I will use these to push back on
CDI-492-FobStuffToServlet. I will provisionally close this issue for
now at least.





[SERVLET_SPEC-30] Configure default behavior of url pattern not covered by security constraint Created: 17/Jan/12  Updated: 05/Mar/13  Resolved: 05/Mar/13

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If an url pattern is not covered by security-constraint, then the default behavior is "permit all".
One would like to configure the default behavior to be "deny all".



 Comments   
Comment by gregwilkins [ 31/Jan/12 ]

Note that this used to be very difficult to do because it was impossible to add a constraint that forbid /* and then to add other constraints that relaxed the criteria on other URIs - because it was impossible to explicitly match "/".

Now with the "" pattern matching root, it is possible to use normal constraints to implement a deny by default and permit by specific pattern approach. So maybe we don't need a change in the spec for this.

Comment by Shing Wai Chan [ 05/Mar/13 ]

Add Section 13.8.4, Uncovered HTTP Protocol Methods.
Add deny-uncovered-http-methods in web.xml schema.





[SERVLET_SPEC-33] Need to clarify the behavior of HttpServletRequest.getPart/getParts Created: 08/Mar/12  Updated: 01/Aug/12  Resolved: 01/Aug/12

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In the javadoc of httpServletRequest.getPart/getParts, it does not mention the behavior of calling these API when there is no @MultipartConfig and multipart-config in deployment descriptors.

One should exception in this case. UnsupportedOperationException? IllegalStateException?



 Comments   
Comment by Christian Ludt [ 25/Mar/12 ]

Both current javadocs for getPart() and getParts() specify that a ServletException is to be thrown:

Throws:
java.io.IOException - if an I/O error occurred during the retrieval [...]
ServletException - if this request is not of type multipart/form-data
IllegalStateException - if the request body is larger than maxRequestSize, or any Part in the request is larger than maxFileSize

Comment by Shing Wai Chan [ 26/Jul/12 ]

The ServletException is thrown when the request is not of type multipart/form-data.
The scenario in the description above is when there is no multipart configuration.
So, one still need to clarify this case.

Comment by markt_asf [ 28/Jul/12 ]

Rather than an Exception, returning null / an empty collection is also an option.

I prefer IllegalStateException over UnsupportedOperationException but have no string preference between throwing an Exception and returning null / an empty collection.

Comment by Shing Wai Chan [ 01/Aug/12 ]

Sending src/main/java/javax/servlet/http/HttpServletRequest.java
Transmitting file data .
Committed revision 55270.





[SERVLET_SPEC-32] Need to clarify when the servlet container will process the file upload Created: 06/Mar/12  Updated: 08/Mar/12  Resolved: 06/Mar/12

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In section of 3.2 of Servlet 3.0 spec, servlet container process multipart/form-data for file uploaded when @MultipartConfig is annotated with the corresponding servlet.

This is not correct as one also need to consider the multipart-config element in web.xml.



 Comments   
Comment by Shing Wai Chan [ 06/Mar/12 ]

Sending requestobject.fm
Sending status.fm
Transmitting file data ..
Committed revision 22.

Comment by Shing Wai Chan [ 08/Mar/12 ]

Sending requestobject.fm
Transmitting file data .
Committed revision 24.





[SERVLET_SPEC-28] @WebServlet annotation does not support the 'enabled' attribute specified by the Servlet 3.0 specification Created: 16/Nov/11  Updated: 23/Jul/12  Resolved: 23/Jul/12

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Amy Roh Assignee: Shing Wai Chan
Resolution: Invalid Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-17721 @WebServlet annotation does not suppo... Resolved

 Description   

See http://java.net/jira/browse/GLASSFISH-17721

"The Servlet 3.0 specification in section 8.2.3 sub part 3 describes "If a servlet is disabled using the enabled element introduced in the web.xml then the servlet will not be available at the url-pattern specified for the servlet".

The WebServletHandler.java deployment annotation handler does not support then enabled element and it should since it is part of the web.xml specification for the <servlet> element."



 Comments   
Comment by rojkov [ 07/Dec/11 ]

I think since this requires recompilation, one can simply comment out the annotation to the same effect.

Comment by emailnbw [ 07/Dec/11 ]

@rojkov -

I don't understand your comment. Are you suggesting a 'work around' or a way to test proposed changes?

Comment by rojkov [ 07/Dec/11 ]

@emailnbw enable in web.xml makes sense because you might want to disable a servlet without recompiling, repackaging and redeploying. Adding it to the annotation means that recompilation, repackaging and redeployment is required for the setting to take effect. If the servlet isn't needed it should be either removed from the source or have @WebServlet commented out. The only value the change provides is consistency.

Comment by emailnbw [ 07/Dec/11 ]

@rojkov -

Thanks for the clarification, I understand what you were saying now. So the use case I had in mind which is what got me to investigate this in the first place is that our web application does not have a web.xml deployment descriptor. We would like to use the annotation to affect a disabled servlet on deployment which will then be programmatically enabled at a time subsequent to deployment.

Comment by rojkov [ 07/Dec/11 ]

I see. This seems to add another requirement for a container to monitor changing annotations. The way I interpret the spec is that examining of annotations takes place at starting of the context.

Comment by emailnbw [ 07/Dec/11 ]

The container will scan for the annotations during the deployment context, it will find the annotated web servlet, which it does in the current scheme, but it would also possibly find an 'enable' attribute on that WebServlet annotation, e.g.:

@WebServlet(asyncSupported = false, name = "HelloServlet", urlPatterns =

{"/hello"}

, enabled = false)

It would deploy the servlet in a disabled state the same way the container would have done had this been specified in the web.xml.

Then some time later external code would enable the web servlet (perhaps via a ReST endpoint the web app provides or a MXBean). The value of the enabled annotation would remain the same through out this process so there is no need to monitor for changing annotations. However, it does mean the container would need to support programmatically enabling/disabling a servlet after deployment. I haven't looked at the existing code path that takes care of enable/disable of a servlet on deployment to know what is involved there.

Comment by Shing Wai Chan [ 18/Jan/12 ]

So having the annotation attribute does not solve your issue, you need a way to enable/disable a given servlet in the runtime. In Servlet 3.0, one can only modify the servlet registration before or on context initialization.

Comment by Shing Wai Chan [ 23/Jul/12 ]

Adding an 'enabled' attribute to @WebServlet does not solve the issue described above.
According to Servlet 3.0, one cannot enable a servlet after the context initialization.





[SERVLET_SPEC-10] Character encoding setting after ServletResponse#reset Created: 20/Sep/11  Updated: 13/Jan/12  Resolved: 13/Jan/12

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

From javadoc, ServletResponse#reset will clear any data that exists in the buffer as well as the status code and headers. If the response has been committed, this method throws an IllegalStateException.

Once the headers are cleared, so is the charset in Content-Type.
If the getWriter() is already called, then according to javadoc of ServletResponse#setCharacterEncoding, one cannot set the encoding. In other words, only the default charset (in a given implementation) can used in this case.



 Comments   
Comment by markt_asf [ 21/Sep/11 ]

I assume that the proposed solution is that calling reset() also resets whatever tracking mechanism is used to determine that getWriter() or getOutputStream() has been called and thereby allowing the user to effectively start again.

Comment by Shing Wai Chan [ 21/Sep/11 ]

If we reset the state for determining whether getWriter() and getOutputStream() has been called, then we need to clarify what happens to existing Writer or OutputStream. Then we need to clarify the behaviors of the existing writer or outputstream.

Comment by markt_asf [ 22/Sep/11 ]

The spec should state that if the response is reset the Writer/OutputStream should no longer be used. Behaviour if there are used is undefined / throws ISE (I have have a slight preference for undefined since that means less work for me ).

As it happens, Tomcat will happily allow the Writer or OutputStream to be re-used although getWriter(), reset(), getOutputStream() will allow the Writer and OutputStream to be used together which might lead to some strange results.

Mark

Comment by Shing Wai Chan [ 13/Jan/12 ]

Sending javax.servlet/src/main/java/javax/servlet/ServletResponse.java
Transmitting file data .
Committed revision 52096.

Sending responseobject.fm
Sending status.fm
Transmitting file data ..
Committed revision 6.





[SERVLET_SPEC-27] sendRedirect Javadoc prevents use of protocol relative URLs Created: 07/Oct/11  Updated: 19/Jan/12  Resolved: 19/Jan/12

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: markt_asf Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The Javadoc for sendRedirect() is quite clear that a URL starting with '/' should be treated as relative to the server root. However, that precludes the use of protocol relative URLs that start with '//'. See [1] for details of why these might be useful. While there are clearly arguments for and against protocol relative URLs, I don't think we should preclude their use and therefore the Javadoc for sendRedirect should be amended to allow for them.

[1] http://blog.httpwatch.com/2010/02/10/using-protocol-relative-urls-to-switch-between-http-and-https/



 Comments   
Comment by Shing Wai Chan [ 19/Jan/12 ]

Sending src/main/java/javax/servlet/http/HttpServletResponse.java
Transmitting file data .
Committed revision 52212.





[SERVLET_SPEC-22] Allow static resources to be served from WEB-INF/classes/META-INF/resources Created: 07/Oct/11  Updated: 04/Feb/15  Resolved: 04/Feb/15

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: markt_asf Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVLET_SPEC-123 Clarify META-INF/resources in a jar i... Resolved

 Description   

IDEs often unpack JAR files into the classes directory. This breaks the static resources from JAR files feature of Servlet 3.0. Allowing static resources to be read from the classes dir would address this.



 Comments   
Comment by Rajiv Mordani [ 07/Feb/13 ]

Would the order then be to first look for resources in WEB-INF/classes/META-INF/resources and then in the jar files?

Comment by markt_asf [ 07/Feb/13 ]

I think that makes sense as it would be consistent with the ordering for class-loading.

I don't have particularly strong feelings about what the order is but I do think that it is important that - if this feature is added - the specification clearly defines what the order is.





[SERVLET_SPEC-17] Clarify required behaviour when an Async listener throws an exception Created: 04/Oct/11  Updated: 15/Dec/12  Resolved: 15/Dec/12

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: markt_asf Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The behaviour on an exception is currently undefined. It would be helpful if the spec defined the expected behaviour in this case. I guess the options are:

  • any recoverable exception to be swallowed/logged and the subsequent listeners fired
  • the request is placed in to the error state


 Comments   
Comment by Shing Wai Chan [ 15/Dec/12 ]

Sending servletobjects.fm
Sending status.fm
Transmitting file data ..
Committed revision 49.





[SERVLET_SPEC-15] Provide the ability for sendRedirect() to control the status code used Created: 04/Oct/11  Updated: 29/Dec/13  Resolved: 29/Dec/13

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: markt_asf Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

There are a range of status codes that a developer might want to use with sendRedirect (302,303,307). Currently, sendRedirect() always issues 302s. It would be helpful to extend the API to allow the developer to control which status code is used.



 Comments   
Comment by markt_asf [ 29/Dec/13 ]

This is duplicated (in much more detail) by SERVLET_SPEC-74





[SERVLET_SPEC-14] Require FORM auth to issue 303 redirects Created: 04/Oct/11  Updated: 01/Mar/13  Resolved: 01/Mar/13

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: markt_asf Assignee: Shing Wai Chan
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

See https://issues.apache.org/bugzilla/show_bug.cgi?id=49779 for an example of why this would be useful.



 Comments   
Comment by monzillo [ 10/Jan/13 ]

I downloaded the app, ported it, and ran it on Glassfish, and did not see the reported problem.
That said, constraint processing and FBL are areas where glassfish and tomcat differ in their implementations.

In any event, I took a closer look at FBL, and I can see how there is a problem (with FBL) which likely is independent of implementation.

As I understand FBL it works generally as follows (leaving out some failure cases like failure of password validation).

1. a request is made to a resource requiring authentication.

2. the container calls the authentication system which saves the request, and the login page is returned to the user.

3. the user fills in the login page and submits its contents in a POST request to j_security_check.

4. the container routes j_security_check to the authentication system which validates the username and password obtained from the post request, and then restores the uri of the saved request and then redirects the post request to the restored uri.

5. the browser repeats the restored request to the restored resource url (the http verb used by the browser depends on the verb used in step 4)

6. if the container determines that the repeated request requires authetication, it calls the authentication system; in which case, the authentication system notices that it has already authenticated this request, so it binds the principal to the request, and restores the details from the original saved request (including the http verb)

7. In either case, the container determines if the called principal (which may be null if the authentication system was skipped in step 6) is authorized to access the resource using verb of the request (which depends on both the way the redirect was done in step and whether the verb used by the browser in step 6, required authentication).

if the redirect of step 4 is done with a 302, then the restored request should be repeated (by the browser with POST, since it is a redirect in response to the POST of the login form. If the original request was done with a verb other than POST, then there is always the possibility that that verb required authentication, and POST does not; in which case the authenticator would not be called in step 6, the verb would not be restored, the caller principal would not be set, and the access check would presumably pass, although the wrong method of the resource would likely be called.

Conversely if the redirect of step 4 is done with a 303, then the restored request should be repeated with a GET; which can result in similar problems if the original request was done with a verb other than GET, and that verb requires authentication while GET does not.

I am not sure how to completely resolve this, but I think the following are true. a 303 redirect should be used when the original request came in with GET. This will ensure that the original request and the repeat following redirect are identical in terms or checked url and http verb.
a 302 redirect should be used when the original request cam in with post. If the request came in on any verb other than GET or POST, then the authenticator should fail if neither GET or POST have been configured to require authentication (at the request pattern). Otherwise 302 or 330 should be used depending on whether POST or GET require authentication.

If the dialog is short-circuited, for example by starting with a GET of the login page, or of a GET or POST to j_security_check, then I believe the convention is to redirect the request to the context root of the app, in which case, either redirection code can likely be accomodated.

Comment by markt_asf [ 12/Jan/13 ]

I agree with all of the analysis above with a few minor tweaks:

I'd used 307 rather than 302 for HTTP/1.1 clients to be unambiguous.

I wonder if the following option is viable:

  • Always use 303 redirects
  • Always pass GET requests through the FORM authenticator
  • If the resource is protected for GET - proceed as currently
  • If the resource is not protected for GET, check if there is a saved request to be restored
  • If there is, restore it along with the original verb
  • If not, carry on
Comment by monzillo [ 14/Jan/13 ]

Yes, I think so...but as i'm sure you know, the container runtime, which in our cases likely includes some variant of AuthenticatorBase, mostly just decides when to call the configured authenticator (based on evaluating constraints), while leaving it up to the authenticator to know how to deal with details/problems like the one we are discussing.

In this case, we are basically saying that (at least) one specific authenticator can't function properly unless it is called on every request (for which an caller identity has not yet been established), and that (when the runtime calls the authenticator on each request) the runtime will either need to pass the authenticator more info (describing the nature of constraints that apply to the call), or the authenticator will need to perform the constraint determination that would otherwise have been done by the runtime.

Since the runtime currently handles all authenticators in (basically) the same way, such a change might need to effect the implementation of all the existing authenticators, or at least we would need to establish a way for the runtime to be able to ask the authenticator if it must be called on every request. Since all the authenticators extend BasicAuthenticator, we could probably do this by adding a method to BasicAuthenticator, that could be overriden by only those authenticators that need to be called independent of constraint.

Aslo, and fwiw, the Servlet Profile of jsr 196 requires; that the configured auth context be called on every request, and the context of the request informs the auth module, as to whether or not the current request is subject to an auth contraint.

Comment by Shing Wai Chan [ 01/Mar/13 ]

The spec has been updated to use 303 appropriately for HTTP/1.1.
See section 13.6.3 for Servlet 3.1 PFD.





[SERVLET_SPEC-13] Make session fixation protection part of the spec Created: 04/Oct/11  Updated: 19/Sep/12  Resolved: 19/Sep/12

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: markt_asf Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

One of the options for providing protection against session fixation is to change the ID of a session on authentication. It would be good if something along the lines of a changeId() method could be added to the session interface to enable custom security solutions to do this easily. An associated event for sessions listeners would also be required.



 Comments   
Comment by markt_asf [ 04/Oct/11 ]

On a related note we may want to consider an option to control if this happens when using container provided authentication.

Comment by janbartel [ 06/Feb/12 ]

Access will be needed to the current request, and also the current response in order to effectively change the session id.

So I propose we add the following to the HttpSession object:

public String changeId (HttpServletRequest request, HttpServletResponse response);

where the return value is the new sessionId.

Comment by gregwilkins [ 06/Feb/12 ]

Note also that we have to consider shared session IDs with cross context dispatch.

If a server is working with cross context dispatch, then many contexts can have the same session ID pointing to different sessions. Changing the session ID on one context will have to change the session ID for all contexts (just as invalidating on one will invalidate on all).

cheers

Comment by Shing Wai Chan [ 14/Sep/12 ]

Incremental fixes:
Committed revision 42.

Modified Paths:
---------------
trunk/servletcontext.fm
trunk/javaEE.fm
trunk/eod-pluggability.fm
trunk/status.fm
trunk/events.fm
trunk/requestobject.fm

Comment by Shing Wai Chan [ 19/Sep/12 ]

Sending sessions.fm
Sending status.fm
Transmitting file data ..
Committed revision 44.





[SERVLET_SPEC-136] Deprecated HttpServletRequestWrapper#isRequestedSessionIdFromUrl() Created: 17/Aug/15  Updated: 18/Aug/15  Resolved: 18/Aug/15

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 4.0-m01

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

HttpServletRequest#isRequestedSessionIdFromUrl() is deprecated in Servlet 2.1. But the corresponding method in HttpServletRequestWrapper is not deprecated. The HttpServletRequestWrapper#isRequestedSessionIdFromUrl() method should be deprecated.



 Comments   
Comment by Shing Wai Chan [ 18/Aug/15 ]

Sending src/main/java/javax/servlet/ServletContext.java
Sending src/main/java/javax/servlet/ServletRequestWrapper.java
Sending src/main/java/javax/servlet/SingleThreadModel.java
Sending src/main/java/javax/servlet/UnavailableException.java
Sending src/main/java/javax/servlet/http/HttpServletRequest.java
Sending src/main/java/javax/servlet/http/HttpServletRequestWrapper.java
Sending src/main/java/javax/servlet/http/HttpServletResponse.java
Sending src/main/java/javax/servlet/http/HttpServletResponseWrapper.java
Sending src/main/java/javax/servlet/http/HttpSession.java
Sending src/main/java/javax/servlet/http/HttpSessionContext.java
Sending src/main/java/javax/servlet/http/HttpUtils.java
Transmitting file data ...........
Committed revision 64060.





[SERVLET_SPEC-142] Use Java SE 8 default methods for listeners Created: 23/Sep/15  Updated: 06/Oct/15  Resolved: 06/Oct/15

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 39 minutes
Original Estimate: Not Specified

Attachments: Zip Archive SERVLET_SPEC-142.zip    

 Description   

Consider these listener APIs in Servlet:

./javax/servlet/AsyncListener.java
./javax/servlet/ReadListener.java
./javax/servlet/ServletContextAttributeListener.java
./javax/servlet/ServletContextListener.java
./javax/servlet/ServletRequestAttributeListener.java
./javax/servlet/ServletRequestListener.java
./javax/servlet/WriteListener.java
./javax/servlet/http/HttpSessionActivationListener.java
./javax/servlet/http/HttpSessionAttributeListener.java
./javax/servlet/http/HttpSessionBindingListener.java
./javax/servlet/http/HttpSessionIdListener.java
./javax/servlet/http/HttpSessionListener.java

Most of the methods in most of those classes can have sensible no-op implementations using the Java SE 8 default methods.



 Comments   
Comment by Shing Wai Chan [ 24/Sep/15 ]

The attachment above basically adding no-ops default to all methods in listeners interfaces.
I think we should look at them one by one.

For instance, HttpSessionIdListener has only one method. Do we really need a default there?

For WriteListener, both #onWritePossible and #onError are essential. Should we have empty method body there? Do we want to ignore all errors by default? Is it a good default?
Similarly for ReadListener.
Note that AsyncListener has a #onError method there, too.

Comment by Ed Burns [ 24/Sep/15 ]

Shing-wai, absolutely we need to look at each one individually.

Let's partition the work of doing that in two, 6 each. Please check out the topic branch and make the changes you feel necessary. Thanks!

Shing-wai

./javax/servlet/http/HttpSessionIdListener.java
./javax/servlet/WriteListener.java
./javax/servlet/ReadListener.java
./javax/servlet/AsyncListener.java
./javax/servlet/http/HttpSessionBindingListener.java
./javax/servlet/http/HttpSessionListener.java

Ed

./javax/servlet/ServletContextAttributeListener.java
./javax/servlet/ServletContextListener.java
./javax/servlet/ServletRequestAttributeListener.java
./javax/servlet/ServletRequestListener.java
./javax/servlet/http/HttpSessionActivationListener.java
./javax/servlet/http/HttpSessionAttributeListener.java

Comment by Ed Burns [ 24/Sep/15 ]

Ok, I reviewed all six in my list

./javax/servlet/ServletContextAttributeListener.java
./javax/servlet/ServletContextListener.java
./javax/servlet/ServletRequestAttributeListener.java
./javax/servlet/ServletRequestListener.java
./javax/servlet/http/HttpSessionActivationListener.java
./javax/servlet/http/HttpSessionAttributeListener.java

and I conclude they are ok as is. I'll assign the issue to you to review the remainder.

Comment by Shing Wai Chan [ 06/Oct/15 ]

Per discussion with EG, we will do the following:
. We can add no-op default methods to all of the methods in
javax.servlet:
ServletContextAttributeListener, ServletContextListener,
ServletRequestAttributeListener, ServletRequestListener
javax.servlet.http:
HttpSessionActivationListener, HttpSessionAttributeListener,
HttpSessionBindingListener, HttpSessionListener

2. We will "not" add no-op default method to javax.servlet.http.HttpSessionIdListener
as there is only "one" method there.

3. We do not add no-op default methods to javax.servlet.WriteListener, ReadListener
as all those methods are important.
Developers need to take a look whether they need to override them.
In fact, similar interface in JDK 8, java.nio.channels.CompletionHandler, does not have default methods.

4. For javax.servlet.AsyncListener, we don't want default #onComplete as we may need to clean up resources there.
Similarly, in #onError and #onTimeout. And we leave AsyncListener without default methods for now.

Sending src/main/java/javax/servlet/ServletContextAttributeListener.java
Sending src/main/java/javax/servlet/ServletContextListener.java
Sending src/main/java/javax/servlet/ServletRequestAttributeListener.java
Sending src/main/java/javax/servlet/ServletRequestListener.java
Sending src/main/java/javax/servlet/http/HttpSessionActivationListener.java
Sending src/main/java/javax/servlet/http/HttpSessionAttributeListener.java
Sending src/main/java/javax/servlet/http/HttpSessionBindingListener.java
Sending src/main/java/javax/servlet/http/HttpSessionListener.java
Transmitting file data ........
Committed revision 64156.

Comment by Shing Wai Chan [ 06/Oct/15 ]

Sending status.fm
Transmitting file data .
Committed revision 116.





[SERVLET_SPEC-141] GenericFilter and HttpFilter Created: 23/Sep/15  Updated: 06/Oct/15  Resolved: 06/Oct/15

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours, 56 minutes
Original Estimate: Not Specified

Attachments: Zip Archive SERVLET_SPEC-141.zip    

 Description   

https://java.net/projects/servlet-spec/lists/users/archive/2014-10/message/1

The servlet API has a class HttpServlet which extends GenericServlet which
implements Servlet.

For filters, there's only Filter. Implementing this interface directly
incurs the following:

1) There are three methods to implement (init, destroy, doFilter). Most
often I only care about doFilter, so the other two are left empty.
2) doFilter takes ServletRequest and ServletResponse. In 95% of my cases I
need to cast these to HttpServletRequest and HttpServletResponse before I
can do anything useful.
3) If I need access to FilterConfig I need to assign it to a field in init(
FilterConfig)

Compare this to HttpFilter:

1) If I only care about doGet, that's the only method I need to override.
2) All do*-methods take HttpServletRequest, HttpServletResponse parameters,
so I don't need to cast.
3) GenericServlet already has the convenience methods getInitParameter*,
getServletConfig, getServletContext, getServletName and log.

Considering this usability asymmetry between servlets and filters, I
propose we add two new classes to the Servlet API, mostly adopted from it's
servlet cousins:

(Method bodies removed for readability)

public abstract class GenericFilter implements Filter {

@Override
public void destroy()

Unknown macro: { .. }



public String getInitParameter(String name)

public Enumeration<String> getInitParameterNames()

Unknown macro: { .. }



public FilterConfig getFilterConfig()

public ServletContext getServletContext()

Unknown macro: { .. }



public void init(FilterConfig config) throws ServletException

public void init() throws ServletException

Unknown macro: { .. }



public void log(String msg)

public String getFilterName()

Unknown macro: { .. }

}

and:

public abstract class HttpFilter extends GenericFilter {

@Override
public void doFilter(ServletRequest req, ServletResponse res,
FilterChain chain) throws IOException, ServletException {}

protected abstract void doFilter(HttpServletRequest request,
HttpServletResponse response, FilterChain chain) throws IOException,
ServletException ;

}

Adding these two classes will improve the usability of filters, reduce the
amount of boiler plate code, and make filter code more readable.

The cost is adding two new classes. But these classes are symmetric to the
already present HttpServlet / GenericServlet, so the conceptual surface
increase is minimal.

What do the exports think about this? Is this something we could consider
adding in the Servlet 4 time frame?

Thanks,
Eirik Bjørsnøs



 Comments   
Comment by Ed Burns [ 23/Sep/15 ]

committed to https://svn.java.net/svn/glassfish~svn/branches/SERVLET_SPEC-141
https://java.net/jira/browse/SERVLET_SPEC-141

SECTION: Modified Files

A src/main/javadoc/doc-files/changed_modified_4_0.png
A src/main/javadoc/doc-files/changed_added_4_0.png
A src/main/javadoc/doc-files/changed_modified_4_0_cursor.cur
A src/main/javadoc/doc-files/changed_added_4_0_cursor.cur
A src/main/javadoc/doc-files/changed_deleted_4_0.png
A src/main/javadoc/doc-files/changed_deleted_4_0_cursor.cur
M src/main/javadoc/javax.servlet-api.css
M pom.xml

  • Create topic branch
    Sending pom.xml
    Adding (bin) src/main/javadoc/doc-files/changed_added_4_0.png
    Adding (bin) src/main/javadoc/doc-files/changed_added_4_0_cursor.cur
    Adding (bin) src/main/javadoc/doc-files/changed_deleted_4_0.png
    Adding (bin) src/main/javadoc/doc-files/changed_deleted_4_0_cursor.cur
    Adding (bin) src/main/javadoc/doc-files/changed_modified_4_0.png
    Adding (bin) src/main/javadoc/doc-files/changed_modified_4_0_cursor.cur
    Sending src/main/javadoc/javax.servlet-api.css
    Transmitting file data ........
    Committed revision 64120.
    dhcp-orl3-2fl-gen-east-10-141-167-3:servlet-SERVLET_SPEC-141 ejburns$ svnhttp

https://svn.java.net/svn/glassfish~svn
dhcp-orl3-2fl-gen-east-10-141-167-3:servlet-SERVLET_SPEC-141 ejburns$ svncom
https://java.net/jira/browse/SERVLET_SPEC-141

SECTION: Modified Files

A src/main/javadoc/doc-files/changed_modified_4_0.png
A src/main/javadoc/doc-files/changed_added_4_0.png
A src/main/javadoc/doc-files/changed_modified_4_0_cursor.cur
A src/main/javadoc/doc-files/changed_added_4_0_cursor.cur
A src/main/javadoc/doc-files/changed_deleted_4_0.png
A src/main/javadoc/doc-files/changed_deleted_4_0_cursor.cur
M src/main/javadoc/javax.servlet-api.css
M pom.xml

  • Create topic branch
Comment by Ed Burns [ 23/Sep/15 ]

Snapshot of API.

Comment by Shing Wai Chan [ 29/Sep/15 ]

The above classes are directly parallel to GenericServlet and HttpServlet.
There is a typo in javadoc of GenericFilter#init():
Genericfilter.init --> GenericFilter.init





[SERVLET_SPEC-140] Clarify if the PrintWriter obtained from the ServletResponse is thread safe Created: 21/Sep/15  Updated: 29/Sep/15  Resolved: 29/Sep/15

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: markt_asf Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 30 minutes
Original Estimate: Not Specified


 Description   

The Servlet spec (section 2.3.3.4) states that neither the response nor the request are thread-safe and implies that neither are objects obtained from them.

The Javadoc for java.io.Writer implies that all Writers are thread-safe.

Currently, different containers have taken different approaches regarding the thread-safety of the PrintWriter obtained from the ServletResponse. It would help if the expected behaviour was explicitly defined in the spec.



 Comments   
Comment by Ed Burns [ 23/Sep/15 ]

Mark filed this issue on Monday. As Mark points out, section 2.3.3.4
states:

"the request and response objects are not thread safe."

Given that the PrintWriter is obtained from the admittedly not thread
safe response, and furthermore that this PrintWriter ultimately writes
to the response, it seems safest to say the following.

Any objects vended from the request or response must be assumed to be
not thread safe. For example, the PrintWriter returned from
ServletResponse.getWriter() and the OutputStream returned from
ServletResponse.getOutputStream() are not thread safe because they
ultimately interact with the response.

Is that sufficient?

Comment by markt_asf [ 24/Sep/15 ]

I like the proposed text. I'd like to propose a variation to try and keep the text consistent with 7.7.1 (the session object is thread safe). Something like:

Unless explicitly stated elsewhere in this specification (e.g. section 7.7.1 for session objects), objects vended from the request or response must be assumed to be not thread safe. This includes, but is not limited to, the PrintWriter returned from ServletResponse.getWriter() and the OutputStream returned from ServletResponse.getOutputStream().





[SERVLET_SPEC-138] Support for HTTP/2 Stream Priority Created: 14/Sep/15  Updated: 18/Sep/15  Resolved: 18/Sep/15

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Shing Wai Chan
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Add a new class Priority
boolean exclusive
int streamId
int weight
Priority dependency
Add method to HttpServletRequest
Priority getPriority()
Add methods to HttpServletResponse
Priority getPriority()
void setPriority(Priority p)



 Comments   
Comment by Ed Burns [ 14/Sep/15 ]

Work being done on topic branch https://svn.java.net/svn/glassfish~svn/branches/SERVLET_SPEC-138.

Comment by gregwilkins [ 16/Sep/15 ]

I'm very cautious about this proposal... specially the setPriority part.

Firstly from a HTTP2 perspective the priority is just the clients priority (probably based on a render strategy). This may be (and probably will be) entirely different to service priorities, which are more about achieving maximal throughput for minimal resource allocation, whilst protecting against DOS attack plus providing some degree of fair share between various users.

So at the very least, the getPriority() method should be renamed getClientPriority(). I think that for the most part, this information will be very hard to use unless service resources/scalability are not a concern. Ie. once a request has been dispatched so that something can call getClientPriority() the request, the server has already allocated significant resources to that request process, so that even if a subsequent request (or changed priority of an existing request) is received, the server may still be best to complete the processing of the low priority request with the resources already allocated (as they cannot generally be revoked). However, there are probably some special cases where priority can be used to decide between multiple requests to determine which progresses, so there is no harm exposing this information if it is available.

Note also, that client priority is dynamic and can be changed at any time - so perhaps a listener is needed?

Yet another complexity is that priority is not absolute and is relative only to other streams that may not have an outstanding request on them (in fact browsers have already proposed creating empty streams just so they can express priorities relative to them). There is no matching concept of stream in the Servlet API, so it will be hard to express priorities.

Finally, I don't see how we can set priority. The priority is the client priority and having the server set it to another value will not change the priority. Perhaps it could be used to override any low level priority handling when it comes to determining which bytes to send on which streams???

Comment by Ed Burns [ 16/Sep/15 ]

GW> I'm very cautious about this proposal... specially the setPriority
GW> part.

GW> Firstly from a HTTP2 perspective the priority is just the clients
GW> priority (probably based on a render strategy). This may be (and
GW> probably will be) entirely different to service priorities, which
GW> are more about achieving maximal throughput for minimal resource
GW> allocation, whilst protecting against DOS attack plus providing some
GW> degree of fair share between various users.

For incoming requests, it is certainly the case that the priority is the
client's priority.

GW> So at the very least, the getPriority() method should be renamed
GW> getClientPriority(). I think that for the most part, this
GW> information will be very hard to use unless service
GW> resources/scalability are not a concern.

But isn't the fact that getPriority() is on HttpServletRequest
sufficient indicator that this is the client's priority?

GW> Ie. once a request has been dispatched so that something can call
GW> getClientPriority() the request, the server has already allocated
GW> significant resources to that request process, so that even if a
GW> subsequent request (or changed priority of an existing request) is
GW> received, the server may still be best to complete the processing of
GW> the low priority request with the resources already allocated (as
GW> they cannot generally be revoked). However, there are probably some
GW> special cases where priority can be used to decide between multiple
GW> requests to determine which progresses, so there is no harm exposing
GW> this information if it is available.

Yes, that's our thinking in putting it on HttpServletRequest.

GW> Note also, that client priority is dynamic and can be changed at any
GW> time - so perhaps a listener is needed?

You mean the client sending an UPDATE frame while a request is in the
midst of being processed? That seems like a mess I don't want to get
into.

GW> Yet another complexity is that priority is not absolute and is
GW> relative only to other streams that may not have an outstanding
GW> request on them (in fact browsers have already proposed creating
GW> empty streams just so they can express priorities relative to
GW> them). There is no matching concept of stream in the Servlet API, so
GW> it will be hard to express priorities.

Ahh, I had neglected to file that other issue, I just filed it [1].

GW> Finally, I don't see how we can set priority. The priority is the
GW> client priority and having the server set it to another value will
GW> not change the priority. Perhaps it could be used to override any
GW> low level priority handling when it comes to determining which bytes
GW> to send on which streams???

Ahh, now I get it. Is it the case that the only time the server can
actually set a priority is when they originate a stream? And the only
time they do that is when they do server push, right? So perhaps it's
the case that priority needs to be added to the push API?

Thanks,

Ed

[1] https://java.net/jira/browse/SERVLET_SPEC-139

Comment by gregwilkins [ 16/Sep/15 ]

Maybe I'm convinced about the naming issue of having this on the Request API... but needs to be clear in javadoc.

Adding Request.getStreamId() is certainly good information to expose, but not sure that the model is correct for HTTP2 priorities as it is too request centric. The proposal is:

  • Requests MAY have streamIDs
  • Requests MAY have priority

But in HTTP2 it is:

  • Streams have Priority
  • Streams MAY have requests

ie streams can exist without requests and may be part of the priority tree

Comment by Shing Wai Chan [ 16/Sep/15 ]

EB> But isn't the fact that getPriority() is on HttpServletRequest
EB> sufficient indicator that this is the client's priority?

GW> Maybe I'm convinced about the naming issue of having this on the Request API...
GW> but needs to be clear in javadoc.

If that is the case, should we have #getPriority in HttpServletRequest only?

Comment by Shing Wai Chan [ 18/Sep/15 ]

The priority is from client side and seems to be too low level to include in Servlet API.
Per discussion in EG, we will mark this issue as "Won't Fix".





[SERVLET_SPEC-125] typo in method signature of getServletRegistrations() in p4-37 Created: 18/Feb/15  Updated: 14/Aug/15  Resolved: 13/Aug/15

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 4.0-m01

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In p4-37 of Servlet 3.1, we have Map<String, ? extends FilterRegistration> getServletRegistrations().
The method name should getFilterRegistrations().
There is a typo in description, too.



 Comments   
Comment by Shing Wai Chan [ 13/Aug/15 ]

The typo, FilterRegistration and FilterRegistration, have been fixed.

Comment by Shing Wai Chan [ 13/Aug/15 ]

r106 | swchan2 | 2015-02-17 18:22:08 -0800 (Tue, 17 Feb 2015) | 3 lines





[SERVLET_SPEC-124] deny-uncovered-http-methods is missing in Chapter 14 of Servlet spec Created: 18/Feb/15  Updated: 18/Feb/15  Resolved: 18/Feb/15

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 4.0-m01

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

missing deny-uncovered-http-methods is missing in the
Figure 14-1, Section 14.1, Section 14.4



 Comments   
Comment by Shing Wai Chan [ 18/Feb/15 ]

Sending deployment.fm
Sending images/web-app.png
Transmitting file data ..
Committed revision 105.





[SERVLET_SPEC-123] Clarify META-INF/resources in a jar is only for static content, not Java classes Created: 04/Feb/15  Updated: 06/Feb/15  Resolved: 06/Feb/15

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 4.0, 4.0-m01

Type: Improvement Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 30 minutes
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVLET_SPEC-22 Allow static resources to be served f... Resolved

 Description   

GW> Our understanding of META-INF/resources is that it is only for
GW> static content that can be obtained via getResource and that it is
GW> not a place where you can put things like WEB-INF/classes and expect
GW> them to appear on the context classpath.






[SERVLET_SPEC-93] Remove ambiguity in getServerName for IPv6 hosts Created: 11/Jul/14  Updated: 30/Jul/14  Resolved: 30/Jul/14

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gregwilkins Assignee: Rajiv Mordani
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVLET_SPEC-97 Host: header and IPv6 addresses Open

 Description   

Currently the javadoc for getServerName says:

/**

  • Returns the host name of the server to which the request was sent.
  • It is the value of the part before ":" in the <code>Host</code>
  • header value, if any, or the resolved server name, or the server IP
  • address.
    */

That this is ambiguous, since for a Host header like [::1]:8080, both "[::1]" (the part before the ":" ) and "::1" (the server IP) satisfy the javadoc.



 Comments   
Comment by Ed Burns [ 30/Jul/14 ]

Duplicates SERVLET_SPEC-97





[SERVLET_SPEC-91] Discourage Basic Authentication Created: 08/Jul/14  Updated: 19/Aug/15  Resolved: 19/Aug/15

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Ed Burns Assignee: Shing Wai Chan
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

According to Phil Hunt's blog entry, <https://blogs.oracle.com/fusionmiddleware/entry/standards_corner_ietf_revisits_http> there are a number of improvements in the recent HTTP 1.1 JSRs that should be investigated for their impact on Servlet.

Consider logging a message at deployment time if the use of basic authentication is detected.



 Comments   
Comment by markt_asf [ 10/Jul/14 ]

Why single out basic authentication? It is no better than form authentication from a security perspective and both are fine if used over SSL.

Comment by Shing Wai Chan [ 18/Aug/15 ]

I have looked through the RFC 7230 to RFC 725.
The basic are still used in examples of RFC 7231 'Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content' and RFC 7235 'Hypertext Transfer Protocol (HTTP/1.1): Authentication'.
I do not see any statement in the above RFCs for discouraging the usage of Basic Authentication.

Phil's blog seems to discuss the issue for client asking username and password in general.

Comment by Shing Wai Chan [ 19/Aug/15 ]

Since there is no explicit statement in the HTTP 1.1 RFCs about discouraging Basic Authentication, per discussion with filer, I will close the issue.





[SERVLET_SPEC-80] Wrong Javadoc for ServletContext.getInitParameter() Created: 20/Sep/13  Updated: 20/Sep/13  Resolved: 20/Sep/13

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: rgallard Assignee: Shing Wai Chan
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Original bug:
https://bugs.openjdk.java.net/browse/JI-9006641

The original incident is at http://webbugs.us.oracle.com/rt/incidentDisplay?incidentID=2592162

A DESCRIPTION OF THE PROBLEM :
The "Returns" section of getInitParameter() is wrong, it is actually the one of getServerInfo().

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
It should be something along the lines of:

a String containing the value of the named context-wide initialization parameter, or null if the parameter does not exist
ACTUAL -
a String containing at least the servlet container name and version number

URL OF FAULTY DOCUMENTATION :
http://docs.oracle.com/javaee/7/api/javax/servlet/ServletContext.html#getInitParameter%28java.lang.String%29



 Comments   
Comment by Shing Wai Chan [ 20/Sep/13 ]

It is duplicated of https://java.net/jira/browse/SERVLET_SPEC-77





[SERVLET_SPEC-83] ServletContext#getInitParameter with null parameter Created: 09/Oct/13  Updated: 18/Nov/15  Resolved: 13/Aug/15

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 4.0, 4.0-m01

Type: Improvement Priority: Major
Reporter: Shing Wai Chan Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours, 4 minutes
Original Estimate: Not Specified


 Description   

In the javadoc of ServletContext#getInitParameter, we have

Returns a String containing the value of the named context-wide initialization parameter, or null if the parameter does not exist.

What happens when the name parameter is null? Should we throw NPE?

Similar issue for #getAttribute?
We would like to have a more consistence answer for these?



 Comments   
Comment by Ed Burns [ 12/Aug/15 ]

I suggest we return the literal string "null" without the quotes. This is what GlassFish currently does.

Comment by Shing Wai Chan [ 12/Aug/15 ]

GlassFish throws NPE in this case.

Comment by markt_asf [ 13/Aug/15 ]

That should be if the name parameter is null for setInitParameter() and setAttribute.

Comment by Ed Burns [ 14/Aug/15 ]

Thanks, fixed.

Comment by pbenedict [ 18/Nov/15 ]

Don't you also want to apply this fix to #getInitParameter in ServletConfig, FilterConfig, GenericFilter, and GenericServlet?





[SERVLET_SPEC-77] Wrong @returns description of javax.servlet.ServletContext.getInitParameter Created: 02/Aug/13  Updated: 05/Aug/13  Resolved: 05/Aug/13

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Eugene Chung Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

http://docs.oracle.com/javaee/7/api/javax/servlet/ServletContext.html#getInitParameter(java.lang.String)

It says

a String containing at least the servlet container name and version number

as its return value. I think it's just a copy&paste mistake via getServerInfo().

The description should be the same as javax.servlet.ServletConfig#getInitParameter(String).



 Comments   
Comment by Shing Wai Chan [ 05/Aug/13 ]

Sending src/main/java/javax/servlet/ServletContext.java
Transmitting file data .
Committed revision 62445.





[SERVLET_SPEC-72] HttpUpgradeHandler and resource injection Created: 01/May/13  Updated: 14/Aug/15  Resolved: 13/Aug/15

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 4.0-m01

Type: Bug Priority: Major
Reporter: janbartel Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Servlet Spec 3.1, section 15.5, table 15.1 does not list the new HttpUpgradeHandler interface as supporting resource injection, postconstruct/predestroy annotations.

However the JavaEE 7 spec, section 5.2.5 table 5.1 does list it as requiring support for resource injection, postconstruct/predestroy.

Which is correct?



 Comments   
Comment by Shing Wai Chan [ 01/May/13 ]

The latter should be correct according to the description in 15.5.15 of Servlet 3.1.

Comment by janbartel [ 01/May/13 ]

I don't think that clarifies things, actually.

Section 15.5 of the servlet spec is entitled "Annotations and Resource Injection", yet the table 15.1 in that section is titled "Components and Interfaces supporting Annotations and Dependency Injection". Shouldn't that title be Resource injection rather than Dependency injection?

Section 15.5.15 of the servlet spec refers specifically instead to Context and Dependency Injection, not resource injection.

It seems to me that the JavaEE spec section 5.2.5 says explicitly that HttpUpgradeHandler needs to support annotations for Resource injection (and PostConstruct/PreDestroy), and also Context and Dependency injection iff CDI is enabled. So, the servlet spec needs to:

1. change the title of table 15.1 to refer to Resource injection, not Dependency injection (which is covered by sec 15.5.15)
2. add HttpUpgradeHandler to table 15.1

regards
Jan

Comment by Shing Wai Chan [ 01/May/13 ]

In my previous comment, I don't mean it is clarified. We will work on this.

Comment by Shing Wai Chan [ 13/Aug/15 ]

Sending javaEE.fm
Transmitting file data .
Committed revision 107.





[SERVLET_SPEC-69] NoBodyResponse in HttpServlet.java can have incorrect content length, should override setContentLengthLong(), others Created: 20/Mar/13  Updated: 24/Apr/13  Resolved: 24/Apr/13

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Nick Williams Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour


 Description   

(Note: See https://issues.apache.org/bugzilla/show_bug.cgi?id=53454 and https://issues.apache.org/bugzilla/show_bug.cgi?id=54734 for more details.)

The spec JAR contains a file-private class NoBodyResponse in HttpServlet.java that contains a bug in it. This bug has existed for a while but was made worse in the Servlet 3.1 Proposed Final Draft.

NoBodyResponse overrides:

public void setContentLength(int);

However, there are five other ways to change the content length of the response, and NoBodyResponse does not override any of them:

  public void setContentLengthLong(long); // added in Servlet 3.1
public void setHeader(String, String);
public void addHeader(String, String);
public void setIntHeader(String, int);
public void addIntHeader(String, int);

The setContentLengthLong(long) method should be overridden in NoBodyResponse to behave exactly like setContentLength(int). The four header methods should also be overridden, to check if the header name (case-insensitive) is "Content-Length" and behave the same way as setContentLength(int) if it is (Tomcat uses a private void checkHeader(String name) method that is called in of each of the four header methods).



 Comments   
Comment by Nick Williams [ 20/Mar/13 ]

I forgot to mention the negative side effects of not overriding these methods (detailed in Tomcat issue 53454 linked above): If the developer calls setContentLengthLong or any of the header methods to set the content length to some non-zero value in doGet, the HEAD request will still return a Content-Length of 0.

Comment by Shing Wai Chan [ 24/Apr/13 ]

This is an implementation issue and has been fixed in https://java.net/jira/browse/GLASSFISH-20396





[SERVLET_SPEC-49] error-code and error-exception are optional in error-page element Created: 18/Oct/12  Updated: 09/Jan/13  Resolved: 09/Jan/13

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: janbartel Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

See:

https://issues.apache.org/bugzilla/show_bug.cgi?id=52135
http://stackoverflow.com/questions/12854768/jetty-servlet-3-0-and-error-page

It appears the jsr315 spec group may have wanted to make a new feature of having error-pages without defining a code or exception name. Unfortunately there is no text about this in the 3.0 final specification. See section 10.9.2 Error Pages. This is not mentioned.

Nor is there any comment in the web-common.xsd schema.

The only information on this feature can be found on a blog from someone from oracle:
https://blogs.oracle.com/arungupta/entry/totd_136_default_error_page

If this is indeed a new feature that was added in servlet 3.0, this must be documented in the specification.

Jan



 Comments   
Comment by Shing Wai Chan [ 09/Jan/13 ]

We need to update the following:

  • web-common schema
  • section 14.4 No. 15, p.157 in Spec
  • section 10.9.2, p.108 in Spec
Comment by Shing Wai Chan [ 09/Jan/13 ]

The spec is updated as follows:
Sending applications.fm
Sending deployment.fm
Sending status.fm
Transmitting file data ...
Committed revision 64.

Concerning the schema, I have confirmed that it has been updated correctly in Servlet 3.0. We only need to add additional comments there.

Comment by Shing Wai Chan [ 09/Jan/13 ]

fix schemas:
Sending src/main/resources/glassfish/lib/schemas/web-common_3_1.xsd
Transmitting file data .
Committed revision 58247.

Sending javaee7/src/web-common_3_1.xsds
Transmitting file data .
Committed revision 58248.





[SERVLET_SPEC-48] Adding servlet programmatically vs @WebServlet Created: 17/Oct/12  Updated: 02/Nov/12  Resolved: 02/Nov/12

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In Section 8.1.1 of Servlet 3.0, we have the following:
If the same servlet class is declared in the deployment descriptor under a different name, a new instance of the servlet MUST be instantiated. If the same servlet class is added to the ServletContext via the programmatic API defined in Section 4.4.1, "Programmatically adding and configuring Servlets" on page 4-31 the values declared via the @WebServlet annotation MUST be ignored and a new instance of the servlet with the name specified MUST be created.

Both sentence should referred to adding the same servlet class with the "different name".
So, the second sentence should be modified as follows:
If the same servlet class is added with the different name to the ServletContext via the programmatic API defined in Section 4.4.1, "Programmatically adding and configuring Servlets" on page 4-31, the attribute values declared via the @WebServlet annotation MUST be ignored and a new instance of the servlet with the name specified MUST be created.



 Comments   
Comment by Shing Wai Chan [ 02/Nov/12 ]

Revisions:
----------
45

Modified Paths:
---------------
trunk/eod-pluggability.fm
trunk/status.fm





[SERVLET_SPEC-43] Clarify behaviour of HttpServletResponse#encodeURL() with relative URLs Created: 28/Jul/12  Updated: 06/Mar/13  Resolved: 06/Mar/13

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: markt_asf Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The Javadoc for HttpServletResponse#encodeURL() states that "The implementation of this method includes the logic to determine whether the session ID needs to be encoded in the URL."

The Javadoc gives one example of a test. Another possible test that may be performed is "Is the URL part of the web application?". If it is not, the session ID does not need to be encoded in the URL.

That highlights the question of how relative URLs should be treated. The options I see are:
a) relative URLs are always assumed to be part of the web application
b) relative URLs are always relative the current HttpServletRequest
c) container specific
d) something else

My current expectation is that b) is the intended behaviour and that it was not explicitly stated since it was viewed as the only possible option. It would be helpful of this expectation could be confirmed or denied and either way if a clarification could be added to the Javadoc for 3.1 onwards (and earlier versions where possible).

Note the same issue exists for encodeRedirectURL()

This question was triggered by https://issues.apache.org/bugzilla/show_bug.cgi?id=53469



 Comments   
Comment by Shing Wai Chan [ 09/Feb/13 ]

Since the #encodeURL string may be used later, we may like to keep it as relative, too.
For #encodeRedirectURL, I expect (b), too.

Comment by markt_asf [ 09/Feb/13 ]

That works for me. If some language can be added that relative URLs passed to encodeURL() and encodeRedirectURL() are relative to the current request that would be great.





[SERVLET_SPEC-42] Clarify wether @WebServletAnnotation can complete a preliminary servlet registration Created: 04/Jul/12  Updated: 25/Feb/13  Resolved: 14/Feb/13

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: janbartel Assignee: Rajiv Mordani
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The <servlet> web.xml element was changed to remove the requirement to specify a <servlet-class>. This results in what is referred to as a "preliminary servlet registration". The specification/javadocs describe how the ServletContext.addServlet() methods can be used to complete the registration, but does not mention whether or not a WebServletAnnotation can be used to do so.

Eg
web.xml contains:
<servlet>
<servlet-name>Foo</servlet-name>
</servlet>

FooServlet.java contains:
@WebServlet(urlPatterns =

{"/","/test/*"}

, name="Foo", initParams=

{@WebInitParam(name="fromAnnotation", value="xyz")}

)
public class FooServlet extends HttpServlet

Is the servlet registration for "Foo" updated with classname "FooServlet" after processing the annotation?



 Comments   
Comment by Rajiv Mordani [ 18/Jul/12 ]

Yes the idea is that a descriptor can override any information specified in the annotation (look at the rules for merging in the spec.) So to answer your question as long as metadata-complete is not set - the annotation and descriptor combine to give the effective declaration.

Comment by Rajiv Mordani [ 25/Feb/13 ]

Also in the javadocs for Registration.java it clearly says - "A Registration object whose

{@link #getClassName}

method returns null is considered <i>preliminary". If a servlet is annotated, the getClassName will not return null and hence will not be considered preliminary.





[SERVLET_SPEC-34] Auth constraint that requires a valid user, but does not require any particular role Created: 16/Mar/12  Updated: 01/Mar/13  Resolved: 01/Mar/13

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: elygre Assignee: Shing Wai Chan
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: security

 Description   

For many applications, the it is desirable to have authentication handled by the container, while authorization must be handled by the application login. In such scenarios, it would be useful to require the a user is logged on, without having to specify roles.

There is precendence for this kind of security from other environments:

Since the last one conflicts with the current spec, maybe something like this would work:

<auth-constraint anyAuthenticatedUserAllowed="true" />
@ServletSecurity(@HttpConstraint(anyAuthenticatedUserAllowed=true))
public class Example4 extends HttpServlet {
}


 Comments   
Comment by Shing Wai Chan [ 09/Jan/13 ]

According to JSR 115 MR2, "*" means all the roles defined for the web app.
It is not any users there.

Comment by elygre [ 09/Jan/13 ]

Shing Wai Chan Yes, that is correct. This issue is an enhancement request for a new auth-constraint that does not require roles, but instead just requires any valid user.

The use case is very common. As show above, the google app-engine deviates from the servlet spec and redefines this aspect of web.xml to support the use case. That should be a strong argument that there is a market requirement.

Comment by Shing Wai Chan [ 10/Jan/13 ]

"*" is for any roles rather than users as defined in JSR 115.
We need to investigate a backward compatible solution.

One way to achieve this is to have the realm to add a universal role to any authenticated users. This is how GlassFish resolve this issue.
You can find more details in
https://blogs.oracle.com/swchan/entry/assign_groups

Comment by elygre [ 10/Jan/13 ]

I totally agree that we need a backward compatible solution. The jira issue does not suggest using the role name "*" at all, but clearly states that this "conflicts with the current spec", and suggests that something else is needed, "maybe the something like this would work":

<auth-constraint anyAuthenticatedUserAllowed="true" />

The GlassFish solutions is interesting. I would hope for a servlet-level solution (which would then be supported by all appservers), but at least it serves to further validate the requirement

Comment by Shing Wai Chan [ 01/Mar/13 ]

A special role "**" is added to achieve this in the spec.
Please see section 13.3 of the Servlet 3.1 PFD for details.

Comment by Shing Wai Chan [ 01/Mar/13 ]

See also section 13.4.1.3 in Servlet 3.1 PFD.





[SERVLET_SPEC-36] Clarify relationship of metadata-complete and ServletContainerInitializers Created: 29/Mar/12  Updated: 14/Aug/12  Resolved: 14/Aug/12

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: janbartel Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Servlet Spec 3.0 does not make clear what relationship exists between metadata-complete setting in web.xml and the discovering and invocation of ServletContainerInitializers.

The stated purpose of ServletContainerInitializers is to allow for pluggable framework initialization, and the given example is initializing the JSP container. This implies that a setting of metadata-complete=true is irrelevant to the finding and calling of ServletContainerInitializers.

If so, even if metata-complete==true for a given webapp, then we are forced to scan every class available to the webapp in the case that a discovered ServletContainerInitializer has a @HandlesTypes annotation - if the HandlesTypes specifies an annotation, then we will scan every class for that annotation, or if HandlesTypes specifies a class, then we need to scan for that class and its descendants. This can take a significant amount of time for a webapp with a large number of jars in WEB-INF/lib.

Please clarify if this is correct, or if metatadata-complete==true means that all ServletContainerInitializers are ignored.



 Comments   
Comment by Shing Wai Chan [ 18/May/12 ]

The metadata-complete and invocation of ServletContainerInitializers are independent.

Comment by markt_asf [ 22/Jun/12 ]

There is one further additional clarification required.

If metadata-complete=true, that implies that any fragment ordering specified is ignored.

However, if the main web.xml specifies an absolute ordering when metadata-complete=true, are all JARs in WEB-INF/lib processed for ServletContainerInitializers or are JARs excluded from the ordering still excluded from the processing for ServletContainerInitializers?

Comment by Rajiv Mordani [ 26/Jul/12 ]

If metadata-complet is true - then the web-fragments (not only the ordering) are ignored. Howerver the jars in WEB-INF/lib will still be processed for ServletContainerInitializers. Ordering does not apply to ServletContainerInitializers.

Comment by Shing Wai Chan [ 27/Jul/12 ]

From p.67 of Servlet 3.0 spec, we have
"The <absolute-ordering> element may contain zero or one <others /> element. The required action for this element is described below. If the <absolute-ordering> element does not contain an <others/> element, any web-fragment not specifically mentioned within <name /> elements MUST be ignored. ... If a discovered ServletContainerInitializer is loaded from an excluded jar, it will be ignored. Excluded jars are not scanned for classes to be handled by any ServletContainerInitializer."

So, excluded jars in absolute-ordering independent of metadata-complete=true will not be scanned for ServletContainerInitializers.

Comment by markt_asf [ 28/Jul/12 ]

<quote>
So, excluded jars in absolute-ordering independent of metadata-complete=true will not be scanned for ServletContainerInitializers.
</quote>

works for me since it provides a way to disable scanning for SCIs.

Comment by Mark Struberg [ 30/Jul/12 ]

Shing, Rajiv could you please point me to the spec paragraph where it's written down that ServletContainerInitializer class scanning must be done regardless of metadata-complete="true"?

Because Section 8.2.1 seems to contradict your statement:

8.2.1: "As before, if the metadata-complete element is set to true in the web.xml descriptor, annotations in the class files and web-fragments bundled in jars will not be processed."
There is no exclusion or "unless stated otherwise" ...

There is a more detailed statement for ServletContainerInitializers in 8.2.2:
"If a discovered ServletContainerInitializer is loaded from an excluded jar, it will be ignored. Excluded jars are not scanned for classes to be handled by any ServletContainerInitializer."

The whole 8.2.4 section also doesn't define any exception.
And section 8.4 "Processing annotations and fragments" seems to underline my interpretation.

To me as uneducated servlet spec reader (though an educated EG member) I read it in summary that ServletContainerInitializers shall get ignored if metatadata-complete="true" is set in WEB-INF/web.xml.

Again: maybe I just didn't search good enough and there is a clear definition in the spec that it should get processed - if so, then please point me to it - thanks!

If not: the rules of the JCP define that once a spec is final then ONLY the released JavaDocs and the spec wording counts - not any 'intent' anymore...

I also do not really understand the goal of this interpretation.
If I set metatdata-complete="true" then I fnnnnn dare don't like any 'implicit' mechanisms. Each EE container brings a ServletContainerInitializer for JSF, JAX-RS, JAX-WS, and tons of others. But what if I like to build something completely different? Some Tapestry or even jruby app? Then I get all the crap activated which is not needed in my case?

I'm also not sure if an empty <absolute-ordering/> would work, as web-fragments are only jars in WEB-INF/lib but ServletContainerInitializer clearly also targets other shared container classpaths as well.

Comment by Shing Wai Chan [ 30/Jul/12 ]

The metadata-complete=true means the completeness of data specified in deployment descriptor.
But it does not mean the annotation will be ignored in the given application.
For instance, CDI annotations will still be scanned and processed.

The ServletContainerInitializer is a service provider specified in META-INF/services, not by annotation. In a ServletContainerInitializer, there may be a @HandlesTypes, which does not have corresponding metadata in deployment descriptor. Since a ServletContainerInitializer and @HandlesTypes are worked together, it should be interpreted whenever a ServletContainerInitializer is loaded.

Comment by Mark Struberg [ 31/Jul/12 ]

Shing, don't get me wrong. The question is not whether you think it should not be scanned by the servlet engine but whether it's written down in the spec. I just found a few paragraphs which all seem to express that absolutely no annotation scanning is done if metadata-complete="true" is set. And there are even a few paragraphs which define this explicitly for ServletContainerInitializer!

Thus I'll ask again: please point me to the paragraphs in the spec which underlines your interpretation. I just could not find it, but I only quickly read through it so I might have overlooked it.

There are 3 possible situations now:

a.) Your 'interpretation' is expressed in a paragraph of the servlet-3.0 spec PDF (or JavaDocs). And this wording is clear that the other paragraphs do not count. Well, then servlet containers must scan of course!

b.) The spec wording is ambiguous and the still to be found paragraph and the few paragraphs I pointed to (expressing the opposite) are expressing contrary facts. In that case you should clarify this in the next spec. Until then any servlet container would be free to implement it as they like.

c.) There is no such paragraph which explicitly expresses that annotations must get scanned even if metadata-complete="true". In that case only this spec wording counts. If you would like to change this behaviour then I suggest you read through the guidelines of how to cope with incompatible changes in Java specs. You are e.g. only allowed to change this in a full release and not in a MR.

I've perfectly understood that the ServletContainerInitializer uses the java.util.ServiceProvider and not web.xml, but please read 8.2.2:
"If a discovered ServletContainerInitializer is loaded from an excluded jar, it will be ignored. Excluded jars are not scanned for classes to be handled by any ServletContainerInitializer."

There is NO room for any other interpretation imo! At least if there is not yet another paragraph which expresses any contrary behaviour.
The problem with java.util.ServiceLoader is that you can easily enable it, but there is NO way to disable it!

And for the CDI class scanning. Of course a CDI container will scan for annotations, but only if a beans.xml is found for that jar - otherwise it won't. It happens that I'm one of the guys writing the CDI spec...

Comment by Shing Wai Chan [ 31/Jul/12 ]

The following is from schema of web.xml:
"The metadata-complete attribute defines whether this deployment descriptor and other related deployment descriptors for this module (e.g., web service descriptors) are complete, or whether the class files available to this module and packaged with this application should be examined for annotations that specify deployment information.
If metadata-complete is set to "true", the deployment tool must ignore any annotations that specify deployment information, which might be present in the class files of the application."

So, the metadata-complete is related to annotations that specify deployment descriptor information. But there is no deployment descriptor for @HandlesTypes in this case.
(CDI is another example that the annotations specifying information not in deployment descriptor.)

While sending my previous comments, I have sent an email to Servlet 3.1 EG about adding a clarification ("independent of metadata-complete") in 8.2.4 as follows:
"In addition to the ServletContainerInitializer we also have an annotation - HandlesTypes. The annotation will be applied on the implementation of ServletContainerInitializer, independent of metadata-complete, to express interest in classes that are either annotated with the classes specified in the value or if a class extends / implements one of those classes anywhere in the classes super types."

Comment by Mark Struberg [ 31/Jul/12 ]

The quote you just posted is another argument for NOT scanning if metadata-complete="true".

Shing, just to make the clear point: CURRENTLY the servlet-3.0 spec DEFINES CLEARLY that metadata-complete="true" DISABLES ANY class scanning!

There are a dozen paragraphs which underline this point of view in the spec + in the JavaDocs + even in the schema for web.xml. And there seems to be NONE which says the opposite.

There is just NOTHING to clarify as the wording is absolutely clear. You could just clarify things which are not or not defined at all or not sufficiently clear defined!

As it seems to stand now (unless someone posts the paragraph which defines the opposite), the Servlet-3.0 specification clearly defines that metadata-complete="true" disables any class-scanning and ServletContainerInitializers wont get picked up neither.

Let's look at this from another side: what are you trying to achieve? What is the reason (use-cases) why you like to have it automatically enabled, even if a user says he doesn't like to get any stuff?

Comment by Mark Struberg [ 31/Jul/12 ]

PS: for servlet-3.1 you should pick up the discussion initiated in the EE-7 umbrella spec about a generic scan.xml which tries to cover the scanning aspects for all the EE parts.

Comment by Shing Wai Chan [ 31/Jul/12 ]

Mark, according to document for web.xml schema mentioned above, metadata-complete is "only" related to "annotations that specify deployment information". It is "not" for "any" annotation. This is not specific to servlet spec. Java EE spec, for instance ejb-jar_3_1.xsd, also defines the metadata-complete this way.

Comment by Mark Struberg [ 31/Jul/12 ]

Yes Shing, I understood your argument. But please allow me to disagree with the underlying subsumption: as the ServletContainerInitializer is a 'metadata pickup mechanism' (it's defined in the servlet spec and used to initialize webapps), and the web.xml is the configuration for all stuff handled by the servlet spec, it imo certainly qualifies as 'servlet metadata' so to speak.

Of course there is no 1:1 analogon between the ServletContainerInitializer and a web.xml tag, but it is kind of a 'bracelet' around various of them.

Please look at servlet-3.0 8.2.4, 8.2.1 and a few other paragraphs. In all those the ServletContainerInitializer is mentioned on exactly the same level as all other servlet-spec 'metadata'. I can see no reason for not applying the same rules defined to the other parts of the spec.

One of my argumentation chain is the following (there are actually quite a few arguments, for paragraphs see above):

1.) a jar is a web fragment. explicit or implicit
2.) if metadata-complete="true" is set in WEB-INF/beans.xml only the web-fragments in <absolute-ordering> count. If there is no <absolute-ordering> then there is no web-fragment enabled.
3.) 8.2.2: "If a discovered ServletContainerInitializer is loaded from an excluded jar, it will be ignored. Excluded jars are not scanned for classes to be handled by any ServletContainerInitializer."

With which of the points don't you agree?

Comment by Shing Wai Chan [ 31/Jul/12 ]

Besides web.xml, there are other metadata in a web application.
Prior to Servlet 3.0, a classpath can be specified in MANIFEST.MF.
In Servlet 3.0, web-fragment.xml can be specified in a given jar.

I see ServletContainerInitializer in 8.2.2 and 8.2.4, but not in 8.2.1.
The included jars, hence excluded jars, specify in <absolute-ordering> is independent of the value of metadata-complete.
In 8.2.2, it describes the behaviors of excluded jars.
In 8.2.4, it is not related to deployment descriptor metadata.

ServletContainerInitializer is a service provider specified in META-INF/services.
And it can be resided in a jar outside a web application.

And in general, the ServletContainerInitializer is for framework like jsp, jsf, etc.
Jsp and Jsf should not be turned off when metadata-complete=true (cf. section 8.3 of Servlet 3.0 spec).

Comment by Mark Struberg [ 31/Jul/12 ]

I'm not sure what your point with the manifest is?

> The included jars, hence excluded jars, specify in <absolute-ordering> is independent of the value of metadata-complete.

8.2.1: "... As before, if the metadata-complete element is set to true in the web.xml descriptor, annotations in the class files and web-fragments bundled in jars will not be processed."

or a bit paraphrased: "... if the metadata-complete element is set to true ... web-fragments bundled in jars will not be processed.".

Which I read as: No annotations, no web-fragments, which mean jars of web-fragments not listed in the web.xml are excluded from processing if metadata-complete="true". Is this interpretation correct? Yes/No?

And now please combine this with the rules specified in 8.2.2:
"Excluded jars are not scanned for annotated servlets, filters or listeners. However, if a servlet, filter or listener from an excluded jar is listed in web.xml or a non-excluded web-fragment.xml, then it's annotations will apply unless otherwise excluded by metadata-complete. ServletContextListeners discovered in TLD files of excluded jars are not able to configure filters and servlets using the programmatic APIs. Any attempt to do so will result in an IllegalStateException. If a discovered ServletContainerInitializer is loaded from an excluded jar, it will be ignored. Excluded jars are not scanned for classes to be handled by any ServletContainerInitializer."

I just mentioned 8.2.4, because it does not mention any exclusions to the general rules defined in 8.2.1.

Comment by Shing Wai Chan [ 31/Jul/12 ]

I mention MANIFEST.MF as another example of metadata.

We may like to clarify the wording of 8.2.1 to be more specific to deployment descriptor related annotations.
If we interpret 8.2.1 as no processing for "all" annotation, then does it means that CDI annotations should not be processed. Of course, this is "not" the case. (And this is also contradict the documents in web.xml schema.)

Also, in our case, we have the annotation, @HandlesTypes. And if we do not process @HandlesTypes (when metadata-complete=true) and still look up the META-INF/services, in this case, ServletContainerInitializer, then the ServletContainerInitializer will not be working properly.

As I mentioned before, we would have a clarification on 8.2.4. And we would like to be more specific about the deployment descriptor related annotations.

Comment by Shing Wai Chan [ 31/Jul/12 ]

This issue is discussed in expert group and the email archive can be found in http://java.net/projects/servlet-spec/lists/users/archive with subject "About SERVLET_SPEC-36".

Comment by Mark Struberg [ 01/Aug/12 ]

> If we interpret 8.2.1 as no processing for "all" annotation, then does it means that CDI annotations should not be processed.
You are mixing apples with eggs. What does the CDI annotations have to do with servlet specific annotations?

The main point here is: if you don't allow a user to disable the SCI somehow, then this might be a major pain in some situations!

In our case it IS already a major pain that SCI automatically start if there is no web.xml. Not only the vastly higher scan times, but e.g. JSF defines that a SCI must be present for automatically starting JSF. In our case this did lead to starting JSF for our resources webapp which contains no JSF at all! It just blew up on servlet-3.0 containers and we had to do crazy things to get rid of it.

I'm perfectly fine if an empty <absolute-ordering/> finally will disable SCI pickup!

Please allow me to ask for another clarification:
What is the lifecycle of the SCI? It's name "Serlvet CONTAINER Initializer" indicates that this only gets scanned 1 time when the container boots. Completely independent of any web application deployed therein.
8.2.4 "An instance of the ServletContainerInitializer is looked up via the jar services API by the container at container / application startup time"

It also defines when the onStartup method gets called, but I have not yet understood if there is 1 SCI instance per webapp and SCI-Class or if the container startup creates a singleton for the whole container and all webapps invoke the onStartup to the same instance? Is this mentioned somewhere? This has a major impact about how to write the SCIs. Please also think about having 2 webapps containing jsf-impl.jar in their WEB-INF/lib (so the same JsfSCI but in 2 different isolated classloaders) vs having the jsf-impl.jar in a container lib dir.

Comment by Shing Wai Chan [ 14/Aug/12 ]

The metadata-completed is clarified as mentioned above. For ServletContainerInitializer, an instance will be created at each application startup time.

Sending eod-pluggability.fm
Sending overview.fm
Sending status.fm
Transmitting file data ...
Committed revision 41.





[SERVLET_SPEC-35] Clarification on section 4.4 Servlet Context Configuration Methods Created: 24/Mar/12  Updated: 05/Mar/13  Resolved: 05/Mar/13

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Christian Ludt Assignee: Rajiv Mordani
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If the ServletContext passed to the ServletContextListener's
contextInitialized method was neither declared in web.xml or
webfragment.xml nor annotated with @WebListener then an
UnsupportedOperationException MUST be thrown for all the
methods defined for programmatic configuration of servlets,
filters and listeners.

This sentence is misleading; leaving out the relative clause gives:

If the ServletContext was neither declared in web.xml or webfragment.xml nor annotated with @WebListener [...]

The ServletContext is created by the Servlet container and can neither be declared in web.xml or webfragment nor annotated, but the ServletListenerContext can be. So, if

neither declared in web.xml or webfragment.xml nor annotated with @WebListener

refers to ServletContextListener, please make that clear.

Still, I don't understand, why and when an UnsupportedOperationException must be thrown. Must it be thrown when that ServletContextListener is added via ServletContext#addListener? What sense would it make to throw an exception here? If that listener had been declared in web.xml or webfragment.xml or annotated, there would be no need to add it programmatically in the first place.



 Comments   
Comment by janbartel [ 01/Mar/13 ]

Can we please have some clarification on what this wording means prior to Public Final release?

There was never any answer to Mark's question on the email thread about this issue "About SERVLET_SPEC_35" on the mailing list.

thanks
Jan

Comment by Rajiv Mordani [ 04/Mar/13 ]

Yes the reference is to the ServletContextListener and not the ServletContext.

The case I believe we were trying to address with this in Servlet 3.0 time was that when ServletContextListener was created from a TLD, then those listeners should not be allowed to use the programmatic APIs.

Comment by Rajiv Mordani [ 05/Mar/13 ]

Yes in fact I did go back and look at the servlet 3.0 archives and we want to disallow the ServletContextListeners that were declared in TLDs. I have clarified the fact that it is the listener and not the ServletContext that needs to be declared and am marking this issue as fixed.





[SERVLET_SPEC-53] Clarify expected behaviour if multiple servlets are mapped to the same URL pattern Created: 08/Jan/13  Updated: 09/Jan/13  Resolved: 09/Jan/13

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: markt_asf Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I have checked through the latest specification draft and can;t find any language covering this.

If I map both servletA and servletB to /foo in web.xml what happens? Clearly, they can't both execute.

My expectation at this point is that a web application with multiple servlets mapped to exactly the same url pattern should fail to start.

Please could we add some clarifying language to the Servlet 3.1 spec.



 Comments   
Comment by Shing Wai Chan [ 09/Jan/13 ]

Sending requestmappings.fm
Transmitting file data .
Committed revision 63.





[SERVLET_SPEC-51] Clarification is needed for ServletContext.addFilter(...) and ServletContext.addServlet(...) Created: 03/Jan/13  Updated: 08/Jan/13  Resolved: 08/Jan/13

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: violetagg Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Hi,

Javadoc for ServletContext.addFilter(...)/ServletContext.addServlet(...) does not specify what should be the behaviour when filterName/servletName is NULL.

Would you specify whether filterName/servletName is mandatory or optional and what should be the behaviour of these methods.

From my point of view filterName/servletName should be mandatory and IllegalArgumentException should be thrown when filterName/servletName is NULL.

Thanks in advance
Violeta Georgieva



 Comments   
Comment by BGehrels [ 03/Jan/13 ]

My feelings about this issue are a little bit ambivalent.

On the one hand side the servlet and filter names are used in other parts of the ServletContext API, for example in getServletRegistrations(). If one would make filterName/servletName optional, then the behaviour for those methods would be unclear.

On the other hand, there is no need for a name, if you configure your whole WebApp using the addServlet/addFilter-Mechanism: The filterName is mainly usefull to reference your servlet from other locations. When using the Java API, javax.servlet.ServletRegistration.Dynamic/javax.servlet.FilterRegistration.Dynamic are used to reference your Servlet/Filter registrations. So, for those users, having to generate a unique name for each servlet and each filter is useless and may also be non-trivial when you are writing generic frameworks (for example).

From my point of view, having a way to define anonymous filters/servlets would be a very nice thing to have. One (ugly) way to allow this would be, to allow null values hier. A better way would probably be to add

public ServletRegistration.Dynamic addServlet(String className);
public ServletRegistration.Dynamic addServlet(Servlet servlet);
public ServletRegistration.Dynamic addServlet(Class <? extends Servlet> servletClass);
public FilterRegistration.Dynamic addFilter(String className);
public FilterRegistration.Dynamic addFilter(Filter filter);
public FilterRegistration.Dynamic addFilter(Class <? extends Filter> filterClass);

to the ServletContext interface.

Comment by markt_asf [ 03/Jan/13 ]

ServletContext#getServletRegistrations() and ServletContext#getFilterRegistrations() can't work if there are multiple anonymous Servlets or multiple anonymous Filters since while Map implementations may support null keys, they don't (and can't) support multiple null keys in a single map since keys have to be unique.

Given the above and the wording of the Javadoc for ServletContext#addFilter() and ServletContext#addServlet() I think there is a strong argument that the names are required and that the Servlet specification should be clarified make this clear. I'd be fine with adding a requirement for a IAE if a null name is provided.

Comment by Shing Wai Chan [ 03/Jan/13 ]

I agree that we should throw IllegalArgumentException for ServletContext#addFilter and ServletContext#addServlet if null name is used.
In no. 7 of section 14.4 of the spec, we have:
"The element content of filter-name element must not be empty."

In this case, I think we need to throw IllegalArgumentException if the name is "".

Comment by violetagg [ 04/Jan/13 ]

Hi,

In this case, I think we need to throw IllegalArgumentException if the name is "".

If we start returning IAE when the filterName/servetName is "" then we need clarification also for WebFilter and WebServlet.
In the javadoc "" is default for filterName/servletName.

javax.servlet.annotation.WebFilter

filterName

public abstract java.lang.String filterName
The name of the filter
Default:
""

javax.servlet.annotation.WebServlet

name

public abstract java.lang.String name
The name of the servlet
Default:
""

We can use the class name of the filter/servlet as default instead of "".
What do you think?

Thanks
Violeta

Comment by Shing Wai Chan [ 04/Jan/13 ]

For @WebServlet, we have
"The default name of the Servlet if not specified is the fully qualified class name."
Similarly for @WebFilter.
So the name is "fully qualified class name" in this case.

Comment by Shing Wai Chan [ 08/Jan/13 ]

The fix has been to javadoc of ServletContext.java
svn 57969





[SERVLET_SPEC-57] Add getFileName() method to javax.servlet.http.Part Created: 18/Feb/13  Updated: 01/Mar/13  Resolved: 01/Mar/13

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Nick Williams Assignee: Shing Wai Chan
Resolution: Fixed Votes: 3
Labels: None
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours
Environment:

All


Tags: HttpServletRequest, Part, file_upload, filename

 Description   

The javax.servlet.http.Part interface lacks a method for retrieving the file name of a part. Most request parts have file names, typically provided by the client's browser as the name of the file on the client's file system when the file is uploaded through the form submission. Currently, consumers of Part must create their own method to extract the file name:

public static String getFileName(Part filePart)
{
    String header = filePart.getHeader("content-disposition");
    for(String headerPart : header.split(";"))
    {
        if(headerPart.trim().startsWith("filename"))
        {
            return headerPart.substring(headerPart.indexOf('=') + 1).trim()
                             .replace("\"", "");
        }
    }
    return null;
}

Tomcat, as an example, already has a method to extract the file name in its Part implementation, but since it is not exposed via the public Part interface developers cannot use it without limiting the portability of their applications. It's possible other containers already do something similar.

The suggested getFileName() method should:

  • Locate the Content-Disposition header from the Part. If no such header exists, return null.
  • Extract the filename attribute from the Content-Disposition header and return its value trimmed.
  • If no filename attribute exists or the filename attribute value is null, return null.
  • Not throw any exceptions.

Estimate 5 minutes to add the method to the interface and < 2 hours to add relevant documentation regarding the method to the spec.



 Comments   
Comment by Nick Williams [ 18/Feb/13 ]

Note that the sample code submitted does not follow the second part of rule 1, "If no such header exists, return null." A more stable implementation would be:

public static String getFileName(Part filePart)
{
    String header = filePart.getHeader("content-disposition");
    if(header == null)
        return null;
    for(String headerPart : header.split(";"))
    {
        if(headerPart.trim().startsWith("filename"))
        {
            return headerPart.substring(headerPart.indexOf('=') + 1).trim()
                             .replace("\"", "");
        }
    }
    return null;
}

Of course, this is merely a sample implementation, and container developers are free to implement the spec in their own way.

Comment by carojkov [ 18/Feb/13 ]

I'd like to propose a method name that clearly states that this is a file name specified by the client. e.g. getClientFileName(). getRequestedFileName() or getSubmittedFileName(). This should help avoid confusion if/when it's decided if adding another get*File() method to the Part is needed. i.e. getFile() returning File after a call to Part#write(String) method.

Comment by Nick Williams [ 18/Feb/13 ]

I agree. I prefer getSubmittedFileName(). Seems the most applicable, as that's exactly what it is: nothing more or less than the submitted file name.

Comment by markt_asf [ 18/Feb/13 ]

+1

Comment by Nick Williams [ 20/Feb/13 ]

By the way, Mark, if this gets accepted for 3.1 I'll implement it in Tomcat. Should just be a matter of adding the method to the interface and then implementing the method in ApplicationPart to wrap ApplicationPart#getFilename().

Comment by Shing Wai Chan [ 01/Mar/13 ]

Add a method Part#getSubmittedFileName

Sending src/main/java/javax/servlet/http/Part.java
Transmitting file data .
Committed revision 59926.





[SERVLET_SPEC-56] clarify effect of disabling the use of url rewriting for session tracking on HttpServletResponse.encodeURL() and HttpServletResponse.encodeRedirectURL() Created: 14/Feb/13  Updated: 05/Mar/13  Resolved: 05/Mar/13

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: monzillo Assignee: Shing Wai Chan
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

when url rewriting has been disabled as a session tracking mechanism
HttpServletResponse.encodeURL() and HttpServletResponse.encodeRedirectURL() must
not encode the session identifier.



 Comments   
Comment by Shing Wai Chan [ 05/Mar/13 ]

Update javadoc for HttpServletResponse#encodeRedirectURL
fix in svn commit 59928





[SERVLET_SPEC-55] recommend that login from specify autocomplete=off Created: 14/Feb/13  Updated: 05/Mar/13  Resolved: 05/Mar/13

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: monzillo Assignee: Shing Wai Chan
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

submitting recommendation from Jeff Williams



 Comments   
Comment by Shing Wai Chan [ 05/Mar/13 ]

Sending security.fm
Sending status.fm
Transmitting file data ..
Committed revision 80.





[SERVLET_SPEC-54] Javadoc inconsistent for HttpServletRequest#changeSessionId() Created: 13/Feb/13  Updated: 14/Feb/13  Resolved: 14/Feb/13

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: markt_asf Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The Javadoc for the above method has inconsistent statements about the return value.

<quote>
String changeSessionId()

Change the session id of the current session associated with this request and return the new session id.

Returns: the original session id
</quote>

I believe that the return value should be the new ID



 Comments   
Comment by Shing Wai Chan [ 14/Feb/13 ]

Sending src/main/java/javax/servlet/http/HttpServletRequest.java
Transmitting file data .
Committed revision 59507.





[SERVLET_SPEC-64] Wording of section 8.2.4 Shared libraries/runtimes pluggability is unclear or incorrect Created: 01/Mar/13  Updated: 12/Mar/13  Resolved: 04/Mar/13

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: janbartel Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

From the 2nd Public Draft:

Page 89/90:
"In addition to the ServletContainerInitializer we also have an annotation -
HandlesTypes. The HandlesTypes annotation on the implementation of the
ServletContainerInitializer is used to express interest in classes that may
have anotations (type, method or field level annotations) specified in the value of the
HandlesTypes or if it extends / implements one those classes anywhere in the
class' super types. The HandlesTypes annotation is applied irrespective of the
setting of metadata-complete. The container uses the HandlesTypes annotation
to determine when to invoke the initializer's onStartup method."

Having or not having a @HandlesTypes annotation does not influence when the onStartup method is called at all AFAICT - later on the spec says that the the onStartup method is always called when the application is starting up.

"When examining the classes of an application to see if they match any of the criteria specified by the
HandlesTypes annotation of a ServletContainerInitializer, the container
may run into class loading problems if one or more of the application's optional JAR
files are missing. Since the container is not in a position to decide whether these
types of class loading failures will prevent the application from working correctly, it
must ignore them, while at the same time providing a configuration option that
would log them."

This sentence doesn't fit very well with the preceding one, which is talking about when the onStartup method is called. Mention of potential problems in loading the classes of the HandlesTypes, and a requirement for logging should be in a separate paragraph.

Page 80:
"The onStartup method of the ServletContainerInitializer will be invoked
when the application is coming up before any of the listener's events are fired."

Which listener are we talking about here? A listener has not been previously mentioned in this section at all. Is it supposed to say "any of the ServletContextListener events are fired" ????

Page 80:
"The ServletContainerInitializer's onStartup method get's a Set of Classes
that either extend / implement the classes that the initializer expressed interest in or
if it is annotated with any of the classes specified via the @HandlesTypes
annotation."

Should this be: " ... onStartup method gets called with a Set of classes ..."? Or even better " ... onStartup method is called with a Set of classes ..."

IMHO section 8.2.4 does not flow very cleanly and could do with a rewrite.



 Comments   
Comment by janbartel [ 01/Mar/13 ]

The above comments apply to the just-released Public Final Draft.

Also, there is a typo on Page 80, "anotation" should be "annotation".

Jan

Comment by Shing Wai Chan [ 04/Mar/13 ]

Sending eod-pluggability.fm
Transmitting file data .
Committed revision 77.

I have fixed issues described above, except the following:
"The onStartup method of the ServletContainerInitializer will be invoked
when the application is coming up before any of the listener's events are fired."

Since ServletContextListener events are fired before any other servlet events, the above statement is correct. There is no need to change in the spec in this case.

Comment by janbartel [ 12/Mar/13 ]

According to your last comment, then the current English of that sentence is not correct.

The sentence says:
"... before any of the listener's events are fired"

The apostrophe is the possessive form of a singular noun - ie it is talking about 1 specific listener.

Instead, the sentence should refer to all servlet listeners, eg:

"... before any of the servlet listener events are fired"

Jan





[SERVLET_SPEC-8] Clarification on run-as for servlet method Created: 31/Aug/11  Updated: 10/Jan/12  Resolved: 10/Jan/12

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I have discussed with Ronald Monzillo about the run-as in servlet.
I try to summarize his comments as follows:

a) In "A.8 Changes Since Servlet 2.3", it states

Clarification: "run-as" identity must apply to all calls from a servlet including init() and destroy() (12.7)

There is no such clarification in the section 12.7 or in the security chapter, so the clarification may have been lost, but the appendix clearly notes the intent, and thus he thinks it is required that a specified run-as identity be in effect during init() and destroy().

b) Note that section 15.3.1 Propagation of Security Identity in EJB Calls, requires that propagation occur whenever an ejb is called by a servlet (without consideration of the Servlet method form which the ejb call is made). That may be going too far, but it would at least support that run-as should be honored within init(); where it is has become common practice to invoke ejbs, and where (unlike the case of calls to ejbs from servlet context listeners), there is a mapping to a specific servlet on which to look for a run-as specification.

I think we should only propagate the security identity when Servlet#init, Servlet#destroy and Servlet#service are called.
(So, there will be no security identity propagation for Servlet#getServletConfig, Servlet#getServletInfo.)



 Comments   
Comment by Shing Wai Chan [ 05/Jan/12 ]

I have further discussion with Ron about this.
We would like clarify the spec from:
"When it is specified, the container must propagate the security identity for any call from a servlet to the EJB layer in terms of the security role name defined in the run-as element. "

to

"When a run-as role is specified for a Servlet, the Servlet container must propagate a principal mapped to the role as the security identity in any call from the Servlet
to an EJB, including calls originating from the Servlet's Servlet#init and Servlet#destroy methods."

In other words, run-as apply to all Servlet's methods when it is invoked by the container.

Comment by Shing Wai Chan [ 10/Jan/12 ]

Sending javaEE.fm
Transmitting file data .
Committed revision 4.





[SERVLET_SPEC-6] Undefined behaviour for AsyncContext#getRequest() and getResponse() after complete()/dispatch() Created: 25/Aug/11  Updated: 11/Feb/13  Resolved: 11/Feb/13

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: markt_asf Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The specification is unclear on what should happen here. Clearly, it isn't going to work but how it fails and when it fails is undefined.

My preference is for declaring that those methods throw IllegalStateException in those circumstances.



 Comments   
Comment by gregwilkins [ 13/Sep/11 ]

I believe the request/response pair should be valid and not recycled until the lifecycle has completed - either with a call to onError or onComplete.

So During those calls, getRequest and getResponse should still return the appropriate object. The use case for this might be to retrieve an attribute from the request or to look at isCommitted or getStatus methods of the request to see what the response was going to be if it had not errored.

Comment by markt_asf [ 18/Sep/11 ]

I'd be fine with that approach. The question remains, what happens after the lifecycle has completed. My preference is still an ISE in that case.

Comment by Shing Wai Chan [ 07/Jan/12 ]

According to javadoc of AsyncContext, when there is async timeout, the
following may be invoked:
a. invoke AsyncListener#onTimeout
b. AsyncContext#complete, AsyncListener#onComplete
c. AsyncContext#dispatch

One should throw IllegalStateException for AsyncContext#getRequest() / getResponse()
if AsyncContext#complete or AsyncContext#dispatch are called.
This will solve the following timeout scenario, too.

Comment by Shing Wai Chan [ 10/Jan/12 ]

Sending src/main/java/javax/servlet/AsyncContext.java
Transmitting file data .
Committed revision 51990.

Sending servletobjects.fm
Sending status.fm
Transmitting file data ..
Committed revision 5.

Comment by gregwilkins [ 30/Jan/12 ]

Because the servlet specification allows (even encourages) object reuse/recycling, it is impossible to require a ISE to be thrown after the lifecycle completes. By definition of recycle, the object has been recycled and is now carrying the state of another request in another lifecycle, and it may well be in a state where such a call is applicable.

All we can say is that after a call to onComplete has returned, then the results of all calls to the AsyncContext API via an existing reference are undefined.

Now given current garbage collectors, it may no longer be good idea not to encourage such object reuse - but many containers already do so, thus it would be a big break to change that.

Comment by Shing Wai Chan [ 30/Jan/12 ]

Need further investigation on request issuee.

Comment by markt_asf [ 30/Jan/12 ]

It should be possible to use a thin, "throw away" wrapper around the AsyncContext that tracked state and threw the Exception leaving the underlying AsyncContext implementation to be safely recycled. Whether this complexity is worth the benefit of changing behaviour from "undertermined" to "throws ISE" is TBD.

My own view is that the complexity is worth the benefit. These sorts of re-use bugs can be really tricky to track down and this change would help considerably.

Comment by gregwilkins [ 31/Jan/12 ]

markt_asf,

I agree that the benefits of reusing objects are probably at best marginal now. A think wrapper may help, but it is probably just as much work to implement as removing the recycling of objects.

For Jetty we definitely plan to evaluate if our current recycling of request,response,asyncContext are still worth it - but it is not a change that we can make lightly.

Also, the state of the art with garbage collection may swing the other way someday, and recycling objects may come back in vogue. Thus I think because the spec originally allowed/encouraged recycling, then it should not change to prohibit recycling - even if containers move away from doing so.

Perhaps we can go for some verbage along the the lines of - all method calls on the AsyncContext are undefined after a call to onComplete. However implementations are encouraged to throw ISE if at all possible.

Comment by Shing Wai Chan [ 02/Feb/12 ]

After timeout or commit, we would like to clarify the use of those previously acquired request or response objects are undefined.
The question is AysncContext.getRequest()/getResponse().
I prefer to have a deterministic behavior here.
As mentioned by Mark, this is feasible in the implementation, I would prefer to throw ISE in this case.

Comment by Rajiv Mordani [ 02/Nov/12 ]

@Greg - I generally don't like to keep things undefined in the spec. I think we should say that an ISE is thrown. It may introduce some complexity for implementations but there are a handful of these . I agree with Mark that these the re-use bugs can be really tricky and hence from the developers point of view it will be very clear to define in the spec that we throw an ISE and require all containers to implement it that way rather than "encourage" container vendors to throw the ISE.

Comment by rstoyanchev [ 05/Nov/12 ]

After timeout or commit, we would like to clarify the use of those previously acquired request or response objects are undefined.

As discussed above, this should not be done after a timeout but only after the lifecycle has completed - i.e. with a call to onError or onComplete. The subject of this issue should be corrected to reflect that as well.

Comment by gregwilkins [ 12/Nov/12 ]

@Rajiv It think we need to be consistent in the specification. If we say that AsyncContext objects throw ISE if used after the request lifecycle is complete, then I think we also need to do the same for the request and response instances themselves. I think it is too confusing to have some objects be reusable and others not.

Besides if AsyncContext.getRequest() throws an ISE, but Request itself is not usable after the completion of the request life cycle, then we have a race condition as an async thread might call getRequest() a nano second before the end of the request life cycle and then perform illegal operations on the request object it got in return.

So either we have to explicitly prohibit all recycling of objects and say that request/response/contexts are all invalid after the completion; OR we continue as we are saying that it is the applications responsibility to not call methods on any of these objects after the lifecycle has completed.

I do not think a half way house of some objects being recyclable while other are not is viable nor easy to understand.

If this was a green field spec, I think that requiring fresh objects on every cycle would be best. But as we have lots of existing code, then I now favour the status quo and that we continue to allow recycling of these objects.

Comment by markt_asf [ 12/Nov/12 ]

Bugs triggered by retaining references to the Request/Response objects are usually more obvious than those involving with AsycnContext. The multi-threaded nature of async adds complexity that does make it easier to get things wrong - hence my focus on AsycnContext.

I'm not against expanding this change to encompass Request/Response and Greg's consistency argument is a valid one but I would also be happy with just changing AsyncContext. I don't think the status quo is a reasonable option.

Comment by markt_asf [ 12/Nov/12 ]

Update title

Comment by Rajiv Mordani [ 12/Dec/12 ]

I'd like to close out on this issue one way or another. Let me start a thread on the EG to make sure that everyone is in fact tracking the issue on issue tracker and see what their opinions are.

Comment by Shing Wai Chan [ 11/Feb/13 ]

Per discussion in expert group discussion, 12/11/12, 1/9/13, 2/4/13, ISE will be thrown in this case.





[SERVLET_SPEC-143] HttpServlet.service(ServletRequest,ServletResponse) missing throws text Created: 28/Sep/15  Updated: 20/Jan/17  Resolved: 20/Jan/17

Status: Resolved
Project: servlet-spec
Component/s: API
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 10 minutes
Original Estimate: Not Specified


 Description   

HttpServlet.service(ServletRequest,ServletResponse) has this @throws clause:

@exception ServletException if the HTTP request cannot be handled

But the RI also throws ServletException if either incoming parameter is not an instanceof their Http counterpart.

I think this should be explicitly stated.



 Comments   
Comment by Ed Burns [ 28/Sep/15 ]

M src/main/java/javax/servlet/http/HttpServlet.java

+ * @throws ServletException if the HTTP request cannot
+ * be handled or if either parameter is not
+ * an instance of its respective

{@link HttpServletRequest}

+ * or

{@link HttpServletResponse}

counterparts.

  • @see javax.servlet.Servlet#service
    */
  • Added text to the @throws ServletException of
    HttpServlet.service(HttpServletRequest, HttpServletResponse).
    Sending src/main/java/javax/servlet/http/HttpServlet.java
    Transmitting file data .
    Committed revision 64145.




[SERVLET_SPEC-118] Replace and deprecate ServletRequest.getParameter for HttpServletRequest Created: 04/Dec/14  Updated: 20/Jan/17  Resolved: 20/Jan/17

Status: Resolved
Project: servlet-spec
Component/s: Filter/Servlet
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: jgigov Assignee: Unassigned
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

As it stands now, getParameter is only useful for String parameters, making it useless for file uploads or just any multipart/* POST requests. I propose the adding following methods to the HttpServletRequest interface.

HttpServletRequest.java
public String getString(String parameterName);
public String[] getStrings(String parameterName);
public Integer getInt(String parameterName) ;
public Integer[] getInts(String parameterName);
public Long getLong(String parameterName);
public Long[] getLongs(String parameterName);
public Float getDouble(String parameterName);
public Float[] getDoubles(String parameterName);
public Double getDouble(String parameterName);
public Double[] getDoubles(String parameterName);
public Number getNumber(String parameterName);
public Number[] getNumbers(String parameterName);
public File getFile(String parameterName);
public File[] getFiles(String parameterName);
public Object getObject(String parameterName);
public Object[] getObjects(String parameterName);
public Map<String,Object[]> getParameterObjects();

By their very names, they are rather self-explanatory. Most of them are essentially parsers to convert from String to the desired object. They should throw NumberFormatException if it occurs, but otherwise behave same as getParameter and getParameterValues for consistency.

The part that requires most discussion, however is how will we get the original file name of uploaded files. There are several reasonable ways it can be done:

1. Have methods in the HttpServletRequest that return only the file name(s).
2. Define a new public (possibly static) class that is returned instead of File, that will contain original file name and the File object, or simply extends File and adds a method for the original name.
3. Define a naming convention to be used, from which the name can always be extracted (the least reasonable, in my opinion, but doable).
4. Define a private/protected class that extends File, but overrides toString() to return the original file name (the solution I used for our company project).

possibility1
public String getFileName(String parameterName);
public String[] getFileNames(String parameterName);

Additionally it might be nicer to have the possibility to return default values and simply have the ones without a defualt specifier overload to calling them with null as the default value.

HttpServletRequest.java
public String getString(String parameterName, String defaultReturn);
public Integer getInt(String parameterName, Integer defaultReturn) ;
public Long getLong(String parameterName, Long defaultReturn);
public Float getDouble(String parameterName, Float defaultReturn);
public Double getDouble(String parameterName, Double defaultReturn);
public Number getNumber(String parameterName, Number defaultReturn);
public Object getObject(String parameterName, Object defaultReturn);

It should also be clearly defined in the JavaDocs how a zero-length parameter sent by the user is treated. Whether it is returned as a zero-length String or null. As the JavaDocs for Java EE 7 stand right now, that is ambiguous and open to interpretation.

Implementing these changes will allow for standard parsers to process RFC 2388 multipart/form-data, the upcoming JSON form and possibly other standards (as there probably are).



 Comments   
Comment by stuartdouglas [ 07/Apr/16 ]

-1 to this, we already support multipart requests via the Part interface.

The numeric return values are IMHO also unessesary, the same thing can be accomplished by a one line call to a parse method for the relevant numeric type. I see no reason to clutter up our interfaces to save what basically amounts to a single method call.

Comment by markt_asf [ 07/Apr/16 ]

Agreed, I see no need for this API clutter.





[SERVLET_SPEC-165] Refresh delivery plan for eventual release to Servlet EG Created: 17/Jan/17  Updated: 23/Jan/17  Resolved: 23/Jan/17

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: MS 2 Sprint 1

 Comments   
Comment by Ed Burns [ 23/Jan/17 ]

JCP milestones approved by Shing-wai.





[SERVLET_SPEC-12] Clarify the path prefix mapping in Section 12.1 Created: 21/Sep/11  Updated: 23/Jan/17  Resolved: 23/Jan/17

Status: Resolved
Project: servlet-spec
Component/s: Misc
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Santiago Pericas-Geertsen Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: extension, future_release, mapping, matching, path, prefix, servlet

 Description   

Section 12.1 states that prefix mapping is done by stepping down the path tree on directory at a time. However, given a path "/foo/", it does not mention how to deal with the trailing "/". This is significant given that "/foo" (no trailing slash) matches "/foo/" as shown later in that chapter (which is a bit confusing if "/" is naively converted in to a regexp).

The use of "/" with the intended semantics is somewhat misleading since it can match any number of paths, including zero. Ant uses "*" to match arbitrary number of directories (including none). IMO, a better syntax for servlet mapping would be:

/.../* => /.../** (path prefix)
(ii) .ext => //.ext (extension mapping)

For example,

(1) match(/a/**, /a/b/c/d) = (/a, /b/c/d)
(2) match(/a/**, /a) = (/a, null) (since ** matches 0 directories)

and

(3) match(/*/.ext, /a/b/c.ext) = (/a/b/c.ext, null)

Changing the syntax would obviously be backward incompatible, but perhaps an alternate syntax could be consider in future revisions of the spec.



 Comments   
Comment by gregwilkins [ 23/Sep/11 ]

While I agree that the path mapping is a bit strange, I'm loath to change it now.... unless there is significant support to do so.

If there is to be a change in the mapping, then another issue that needs to be fixed is the inability to form a pattern to match the ROOT of a webapp, since "/" is the default mapping. Also the fact that "/" has different semantics to "/*" is confusing as they both match the same requests (in the absence of any suffix matches).





[SERVLET_SPEC-75] Multipart part without filename must make part contents available as a string in parameters Created: 11/Jun/13  Updated: 23/Jan/17  Resolved: 23/Jan/17

Status: Resolved
Project: servlet-spec
Component/s: HTTP
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: janbartel Assignee: Unassigned
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Given that the MultiPartConfig allows for setting a maximum threshold after which part contents must be written to a file, it is odd that the spec also says that parts that don't explicitly include a filename must also make their contents available as a String in the params. The max threshold appears to be a good feature to avoid denial of service attacks via uncontrolled memory use, however having the requirement to put the content straight back into memory negates that. So a malicious client can simply not send a filename in the part content disposition and cause memory issues on the server side.

Would not a better solution be to make the name of the file to which the part was written available in the parameters? Only if the part was not written to a file would the part contents be available in the parameters.



 Comments   
Comment by kchung [ 11/Jun/13 ]

You are right in that the spec does not specify the behavior for getParameter and getParameterValues when a multipart content size exceeds the threshold.

It may be enough for the spec to say that getParameter are only guaranteed to return the content when the threshold is not reached, and leave the behavior undefined otherwise. In reality, we don't expect anybody to use this method to get BIG multipart files.

If we are to return the name of a file like you suggested, we'll need another way to tell us that a file name (instead of its content) is being returned. Don't think it's worth the trouble.

Comment by markt_asf [ 11/Jun/13 ]

The spec also doesn't state that containers should place limits on the size of POST requests. However, every container does to protect against a DoS. This is no different.

Tomcat addresses this issue by applying its standard POST limits to data that is processed via MultiPartConfig but ends up in the parameter map. Other containers will probably take a different approach but I think this falls firmly in the implmentation specific category.





[SERVLET_SPEC-139] Add int getStreamId() to HttpServletRequest and HttpServletResponse. Created: 16/Sep/15  Updated: 23/Jan/17  Resolved: 23/Jan/17

Status: Resolved
Project: servlet-spec
Component/s: HTTP
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Add new method

public int getStreamId()

to HttpServletRequest and HttpServletResponse.



 Comments   
Comment by gregwilkins [ 16/Sep/15 ]

Perhaps this could be abstracted a bit more - getTransportId? so for HTTP/1 it could give some identifier that represents the TCP/IP connection?

Note also that in HTTP2 streams can exist without requests (eg carrying websocket or just created empty as a priority marker).

Comment by Shing Wai Chan [ 18/Sep/15 ]

What is the use cases for this? Do application needs to know the streamId?

Comment by Ed Burns [ 18/Sep/15 ]

It's certainly less necessary now that SERVLET_SPEC-138 has been closed.

Comment by gregwilkins [ 20/Sep/15 ]

I do think it can be useful to expose some kind of connection/transport ID.
This is already available to some extend for https as the SSL session ID can be used to determine if two requests came from the same connection or not. Thus this could be generalized to a getConnectionId which would return something unique for the transport used.

I do know that a few webapps do care about this and have used container specific methods to determine this information, however I don't think they are common enough use-cases to insist something like this must be in the spec.

Comment by stuartdouglas [ 07/Apr/16 ]

I don't think getStreamId() is useful, it does not actually tell you anything without also some way of identifying the connection that the stream is associated with. getConnectionId() could be more useful, but I am worried about the potential for misuse if the server is behind a proxy.

I can see developers making assumptions about how getConnectionId() works based on their development machine, that no longer hold true once the app is in production due to the presence of a reverse proxy.

Comment by markt_asf [ 07/Apr/16 ]

Absent a valid use case, I'm fine with not supporting either method in the spec API.





[SERVLET_SPEC-132] WebSocket and Servlet mappings clarification Created: 07/May/15  Updated: 23/Jan/17  Resolved: 23/Jan/17

Status: Resolved
Project: servlet-spec
Component/s: Misc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: mmulholl Assignee: Unassigned
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Websocket endpoints declare mappings similar to a servlet mapping but the specification does not provide any guidance on how to handle these mapping when they exist in the same application. Should an endpoint mapping be considered as just another servlet mapping or something different based on the presence of an upgrade header?

For example, could a servlet and endpoint use the same mapping? The servlet is called in the absence of an upgrade header and the endpoint with the presence of an upgrade header? Or should this be a mapping clash?

For example, if an endpoint mapping uses a wildcard /home/* and a request is received for /home/index.html should the request be passed to the endpoint or the static file processor? Once again, could the destination be determined by the presence of an upgrade header?



 Comments   
Comment by Pavel Bucek [ 12/May/15 ]

Why do you think this should be filed against Servlet?

From my point of view, if WebSocket spec defines something without all required details, we should make the adjustment in WebSocket spec, not in Servlet; Servlet spec does not need to know about WebSocket and its mapping and WebSocket spec should do better job in terms of the description of Servlet integration in that regard.

Comment by mmulholl [ 12/May/15 ]

Well, we have section 12 in the spec which this question relates to. If we just implement what is in section 12 it means a websocket endpoint is just another servlet mapping, customers have to be aware of clashes between endpoint mappings and servlet mappings and extension processing, which is fine if that is the answer. However, if the servlet implementation should be sensitive to the upgrade header when mapping requests that would need an update to the servlet spec.

Comment by stuartdouglas [ 12/May/15 ]

The way we (Undertow) handle this is to install the websocket handler as a filter at the end of the filter chain. This gives user filters a chance to operate on the request before it is upgraded, and if there are no upgrade headers present then the request will be handled by any mapped servlet as normal.

Comment by Pavel Bucek [ 13/May/15 ]

@mmulholl: why would server need to recognise upgrade header? It is just HTTP request as others. Also I don't agree that single endpoint is another servlet mapping - @ServerEndpoint does not say anything about SERVLET mapping, it is just an alignment WITHIN WebSocket application, which has different rules and WebSocket spec deals with them (see JSR 356, chapter 3.1.1).

@stuartdouglas: we (Tyrus) do the same thing. And as you, we did not encounter any major issues with it (yet..), so it seem to be viable solution.

The issue might be more about how is the websocket application intergrated (mapped) into servlet mapping and that does not seem to be correctly defined. What is usually done is that the container registers single ServletFilter, which handles all upgrade requests (mapping "/*") and it is at the end of the filter chain. We might need to put something like this into WebSocket spec, but Servlet does not need to know about it.

Comment by stuartdouglas [ 07/Apr/16 ]

I think this can be closed, IMHO any clarification here belongs in the websocket spec.

Comment by markt_asf [ 07/Apr/16 ]

+1 to closing this.





[SERVLET_SPEC-167] Review unresolved issues Created: 23/Jan/17  Updated: 23/Jan/17  Resolved: 23/Jan/17

Status: Resolved
Project: servlet-spec
Component/s: Misc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 3 hours, 26 minutes
Original Estimate: Not Specified

Sprint: MS 2 Sprint 2

 Description   

Review unresolved issues as listed in this JIRA query

https://java.net/jira/issues/?jql=project%20%3D%20SERVLET_SPEC%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20component%20ASC%2C%20key%20ASC%2C%20priority%20DESC

Ask yourself some basic questions for each?

  • Has this been fixed already?
  • Can this be closed as "Works as Designed"?
  • Is this one well specified enough to just do the spec and impl work right now?
  • Has there been any work on this during the 4.0 cycle?
  • Are any of the Expert Group members particularly keen on seeing this one resolved?
  • If it has the FUTURE_RELEASE tag, should we attempt it in 4.0?


 Comments   
Comment by Ed Burns [ 23/Jan/17 ]

These two components have a disproportionately large number of hard issues: Security, IO.





[SERVLET_SPEC-104] inconsistent async-supported ordering for filters and servlets Created: 27/Aug/14  Updated: 24/Jan/17  Resolved: 24/Jan/17

Status: Resolved
Project: servlet-spec
Component/s: API
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gregwilkins Assignee: Ed Burns
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: MS 2 Sprint 2

 Description   

The schema for servlet and filters is a sequence rather than a group, so when validating, the order of the elements is important.

However, async-supported is inconsistent, as it is before init-params in filters, but after them in servlets.



 Comments   
Comment by Ed Burns [ 23/Jan/17 ]

Asked Java EE Architecture about permissibility of this change.

Comment by Ed Burns [ 24/Jan/17 ]

After consulting with EE arch and Shing-wai, marking this WONTFIX as the breakage in backward compatibility is not worth the improvement in correctness in this case.





[SERVLET_SPEC-153] Specify allowable characters for context-root Created: 25/Mar/16  Updated: 07/Feb/17  Resolved: 07/Feb/17

Status: Resolved
Project: servlet-spec
Component/s: Configuration
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVLET_SPEC-154 Consider requiring context-roots to b... Open

 Description   
>>>>> On Thu, 17 Mar 2016 19:10:56 +0000 (UTC), PB said:

PB> Dear EG Members,
PB> I'd like to get clarification in regards to the following. I am quoting
PB> from EE 5.0 (see link below), section 8.3.1, paragraph 3c. This
PB> language still exists in EE 7 and dates back to at least EE 1.3:

PB> The Deployer must... "Assign a context root for each web module
PB> included in the Java EE application. The context root is a relative
PB> name in the web namespace for the application. Each web module must be
PB> given a distinct and non-overlapping name for its context root."

PB> This scenario I have today:
PB> /context/something <-- context is /context
PB> /context/something/somethingelse <-- context is /context/something

PB> Please advise on these points:

PB> a) The specification puts no limitations on the context root character
PB> set (so it can include a slash). With that said, would you consider
PB> these "overlapping" contexts as the specification defines it? 

The specification should be explicit in which characters are allowed in the context-root.



 Comments   
Comment by Ed Burns [ 07/Feb/17 ]

Upon closer inspection of this issue, I see that there is no text in the Servlet spec PDF, the JavaDoc, or the Servlet defined XSDs that defines the context root. The only thing in the XSD is the application_7.xsd, which defines how one writes an application.xml for an EAR. In there, we have a context-root, like this:

  <module>
        <web>
            <web-uri>myweb.war</web-uri>
            <context-root>MyWeb</context-root>
        </web>
    </module>

That context-root is constrained to be a javaee:string, which is defined as

  <xsd:complexType name="string">
    <xsd:annotation>
      <xsd:documentation>

        This is a special string datatype that is defined by Java EE as
        a base type for defining collapsed strings. When schemas
        require trailing/leading space elimination as well as
        collapsing the existing whitespace, this base type may be
        used.
        
      </xsd:documentation>
    </xsd:annotation>
    <xsd:simpleContent>
      <xsd:extension base="xsd:token">
        <xsd:attribute name="id"
                       type="xsd:ID"/>
      </xsd:extension>
    </xsd:simpleContent>
  </xsd:complexType>

According to <http://www.datypic.com/sc/xsd/t-xsd_ID.html>, "The type xsd:ID is used for an attribute that uniquely identifies an element in an XML document. An xsd:ID value must be an NCName. This means that it must start with a letter or underscore, and can only contain letters, digits, underscores, hyphens, and periods."

Comment by Ed Burns [ 07/Feb/17 ]

This seems to be sufficiently constrained based on what is standardized.





[SERVLET_SPEC-89] Need clarification /enhancement to <distributable/> Created: 09/Jun/14  Updated: 09/Feb/17  Resolved: 24/Jan/17

Status: Resolved
Project: servlet-spec
Component/s: API
Affects Version/s: None
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: MS 2 Sprint 2

 Description   

Suppose we have a war with one web-fragment as follows:
a) In web.xml, there is no <distributable/>.
b) In web-fragment.xml, there is a <distributable/>.
What is the resulting merged web.xml?

In g.iii. of 8-80 of Servlet 3.1, we have

iii. If an element with a minimum occurrence of zero, and a maximum
occurrence of one, is present in a web fragment, and missing in the main
web.xml, the main web.xml inherits the setting from the web fragment. If
the element is present in both the main web.xml and the web fragment, the
configuration setting in the main web.xml takes precedence. For example, if
both the main web.xml and a web fragment declare the same servlet, and
the servlet declaration in the web fragment specifies a <load-onstartup>
element, whereas the one in the main web.xml does not, then
the <load-on-startup> element from the web fragment will be used in
the merged web.xml.

ix. The web.xml resulting from the merge is considered <distributable>
only if all its web fragments are marked as <distributable> as well.

And we have at most one <distributable/> according to descriptions in
schema:
The web-app element is the root of the deployment
descriptor for a web application. Note that the sub-elements
of this element can be in the arbitrary order. Because of
that, the multiplicity of the elements of distributable,
session-config, welcome-file-list, jsp-config, login-config,
and locale-encoding-mapping-list was changed from "?" to "*"
in this schema. However, the deployment descriptor instance
file must not contain multiple elements of session-config,
jsp-config, and login-config. When there are multiple elements of
welcome-file-list or locale-encoding-mapping-list, the container
must concatenate the element contents. The multiple occurence
of the element distributable is redundant and the container
treats that case exactly in the same way when there is only
one distributable.

So, the answer seems to be a <distributable/>.

In other words, if all the web fragment libraries are distributable.
Then so must the application be.

Since distributable element is an emptyType, it cannot be mark as not distributable.

I suggest to add an optional boolean attribute with default value true.
This allows user to specify explicitly whether the web app is distributable or not.



 Comments   
Comment by markt_asf [ 10/Jun/14 ]

It looks like the text for ix just needs some tweaks. The "as well." at the end suggests to me that it means the main web.xml and all the fragments need to be marked as distributable.

I suggest the following re-wording:

ix. The web.xml resulting from the merge is considered <distributable>
only if the main web.xml and all the web fragments are marked as <distributable>.

Comment by chemFelix [ 21/Oct/14 ]

This problem and the resulting implementation ( https://java.net/jira/browse/GLASSFISH-20917 ) are really blocking me. Why does it take so long to fix this? Of course, the impact of such change may be substantial, but it will still be if we wait for christmas. The fact that this particular bug appeared is acceptable, while the combination of the bug and the lack of any efforts to resolve it are not. Sorry for my harsh words.

Comment by Shing Wai Chan [ 23/Jan/17 ]

I agree with Mark on the comments on the "as well". I have updated the spec.

Sending eod-pluggability.fm
Sending status.fm
Transmitting file data ..done
Committing transaction...
Committed revision 125.





[SERVLET_SPEC-155] Clarification on getDefaultSessionTrackingModes and getEffectiveSessionTrackingModes Created: 31/Mar/16  Updated: 09/Feb/17  Resolved: 24/Jan/17

Status: Resolved
Project: servlet-spec
Component/s: Container
Affects Version/s: None
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: MS 2 Sprint 2

 Description   

In Servlet 3.1 javadoc of ServletContext#getDefaultSessionTrackingModes, we have
"Gets the session tracking modes that are supported by default for this ServletContext."

The description indicates that the above API returns a list of supported session tracking modes.

However, in javadoc of #getEffectiveSessionTrackingModes(), we have
"By default, the session tracking modes returned by getDefaultSessionTrackingModes are in effect."

This will be an issue when the server supports COOKIE, URL and SSL as SSL cannot be effective with COOKIE and URL at the same time. (See javadoc of #setSessionTrackingModes.)



 Comments   
Comment by Shing Wai Chan [ 31/Mar/16 ]

In this case, I proposed to remove the third line of description in #getEffectiveSessionTrackingModes(). That is, removing the following:
"By default, the session tracking modes returned by getDefaultSessionTrackingModes are in effect."

Comment by markt_asf [ 02/Apr/16 ]

OK, but if the web application does not explicitly request a tracking mode what should the effective tracking modes be? I suggest default less SSL unless SSL is the only one in which case use SSL.

Comment by Shing Wai Chan [ 23/Jan/17 ]

Sending src/main/java/javax/servlet/ServletContext.java
Transmitting file data .done
Committing transaction...
Committed revision 64427.





[SERVLET_SPEC-144] Clarification on metadata-complete Created: 02/Oct/15  Updated: 09/Feb/17  Resolved: 02/Oct/15

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

As we noticed that people seem to get confused as to the exact meaning of the xml attribute metadata-complete = "true" with regard to annotation scanning.

The intent here is not to not process all annotations, but rather to not process those annotations that are covered by the metadata of the deployment descriptors that specify metadata-complete.

While the above information is in the spec, we need to make it more explicit in the spec.



 Comments   
Comment by Shing Wai Chan [ 02/Oct/15 ]

Sending eod-pluggability.fm
Sending status.fm
Transmitting file data ..
Committed revision 113.





[SERVLET_SPEC-60] Provide HttpServletRequestWrapper that minimizes effort required to override core data Created: 20/Feb/13  Updated: 14/Feb/17  Resolved: 14/Feb/17

Status: Resolved
Project: servlet-spec
Component/s: Filter/Servlet
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

While the Servlet spec provides an HttpServletRequestWrapper that makes it easy to wrap an existing HttpServletRequest and override a specific method, there's still a significant amount of work needed to fully override all methods that are related to a singe "data item".

For instance, if it's needed to provide different headers for a wrapped request, it's not possible to simply override a single method that provides a collection of headers. Instead no less than 5 methods need to be overridden:

  • getHeaderNames
  • getHeader
  • getHeaders
  • getIntHeader
  • getDateHeader

Specifically, in the above example it's not exactly trivial to implement getDateHeader. It should theoretically not be needed to provide a custom implementation of this getDateHeader method since the Servlet implementation already has one, but there's no portable way to use that.

If it's needed to provide another URL even more methods have to be overridden (getContextPath, getPathInfo, etc).

It would be great if a wrapper class could be provided that identified a number of "core data" items, such as cookies, headers, locales, parameters, the request method, URL and query String, where for each of which the user could provide that "core data" item by overriding a single method.

All methods that provide derived data would call this single method in their container provided implementations. (this is loosely based on the concept of AbstractMap in Java SE, where a user only has to implement a minimal amount of functionality in order to have reasonable implementations for all methods of the complex Map interface)



 Comments   
Comment by arjan tijms [ 14/Feb/17 ]

Just wondering, why was this closed?

This is still a very much needed functionality and would be greatly appreciated if it would be provided. Time and again I'm seeing code implementing this manually. In JSF it's done for Cactus, the JSR 375 Security API implements it itself, etc etc.





[SERVLET_SPEC-158] Clarify the behaviour of the "**" role in security constraints Created: 11/Jul/16  Updated: 15/Feb/17  Resolved: 15/Feb/17

Status: Resolved
Project: servlet-spec
Component/s: Security
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: stuartdouglas Assignee: Shing Wai Chan
Resolution: Works as designed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: MS 3 Sprint 2

 Description   

Under the description of isUserInRole there is the following caveat when it talks about the "**" role:

If the role-name of the security-role to be tested is "**", and the application has NOT declared an application security-role with role-name "**", isUserInRole must only return true

However when discussing declarative constraints later on the spec says

The special role name “**” is a shorthand for any authenticated user independent of role.

No mention is made of special handling of the "**" role if the application has defined an application security role with the same name, which means that according to the letter of the spec the behavior of programmatic constrains and isUserInRole is inconsistent.

I think this should be clarified.



 Comments   
Comment by Shing Wai Chan [ 08/Feb/17 ]

Here is what the spec says:

The role name “*” should never be used as an argument in calling isUserInRole. Any call to isUserInRole with “*” must return false. If the role-name of the security-role to be tested is “**”, and the application has NOT declared an application security-role with role-name “**”, isUserInRole must only return true if the user has been authenticated; that is, only when getRemoteUser and getUserPrincipal would both return a non-null value. Otherwise, the container must check the user for membership in the application role.

If "**" is used as a security role name, then it is covered by the last sentence of the spec:

Otherwise, the container must check the user for membership in the application role.

20170208-edburns: escaped * for proper rendering.

Comment by Ed Burns [ 08/Feb/17 ]

But Stuart is asking what should be the behavior when the app explicitly and declaratively does define a security-role for "**". The spec says what should be the behavior of isUserInRole() when there is no such rule, but he is saying it does not say what to do when there is such a rule. At least, that is my read of Stuart's description.

Comment by Shing Wai Chan [ 08/Feb/17 ]

From jira description above, Sturat is asking the question is for "**", not "*".
The behavior for "*" is also specified in the spec:

The role name “*” should never be used as an argument in calling isUserInRole. Any call to isUserInRole with “*” must return false.

Comment by Ed Burns [ 14/Feb/17 ]

After clarification with Shing-wai, I now agree that this issue is sufficiently handled in the existing text of the specification.





[SERVLET_SPEC-70] Programmatic configuration API missing setting to replace <session-timeout> Created: 23/Mar/13  Updated: 01/Mar/17  Resolved: 09/Feb/17

Status: Resolved
Project: servlet-spec
Component/s: Configuration
Affects Version/s: None
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: Nick Williams Assignee: Shing Wai Chan
Resolution: Fixed Votes: 4
Labels: None
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour

Issue Links:
Related
is related to GLASSFISH-21668 Implement get/set SessionTimeout in S... Resolved
Tags: servlet-context, servlet_4_0, session-timeout, sessions
Sprint: MS 3 Sprint 1

 Description   

I just realized that there's no replacement for the deployment descriptor's <session-timeout> in ServletContext. Everything else in <session-config> (<tracking-mode> and all of the <cookie-config> options) can be set with ServletContext, but <session-timeout> cannot. I literally have a web.xml that is just the following:

<web-app ... version="3.0">
    <session-config>
        <session-timeout>30</session-timeout>
    </session-config>
</web-app>

Seems like kind of a big thing to be missing. Can we get setSessionTimeout and getSessionTimeout methods in ServletContext? It only makes sense, since ServletContext also has setSessionTrackingModes and getSessionTrackingModes methods.

I'd add that we really need a setDistributable and isDistributable, but I see those as lower priorities. Admittedly, there are plenty of things you can only do with web.xml, but session timeouts stick out because everything else from the <session-config> group can be configured programmatically.



 Comments   
Comment by Eugen Paraschiv [ 26/Jul/13 ]

This would definitely help get rig of the last remaining XML pieces.

Comment by kithouna [ 09/Aug/13 ]

We should definitely have this. I agree with OP that everything in web.xml should be possible to do programmatically, but of all those things this should really be done.

Comment by janbartel [ 24/Jan/17 ]

It has always been possible to change the timeout on an individual session using HttpSession.setMaxInactiveInterval(int sec). Please provide a description of the behaviour in the following cases:

1. are there any restrictions on when or from where this method can be called?
2. will the new method use time unit of minutes or seconds?
3. does the new method affect existing sessions or only sessions created after this method is called?
4. if it affects existing sessions, should it override a value previously established by a call to HttpSession.setMaxInactiveInterval (int sec)?
5. if it affects existing sessions this will be chaotic for distributed sessions: the node on which this call is made may not have any of the existing sessions local to it; if this call was made simultaneously on multiple nodes with different values the results would be non-deterministic.

Comment by Arend v. Reinersdorff [ 25/Jan/17 ]

@janbartel My take on this is the following:

  1. The new API should strictly be a replacement for the session-timeout element in web.xml. All extensions to this like changing the timeout of existing sessions should be separate issues.
  2. The new API should behave like the session-timeout element in web.xml as much as possible, eg accept the same values.
  3. The new API should behave like other methods on ServletContext which are used during initialization, eg throw IllegalStateException if they are called after initialization

Which would answer your questions as follows:

  1. The new method has the same restrictions as other methods on ServletContext which are used during initialization, eg setSessionTrackingModes() or addServet()
    • IllegalStateException - if this ServletContext has already been initialized
    • UnsupportedOperationException - if this ServletContext was passed to the ServletContextListener.contextInitialized(javax.servlet.ServletContextEvent) method of a ServletContextListener that was neither declared in web.xml or web-fragment.xml, nor annotated with WebListener
  2. The new method will use time unit minutes, same as the session-timeout in web.xml.
    • As with the session-timeout in web.xml a value of 0 or less means that sessions will never time out.
  3. The new method does not affect existing sessions, same as the session-timeout element in web.xml
    • This also avoids the problems 4. and 5. that you pointed out.
  4. Existing sessions are not affected, see 3.
  5. Existing sessions are not affected, see 3.

See also:

  • Servlet 3.1 specification page 182, chapter 14.4 Deployment Descriptor Diagram, 12. session-config

    The sub-element session-timeout defines the default session time out interval
    for all sessions created in this Web application. The specified time out must be
    expressed in a whole number of minutes. If the time out is 0 or less, the container
    ensures the default behavior of sessions is never to time out. If this element is not
    specified, the container must set its default time out period.

  • ServletContext.setSessionTrackingModes()

    Throws:
    IllegalStateException - if this ServletContext has already been initialized
    UnsupportedOperationException - if this ServletContext was passed to the ServletContextListener.contextInitialized(javax.servlet.ServletContextEvent) method of a ServletContextListener that was neither declared in web.xml or web-fragment.xml, nor annotated with WebListener

Comment by Shing Wai Chan [ 06/Feb/17 ]

Per discussion with EG, we will only add get/set SessionTimeout in ServletContext.

Revisions:
----------
64446





[SERVLET_SPEC-16] Add the ability to set <jsp-file> though the ServletRegistration interface Created: 04/Oct/11  Updated: 01/Mar/17  Resolved: 09/Feb/17

Status: Resolved
Project: servlet-spec
Component/s: Configuration
Affects Version/s: None
Fix Version/s: 4.0

Type: Improvement Priority: Major
Reporter: markt_asf Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-21666 Implement programmatic jsp-file Resolved
Sprint: MS 3 Sprint 1

 Description   

Title says it all. This looks like an oversight in the original ServletRegistration API.



 Comments   
Comment by Rajiv Mordani [ 07/Feb/13 ]

Not everything defined in the web.xml can be done via ServletRegistration.

Comment by markt_asf [ 07/Feb/13 ]

Indeed, but is there a reason not to add jsp-file that I have missed?

Comment by Rajiv Mordani [ 07/Feb/13 ]

There was no specific discussion about jsp-file, however the main goal of the APIs for adding Servlet, Filters and Listeners was for pluggability of frameworks. Not sure how many frameworks will really need to the jsp-file for pluggability.

Comment by markt_asf [ 07/Feb/13 ]

Here is the Tomcat discussion that triggered this request:
http://tomcat.markmail.org/thread/pg65fgqhfra7czy5

Comment by Ed Burns [ 26/Jan/17 ]

Here is a proposal that implements this.

@WebListener()
public class NewServletListener  implements ServletContextListener {

    @Override
    public void contextInitialized(ServletContextEvent sce) {

        final ServletContext servletContext = sce.getServletContext();
        final ServletRegistration.Dynamic dynamic = servletContext.addServlet("newjsp",
                ServletContext.JSP_SERVLET_CLASS_REFERENCE);
        dynamic.setJspFile("/newjsp.jsp");
        dynamic.addMapping("/newjsp");

    }

}
Comment by Ed Burns [ 26/Jan/17 ]

The use of the constant JSP_SERVLET_CLASS_REFERENCE enables the implementation to take the necessary actions to ensure this is equivalent to the implementation private JspServlet.

Comment by Shing Wai Chan [ 27/Jan/17 ]

<jsp-file> is a deployment descriptor. If the API is to set <jsp-file>, do we need to introduce the constant JSP_SERVLET_CLASS_REFERENCE?

Comment by Ed Burns [ 27/Jan/17 ]

I chose adding the constant to minimize impact on the existing API for programmatic servlet registration, which is:

@WebListener()
public class NewServletListener  implements ServletContextListener {

    @Override
    public void contextInitialized(ServletContextEvent sce) {

        final ServletContext servletContext = sce.getServletContext();
        final ServletRegistration.Dynamic dynamic = servletContext.addServlet("newjsp",
                [String, Class or Servlet]);
        dynamic.addMapping("/newjsp");

    }

}

As far as I know, and I could be wrong about this, but the existing API does require the use of one of the addServlet() variants on ServletContext. Given that assumption, neither the Class nor the Servlet variants are appropriate for a Servlet that is a JSP page. That leaves String. We have a private constant that is used internally for such things, but that is implementation specific. So, I judged the easiest and most minimal impact would be achieved by introducing a new constant whose meaning is as I've documented in the patch.

Comment by markt_asf [ 27/Jan/17 ]

I originally thought of using null. Looking at the addSevlet() Javadoc that looks legal. However, a specific constant strikes me as a better idea than giving null a special meaning.

Comment by Shing Wai Chan [ 06/Feb/17 ]

Revisions:
----------
64485

Modified Paths:
---------------
trunk/api/javaee-api/javax.servlet/src/main/java/javax/servlet/ServletContext.java

Comment by Shing Wai Chan [ 10/Feb/17 ]

add ServletContext#addJspFile()





[SERVLET_SPEC-73] Provide a way to find out mapping type used for selecting Servlet Created: 22/May/13  Updated: 11/Mar/17  Resolved: 11/Mar/17

Status: Resolved
Project: servlet-spec
Component/s: Misc
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Ed Burns
Resolution: Fixed Votes: 5
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours, 56 minutes
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-21670 Implement SERVLET_SPEC-73 Resolved
Tags: ease-of-use, ease_of_development
Sprint: MS 4 Sprint 1

 Description   

Section 12.2 of the Servlet spec defines how a request can be mapped to a Servlet in several ways, namely path mapping, extension mapping, a default mapping and an exact mapping.

A Servlet however can't easily find out which of the several mapping variants was used by the container to invoke it.

Knowledge of the mapping that was used is needed for several situations. E.g. In some frameworks (among which JSF) a Servlet can be mapped in several ways and the framework needs to reverse engineering the mapping using several tricks in order to distill the core requested page. E.g. extract /foo from any of /faces/foo.xhtml, /foo.xhtml and /foo.jsf.

Another case is when using both a default and another mapping for the same Servlet, such that this Servlet can handle "virtual resources" in a special way. E.g. the FacesServlet from JSF could be mapped to both *.xhtml and /, where a Filter filtering exactly the FacesServlet could intercept a request like /foo.bar, modify the request dynamically and continue the filtering chain.

Although there are workarounds for most cases, they aren't always the most obvious way to do things.

I therefor would like to propose to add a method to e.g. HttpServletRequest that code can use to find out which mapping variant was used for the current request processing.



 Comments   
Comment by arjan tijms [ 02/Jun/13 ]

In addition to what was primarily requested in this issue, it might also be useful to have a method on e.g. ServletContext where a URL or URI can be given as input and the mapping (if any) that the Servlet Container would use is then returned.

Comment by Ed Burns [ 11/Sep/15 ]

See discussion at <https://java.net/projects/servlet-spec/lists/jsr369-experts/archive/2015-09/message/21>.

Comment by Ed Burns [ 02/Feb/17 ]

API work is on topic branch <https://svn.java.net/svn/glassfish~svn/branches/SERVLET_SPEC-73>.

Comment by janbartel [ 09/Feb/17 ]

Based on Arjan's examples in https://java.net/projects/servlet-spec/lists/jsr369-experts/archive/2015-09/message/21 and the javadoc comments, it is not clear exactly how the Mapping.getMatchValue() should be derived.

Can you please update spec section 12.2.2 Example Mapping Set of request urls to mappings to explicitly clarify how the getMatchValue() is derived.

Comment by Ed Burns [ 01/Mar/17 ]

Sending pom.xml
Sending src/main/java/javax/servlet/AsyncContext.java
Sending src/main/java/javax/servlet/RequestDispatcher.java
Sending src/main/java/javax/servlet/http/HttpServletRequest.java
Sending src/main/java/javax/servlet/http/HttpServletRequestWrapper.java
Adding src/main/java/javax/servlet/http/MappingMatch.java
Adding src/main/java/javax/servlet/http/ServletMapping.java
Transmitting file data .......done
Committing transaction...
Committed revision 64685.

Committed to trunk.

Comment by Ed Burns [ 01/Mar/17 ]

Yes Jan, will do.

Comment by Ed Burns [ 01/Mar/17 ]

Sending src/main/java/javax/servlet/http/HttpServletRequest.java
Sending src/main/java/javax/servlet/http/MappingMatch.java
Transmitting file data ..done
Committing transaction...
Committed revision 64686.





[SERVLET_SPEC-161] Allow request/response encoding to be set from deployment descriptor and API Created: 07/Sep/16  Updated: 15/Mar/17  Resolved: 15/Mar/17

Status: Resolved
Project: servlet-spec
Component/s: Configuration
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-21688 Implement SERVLET_SPEC-161 Resolved
is related to SERVLET_SPEC-92 The default charset of ISO-8859-1 has... Open
Sprint: MS 4 Sprint 1, MS 4 Sprint 2

 Description   

SD> Request/Response Encoding

SD> At the moment the spec explicitly states that these default to
SD> ISO-8859-1, which made sense at the time as this was the default
SD> character encoding for HTML4. HTML5 has changes this however and now
SD> defaults to UTF-8.

SD> To address this I think we need to allow the default to be controlled
SD> in web.xml via a <default-encoding> element. This element will only
SD> affect the request and response encoding, and will override any spec
SD> mandated default. Obviously if the encoding is explicitly specified
SD> the default will not be used.



 Comments   
Comment by Ed Burns [ 07/Sep/16 ]

GW> So they could just be <request-encoding> and <response-encoding>, with
GW> documentation that says that the encoding set by these is overridden by the
GW> programmatic methods: setCharacterEncoding, setContent-Type and/or
GW> setLocale.

Comment by Ed Burns [ 07/Sep/16 ]

Section 3.11 of the prose document must be updated. It currently says:

Request data encoding
Currently, many browsers do not send a char encoding qualifier with the Content- Type header, leaving open the determination of the character encoding for reading HTTP requests. The default encoding of a request the container uses to create the request reader and parse POST data must be “ISO-8859-1” if none has been specified by the client request. However, in order to indicate to the developer, in this case, the failure of the client to send a character encoding, the container returns null from the getCharacterEncoding method.
If the client hasn’t set character encoding and the request data is encoded with a different encoding than the default as described above, breakage can occur. To remedy this situation, a new method setCharacterEncoding(String enc) has been added to the ServletRequest interface. Developers can override the character encoding supplied by the container by calling this method. It must be called prior to parsing any post data or reading any input from the request. Calling this method once data has been read will not affect the encoding.

Comment by Shing Wai Chan [ 22/Feb/17 ]

The following proposal has been sent to EG.


Since the default encoding for HTML5 is UTF-8, it would be good to

  • provide a way to configure the request/response encoding in a web application.
  • have an ability to configure the servlet container in a container specify way.

I propose to have the following changes:

  • add <request-encoding> to web.xml schema
    A sample usage is as follows:
    <request-encoding>UTF-8</request-encoding>
  • add <response-encoding> to web.xml schema
  • update javadoc for ServletRequest#getCharacterEncoding() as follows:
    old:
    This method returns null if the request does not specify a character encoding
    new:
    This method returns null if no request character encoding has been
    specified. The following methods for specifying the
    request character encoding are consulted, in decreasing order of
    priority: perrequest, per web app (using deployment descriptor), and
    per container (using vendor specific configuration).
  • update javadoc for ServletResponse
    old:
    The charset for the MIME body response can be specified explicitly using the
    setCharacterEncoding(java.lang.String) and setContentType(java.lang.String) methods,
    or implicitly using the setLocale(java.util.Locale) method.
    Explicit specifications take precedence over implicit specifications.
    If no charset is specified, ISO-8859-1 will be used.
    new:
    The charset for the MIME body of the response can be specified
    using any of the following techniques: per request, per web-app (using
    deployment descriptor), and per container (using vendor specific configuration).
    If multiple of the preceding techniques have been employed, the priority is
    the order listed.
    For per request, the charset for the response can be specified explicitly using the
    setCharacterEncoding(java.lang.String) and setContentType(java.lang.String) methods,
    or implicitly using the setLocale(java.util.Locale) method.
    Explicit specifications take precedence over implicit specifications.
    If no charset is explicitly specified, ISO-8859-1 will be used.

#getCharacterEncoding() as follows:
old:
The character encoding may have been specified explicitly using
the setCharacterEncoding(java.lang.String) or setContentType(java.lang.String) methods,
or implicitly using the setLocale(java.util.Locale) method.
Explicit specifications take precedence over implicit specifications.
new:
The following methods for specifying the response character encoding are
consulted, in decreasing order of priority: per request, per web-app (using
deployment descriptor), and per container (using vendor specific configuration).
The first one of these methods that yields a result is returned.
Per-request, the charset for the response can be specified explicitly using the
setCharacterEncoding(java.lang.String) and setContentType(java.lang.String) methods,
or implicitly using the setLocale(java.util.Locale) method.
Explicit specifications take precedence over implicit specifications.

#setCharacterEncoding() as follows:
old:
If the character encoding has already been set by setContentType(java.lang.String) or
setLocale(java.util.Locale), this method overrides it.
new:
If the response character encoding has already been set by the
deployment descriptor, or using the setContentType() or setLocale()
methods, the value set in this method overrides any of those values.

  • update 3.11 of spec
    old:
    The default encoding of a request the container uses to create the request reader and
    parse POST data must be “ISO-8859-1” if none has been specified by the client request.
    However, in order to indicate to the developer, in this case, the failure of the client
    to send a character encoding, the container returns null from the getCharacterEncoding method.

If the client hasn’t set character encoding and the request data is encoded with a
different encoding than the default as described above, breakage can occur.
To remedy this situation, a new method setCharacterEncoding(String enc) has been added
to the ServletRequest interface. Developers can override the character encoding supplied by
the container by calling this method. It must be called prior to parsing any post data or
reading any input from the request. Calling this method once data has been read will not
affect the encoding.
new:
The default encoding of a request the container uses to create the request reader and
parse POST data must be “ISO-8859-1” if none has been specified by the client request,
deployment descriptor or per container using vendor specific configuration.
However, in order to indicate to the developer, in this case, the failure of the client
to send a character encoding, the container returns null from the getCharacterEncoding method.

If the client hasn’t set character encoding and the request data is encoded with a
different encoding than the default as described above, breakage can occur.
To remedy this situation, the <request-encoding> element is available in the web.xml and
the setCharacterEncoding(String enc) method is available on the ServletRequest interface.
Developers can override the character encoding supplied by
the container by adding the element or calling the method. It must be called prior to
parsing any post data or
reading any input from the request. Calling this method once data has been read will not
affect the encoding.

  • update 5.5 spec
    old:
    If the element does not exist or does not provide a mapping, setLocale uses a container dependent mapping.

new:
The <response-encoding> element can be used to explicitly set the
encoding for all responses.
<response-encoding>UTF-8</response-encoding>
If neither element exists or does not provide a mapping, setLocale uses a container dependent mapping.


Comment by Shing Wai Chan [ 28/Feb/17 ]

The getters and setters in ServletContext can be as followed:
public String getRequestCharacterEncoding();
public void setRequestCharacterEncoding(String encoding);

public String getResponseCharacterEncoding();
public void setResponseCharacterEncoding(String encoding);

For getters, we may like to throw UnsupportedOperation if this ServletContext was passed to the

{@link ServletContextListener#contextInitialized} method of a {@link ServletContextListener} that was neither declared in <code>web.xml</code> or <code>web-fragment.xml</code>, nor annotated with {@link javax.servlet.annotation.WebListener}

For setters, we may like to
a) throws IllegalStateException if this ServletContext has already been initialized
b) throws UnsupportedOperationException if this ServletContext was passed to the {@link ServletContextListener#contextInitialized}

method of a

{@link ServletContextListener}

that was neither declared in <code>web.xml</code> or <code>web-fragment.xml</code>, nor annotated with

{@link javax.servlet.annotation.WebListener}

This will align with other APIs in ServletContext.

Comment by Shing Wai Chan [ 28/Feb/17 ]

update schema
Sending src/web-app_4_0.xsds
Sending test/web-app-complete.xml
Sending test/web-app.xml
Transmitting file data ...done
Committing transaction...
Committed revision 64627.

Comment by Shing Wai Chan [ 03/Mar/17 ]

Sending src/main/java/javax/servlet/ServletRequest.java
Sending src/main/java/javax/servlet/ServletResponse.java
Transmitting file data ..done
Committing transaction...
Committed revision 64710.

Comment by Shing Wai Chan [ 03/Mar/17 ]

Sending deployment.fm
Sending requestobject.fm
Sending responseobject.fm
Sending servlet.book
Sending servletcontext.fm
Sending sessions.fm
Sending status.fm
Transmitting file data .......done
Committing transaction...
Committed revision 128.

Comment by Shing Wai Chan [ 14/Mar/17 ]

Rename request/response-encoding to request/response-character-encoding:

Sending javaee8/src/web-app_4_0.xsds
Sending javaee8/test/web-app-complete.xml
Sending javaee8/test/web-app.xml
Transmitting file data ...done
Committing transaction...
Committed revision 64791.

Comment by Shing Wai Chan [ 14/Mar/17 ]

Sending deployment.fm
Sending requestobject.fm
Sending responseobject.fm
Sending servlet.book
Sending status.fm
Transmitting file data .....done
Committing transaction...
Committed revision 131.

Comment by Shing Wai Chan [ 15/Mar/17 ]

Sending deployment.fm
Sending images/web-app.png
Transmitting file data ..done
Committing transaction...
Committed revision 132.

Comment by Shing Wai Chan [ 15/Mar/17 ]

r134 | swchan2 | 2017-03-14 21:34:55 -0700 (Tue, 14 Mar 2017) | 2 lines

update web-app diagram





[SERVLET_SPEC-171] Clarification on behaviors of returned Set Created: 21/Mar/17  Updated: 28/Mar/17  Resolved: 24/Mar/17

Status: Resolved
Project: servlet-spec
Component/s: Filter/Servlet
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: servlet_4_0
Sprint: MS 4 Sprint 2

 Description   

In Servlet API, the following API returns a Set:

PushBuilder: public Set<String> getHeaderNames();
(ii) ServletContext: public Set<String> getResourcePaths(String path);
(iii) ServletContext: public Set<SessionTrackingMode> getDefaultSessionTrackingModes();
(iv) ServletContext: public Set<SessionTrackingMode> getEffectiveSessionTrackingModes();

(v) Registration: public Set<String> setInitParameters(Map<String, String> initParameters);
(vi) ServletRegistration: public Set<String> addMapping(String... urlPatterns);
(vii) ServletRegistration.Dynamic: public Set<String> setServletSecurity(ServletSecurityElement constraint);

For (v)-(vii), the returned set is about conflicts.
For -(iv), the returned set is from getter.

The javadoc and spec does not mention the behavior of the returned Set.

For convenience, we will look at PushBuilder, above, in the following wordings.
There are two options:
a) Backed:
The returned set is backed by the PushBuilder, so changes in the
returned set are reflected in the PushBuilder, and vice-versa.
b) NonBacked:
The returned set is not backed by the PushBuilder, so changes in the
returned set are not reflected in the PushBuilder, and vice-versa.



 Comments   
Comment by Shing Wai Chan [ 24/Mar/17 ]

Sending src/main/java/javax/servlet/Registration.java
Sending src/main/java/javax/servlet/ServletContext.java
Sending src/main/java/javax/servlet/ServletRegistration.java
Sending src/main/java/javax/servlet/http/PushBuilder.java
Transmitting file data ....done
Committing transaction...
Committed revision 64875.

Comment by Shing Wai Chan [ 24/Mar/17 ]

Sending servlet.book
Sending status.fm
Transmitting file data ..done
Committing transaction...
Committed revision 139.





[SERVLET_SPEC-109] AsyncContext#complete will not take effect Created: 09/Oct/14  Updated: 29/Mar/17  Resolved: 29/Mar/17

Status: Resolved
Project: servlet-spec
Component/s: I/O
Affects Version/s: None
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: MS 5 Sprint 1

 Description   

In Servlet 3.1 spec, we have the following for AsyncContext#complete:
If this method is called before the container-initiated dispatch that called startAsync has returned to the container, then the call will not take effect until after the container-initiated dispatch has returned to the container. Invocation of the AsyncListener.onComplete(AsyncEvent) will also be delayed till after the
container-initiated dispatch has returned to the container.

Precisely, what does the "will not take effect" means?
Notice that there are similar paragraph for AsyncContext#dispatch.

What happens when we do the following within the Servlet#service:
asyncContext.complete() and then asyncContext.dispatch()?

We need to clarify the meaning of "will not take effect" in these two paragraphs.



 Comments   
Comment by Shing Wai Chan [ 24/Mar/17 ]

Sending servlet.book
Sending servletobjects.fm
Sending status.fm
Transmitting file data ...done
Committing transaction...
Committed revision 140.





[SERVLET_SPEC-172] Explicitly address corner cases in Part.write() Created: 23/Mar/17  Updated: 31/Mar/17  Resolved: 31/Mar/17

Status: Resolved
Project: servlet-spec
Component/s: API
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour, 23 minutes
Original Estimate: Not Specified

Tags: servlet_4_0
Sprint: MS 5 Sprint 1

 Description   

The spec for @MultipartConfiguration.location says:

Spec8.1.5> The location attribute of the
Spec8.1.5> javax.servlet.annotation.MultipartConfig and the <location>
Spec8.1.5> element of the <multipart-config> is interpreted as an
Spec8.1.5> absolute path and defaults to the value of the
Spec8.1.5> javax.servlet.context.tempdir. If a relative path is
Spec8.1.5> specified, it will be relative to the tempdir location. The
Spec8.1.5> test for absolute path vs relative path MUST be done via
Spec8.1.5> java.io.File.isAbsolute.

The javadoc for Part.write(String fileName) says:

Part.write> fileName - the name of the file to which the stream will be
Part.write> written. The file is created relative to the location as
Part.write> specified in the MultipartConfig

GW> It is not clear whether fileName should be interpreted as a Path or
GW> not

GW> what should be the result if it specifies an absolute location

GW> what should be the result if it contains special path elements such
GW> as "." or "..".

GW> security concerns about allowing the container to try to write to
GW> any old path)

GW> Should an absolute filename throw an IAE or should it just be interpreted
GW> relative to the



 Comments   
Comment by Ed Burns [ 31/Mar/17 ]

Sending status.fm
Transmitting file data .done
Committing transaction...
Committed revision 143.

Comment by Ed Burns [ 31/Mar/17 ]

[SERVLET_SPEC-172-Part.write] update javadoc to clarify interpretation of fileName argument.

M src/main/java/javax/servlet/http/Part.java

Sending src/main/java/javax/servlet/http/Part.java
Transmitting file data .
Committed revision 64894.





[SERVLET_SPEC-146] Add ability to specify URL encoding Created: 04/Oct/15  Updated: 12/Apr/17  Resolved: 12/Apr/17

Status: Resolved
Project: servlet-spec
Component/s: Configuration
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: braghest Assignee: Ed Burns
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: MS 5 Sprint 1

 Description   

Implementations use encodings for three different things:

  1. the response body
  2. the request body
  3. the request URL

The specification provides API methods to configure the first two but no way to configure the last one (encoding of the request URL). This makes it impossible to create a portable application that uses non-ASCII URLs (or GET forms) and forces users to rely proprietary sever configuration.

For additional information check out this thread:
https://java.net/projects/servlet-spec/lists/users/archive/2015-08/message/41

Optionally a fix can include one central place to configure all three encodings but this is not required.



 Comments   
Comment by gregwilkins [ 08/Feb/17 ]

Note that when discussing encoding in terms of URIs there can be multiple encodings involved:
+ the encoding used to transport the URI itself (mostly specified by HTTP RFC's but some flexibility in implementation exists)
+ the encoding used for any encoded characters in the URI
+ the encoding of a HTTP URI path may sometimes differ from the URI of the query string

Comment by Ed Burns [ 12/Apr/17 ]

SERVLET_SPEC-146 Request URI Encoding

M requestmappings.fm
M requestobject.fm
M status.fm
Sending requestmappings.fm
Sending requestobject.fm
Sending status.fm
Transmitting file data ...done
Committing transaction...
Committed revision 145.





[SERVLET_SPEC-135] Adding @Deprecated for those with @deprecated in javadoc Created: 17/Aug/15  Updated: 18/Aug/15  Resolved: 18/Aug/15

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 4.0-m01

Type: Bug Priority: Minor
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The following has @deprecated in javadoc. @Deprecated should be added in the codes.

ServletContext: #getServlet(String), #getServlets(), #getServletNames(), #log(Exception, String)

ServletRequestWrapper: #getRealPath

SingleThreadModel: class level

UnavailableException: constructors, #getServlet

HttpServletRequest: #isRequestSessionIdFromUrl()

HttpServletResponse: #encodeUrl(String), #encodeRedirectUrl(String), #setStatus(int, String)

HttpServletResponseWrapper: #encodeUrl(String), #encodeRedirectUrl(String), #setStatus(int, String)

HttpSession: #getSessionContext(), #getValue(), #getValueNames(), #putValue(), #removeValue()

HttpSessionContext: class level, #getSession(String), #getIds()

HttpUtils: class level



 Comments   
Comment by Shing Wai Chan [ 18/Aug/15 ]

Sending src/main/java/javax/servlet/ServletContext.java
Sending src/main/java/javax/servlet/ServletRequestWrapper.java
Sending src/main/java/javax/servlet/SingleThreadModel.java
Sending src/main/java/javax/servlet/UnavailableException.java
Sending src/main/java/javax/servlet/http/HttpServletRequest.java
Sending src/main/java/javax/servlet/http/HttpServletRequestWrapper.java
Sending src/main/java/javax/servlet/http/HttpServletResponse.java
Sending src/main/java/javax/servlet/http/HttpServletResponseWrapper.java
Sending src/main/java/javax/servlet/http/HttpSession.java
Sending src/main/java/javax/servlet/http/HttpSessionContext.java
Sending src/main/java/javax/servlet/http/HttpUtils.java
Transmitting file data ...........
Committed revision 64060.





[SERVLET_SPEC-127] Minor mistakes in the specification (Servlet 3.1 Final Release for Evaluation) Created: 21/Feb/15  Updated: 05/Jan/16  Resolved: 14/Aug/15

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 4.0-m01

Type: Bug Priority: Minor
Reporter: Anthony Vanelverdinghe Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

section 2.3.3.1: "or methods such as doGet or doPost which are dispatched to the service method of the HttpServlet abstract class". This is exactly the other way around: the service method dispatches requests to the doXXX methods. From the javadoc http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServlet.html: "There's almost no reason to override the service method. service handles standard HTTP requests by dispatching them to the handler methods for each HTTP request type (the doXXX methods listed above)."

section 3.7: "The container will subsequently invoke the onDataAvailable method if and only if isReady method on ServletInputStream, described below, returns false." should be "[...] returns true."

section 5.3: "The container will subsequently invoke the onWritePossible method if and only if isReady method on ServletOutputStream, described below, returns false." should be "[...] returns true."

section 5.7: "[...] then the request object remains valid until complete method on AsyncContext is called." should be "[...] then the response object [...]"

section 8.1.5: "type mime/multipart" should be "multipart/form-data"

section 11.3.3: "HttpSessionListener.destory" should be "HttpSessionListener.destroy"

chapter 13, introduction: "[...] setServletSecurity method of the ServletRegistration interface." should be "[...] setServletSecurity method of the ServletRegistration.Dynamic interface."

javadoc of ServletContainerInitializer http://docs.oracle.com/javaee/7/api/javax/servlet/ServletContainerInitializer.html: "annontation" should be "annotation"

javadoc of ServletSecurityElement http://docs.oracle.com/javaee/7/api/javax/servlet/ServletSecurityElement.html: "represntation" should be "representation"



 Comments   
Comment by Shing Wai Chan [ 21/Feb/15 ]

javadoc fix
Sending src/main/java/javax/servlet/ServletContainerInitializer.java
Sending src/main/java/javax/servlet/ServletSecurityElement.java
Transmitting file data ..
Committed revision 63779.

Comment by Shing Wai Chan [ 14/Aug/15 ]

Sending eod-pluggability.fm
Sending events.fm
Sending requestobject.fm
Sending responseobject.fm
Sending security.fm
Sending servlet.book
Sending servletobjects.fm
Transmitting file data .......
Committed revision 108.

Comment by Shing Wai Chan [ 05/Jan/16 ]

additional fixes

Sending requestobject.fm
Sending responseobject.fm
Transmitting file data ..
Committed revision 122.

Sending src/main/java/javax/servlet/ReadListener.java
Sending src/main/java/javax/servlet/WriteListener.java
Transmitting file data ..
Committed revision 64232.





[SERVLET_SPEC-46] "Differed" should be "deferred" in spec text on async servlet lifecycle Created: 07/Sep/12  Updated: 14/Sep/12  Resolved: 14/Sep/12

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: janbartel Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

EDR text, section 2.3.3.3 pg 11:

"Dispatching from a synchronous servlet to an asynchronous servlet would be illegal.
However the decision of throwing an IllegalStateException is differed to the
point when the application calls startAsync. This would allow a servlet to either
function as a synchronous or an asynchronous servlet."

I think "differed" should be "deferred".



 Comments   
Comment by Shing Wai Chan [ 14/Sep/12 ]

Sending servletobjects.fm
Transmitting file data .
Committed revision 43.





[SERVLET_SPEC-38] Listeners were not invoked in a random order prior to Servlet 3.0 spec Created: 01/Apr/12  Updated: 30/Jul/12  Resolved: 30/Jul/12

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Christian Ludt Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Section 1.6.1 Listener ordering, a subsection of 1.6 Compatibility with Java Servlet Specification Version 2.5 states

Prior to this release of the specification, listeners were invoked in a random order. [...]

However, the Servlet Specification Version 2.5 already specified on page 78 in SRV.10.3.2 Deployment Declarations, SRV.10.3.3 Listener Registration and SRV.10.3.4 Notifications At Shutdown that the order is taken from the deployment descriptor:

SRV.10.3.2 Deployment Declarations
[...] [Listener classes] are listed by class name in the order in which they are to be invoked.

SRV.10.3.3 Listener Registration
The Web container registers the listener instances according to [...]
the order in which they appear in the deployment descriptor. During Web
application execution, listeners are invoked in the order of their registration.

SRV.10.3.4 Notifications At Shutdown
On application shutdown, listeners are notified in reverse order to their declarations
with notifications to session listeners preceeding notifications to context listeners.
Session listeners must be notified of session invalidations prior to context listeners
being notified of application shutdown.



 Comments   
Comment by Shing Wai Chan [ 30/Jul/12 ]

1. remove 1.6.1
2. Clarification in 8.2.3 (p.77) and 11.3.3

Sending eod-pluggability.fm
Sending events.fm
Sending overview.fm
Sending servletobjects.fm
Sending status.fm
Transmitting file data .....
Committed revision 39.





[SERVLET_SPEC-149] Eliminate talk of "default" context Created: 19/Nov/15  Updated: 20/Jan/17  Resolved: 20/Jan/17

Status: Resolved
Project: servlet-spec
Component/s: API
Affects Version/s: 4.0
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: pbenedict Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVLET_SPEC-150 Eliminate talk of "default" context Resolved

 Description   

With 4.0, web.xml is introducing a <default-context-path> element (SERVLET_SPEC-137). To prevent confusion, the Javadoc for ServletContext#getContextPath should stop mentioning the "default" context as a synonym for the "root" context. The latter should only be mentioned.



 Comments   
Comment by Ed Burns [ 20/Jan/17 ]

Committed revision 64421.





[SERVLET_SPEC-150] Eliminate talk of "default" context Created: 19/Nov/15  Updated: 20/Jan/17  Resolved: 20/Jan/17

Status: Resolved
Project: servlet-spec
Component/s: API
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: pbenedict Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVLET_SPEC-149 Eliminate talk of "default" context Resolved

 Description   

With 4.0, web.xml is introducing a <default-context-path> element (SERVLET_SPEC-137). To prevent confusion, the Javadoc for ServletContext#getContextPath should stop mentioning the "default" context as a synonym for the "root" context. The latter should only be mentioned.



 Comments   
Comment by pbenedict [ 19/Nov/15 ]

Please delete this ticket. My apologies. Wrong spec project.

Comment by Lukas Jungmann [ 20/Nov/15 ]

moved to the right project





[SERVLET_SPEC-115] Missing DTD in jar file Created: 04/Nov/14  Updated: 26/Jan/17  Resolved: 23/Jan/17

Status: Resolved
Project: servlet-spec
Component/s: API
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: paulmillar Assignee: Ed Burns
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: MS 2 Sprint 2

 Description   

Previous versions of servlet-spec jar included several XML dtd documents as part of their contents:

paul@sparkplug:~$ jar tf ~/.m2/repository/javax/servlet/servlet-api/2.5/servlet-api-2.5.jar |grep dtd
javax/servlet/resources/XMLSchema.dtd
javax/servlet/resources/datatypes.dtd
javax/servlet/resources/web-app_2_2.dtd
javax/servlet/resources/web-app_2_3.dtd
paul@sparkplug:~$

With later versions of servlet-api, these dtd files are missing:

paul@sparkplug:~$ jar tf ~/.m2/repository/javax/servlet/javax.servlet-api/3.1.0/javax.servlet-api-3.1.0.jar|grep dtd
paul@sparkplug:~$

When included correctly, these files allow validating parsers to obtain the necessary DTD information from the jar file directly, without downloading them. This reduces pressure on the DTD host (java.sun.com), improves software performance and removes the necessity to have Internet access.

While the application can include the DTD files itself to achieve the same benefit, placing them within the servlet-spec jar file (as before) seems a reasonable trade-off.



 Comments   
Comment by Ed Burns [ 23/Jan/17 ]

After talking with Shing-wai, I learned that we intentionally stopped including the DTDs and XSDs in the javax.servlet:javax.servlet-api JAR, because they are better maintained outside of that jar. In the case of GlassFish, they end up in the dtds and schemas directories, respectively.

Comment by paulmillar [ 24/Jan/17 ]

Hi Ed,

Thanks for the update.

Sorry, I don't follow the logic in moving the DTD and XSD from the servlet JAR file into the application/framework (i.e., GlassFish, here). The web.xml file (for example) is part of the spec., so it's a reasonable expectation that implementations may validate XML files, so will need access to the DTD. As the servlet-api jar file is maintained, any changes to the DTD/XSD should be achievable.

That aside, the bigger issue is that I couldn't find the changelog entry that documents the removal of these files.

Could you point me at the log entry that describes the file's removal?

Cheers,

Paul.

Comment by paulmillar [ 24/Jan/17 ]

Added an issue about the lack of changelog entry:

https://java.net/jira/browse/SERVLET_SPEC-168

Cheers,

Paul.

Comment by markt_asf [ 24/Jan/17 ]

For background, Tomcat provides its own implementation of the spec JARs and they contain all the necessary DTDs and XSDs required for validation.

Comment by janbartel [ 25/Jan/17 ]

Jetty too provides its own schema files, but I think it would be preferable if they were available from a jar provided by the official spec.

Comment by Ed Burns [ 25/Jan/17 ]

I agree it would be preferable, but Shing-wai and I prefer to be consistent with other Java EE specs, the majority of which do not include DTDs or Schemas in their jar artifacts. Also, please note that the production and GAV of our "official" spec jar, javax.servlet:javax.servlet-api:4.0, is not covered by the JCP spec proper, though these are covered by this page maintained by Java EE Architect Bill Shannon:

https://glassfish.java.net/wiki-archive/Maven%20Versioning%20Rules.html

Comment by paulmillar [ 26/Jan/17 ]

@janbartel you said "Jetty too provides its own schema files"

Do you mean that Jetty provides jetty-specific DTDs, or that Jetty provides the servlet DTD files?

The former I can confirm: Jetty jar files contain DTD files for validating its XML-based configuration; however, I do not see any containing the servlet DTD, nor do those servlet DTD files exist in their source-code.

That Jetty currently does not provide servlet DTD files (e.g., web-app_2_3.dtd) was the reason for opening this ticket. The result is that applications (that using Jetty framework) must include the DTD themselves. This I did (when opening this ticket) intending this to be a temporary work-around.

Naturally, I can open a support ticket against Jetty saying they should include the servlet DTD files within their distribution, as @EdBurns mentioned GlassFish currently does. It would help me in writing this ticket if the decision not to include DTD files was documented somewhere; I imagine a changelog entry would be the natural place to record such a decision (see https://java.net/jira/browse/SERVLET_SPEC-168 ).

However, I guess this ticket also describes the decision, so that could be used, too.

Cheers,

Paul.

Comment by paulmillar [ 26/Jan/17 ]

For reference, here's the ticket I opened against Jetty, requesting they include DTD files in their distribution.

https://github.com/eclipse/jetty.project/issues/1287





[SERVLET_SPEC-168] Removed DTD file not documented Created: 24/Jan/17  Updated: 26/Jan/17  Resolved: 26/Jan/17

Status: Resolved
Project: servlet-spec
Component/s: API
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: paulmillar Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: MS 2 Sprint 2

 Description   

In a related issue:

https://java.net/jira/browse/SERVLET_SPEC-115

I reported that DTD files are missing from the API JAR file. This issue was closed with "Works as designed".

However, I was unable to find a mention of this change (removing DTD files from the JAR file) in the changelog.

Could you point me at the log entry that describes the file's removal, or update the changelog to include this change?

Cheers,

Paul.



 Comments   
Comment by Ed Burns [ 26/Jan/17 ]

ejburns-mac:servlet-spec-1HEAD ejburns$ svn commit -m "SERVLET_SPEC-168 mention no DTD policy in changelog" status.fm
Sending status.fm
Transmitting file data .done
Committing transaction...
Committed revision 126.





[SERVLET_SPEC-137] Allow context root Created: 20/Aug/15  Updated: 01/Mar/17  Resolved: 15/Sep/15

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 4.0-m01

Type: Improvement Priority: Minor
Reporter: nboyce Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-21673 Implement default-context-path Resolved

 Description   

Set context root in web-inf/web.xml

Products would use the module name (for which we defined defaulting rules) as the context root unless it was overridden.



 Comments   
Comment by Ed Burns [ 21/Aug/15 ]

Would this require a change to the web_app.xsd? Reminder, those are maintained in a separate repo at <https://svn.java.net/svn/glassfish~svn/trunk/schemas>.

Comment by Shing Wai Chan [ 21/Aug/15 ]

Yes, this requires a schema change.
The schemas/javaee8 directory is not there yet. We need to wait for the setup.

Comment by markt_asf [ 21/Aug/15 ]

I'm not convinced this is a good idea. Web applications should be independent of the context path at which they are deployed.

Comment by Shing Wai Chan [ 15/Sep/15 ]

Per discussion in EG, we agree to add <default-context-path> element in web.xml.
Sending src/web-app_4_0.xsds
Sending src/web-common_4_0.xsds
Sending src/web-fragment_4_0.xsds
Sending test/web-app-complete.xml
Sending test/web-app-data-source.xml
Sending test/web-app-resources.xml
Sending test/web-app.xml
Sending test/web-fragment-complete.xml
Transmitting file data ........
Committed revision 64096.

Sending deployment.fm
Sending images/web-app.png
Sending servlet.book
Sending status.fm
Transmitting file data ....
Committed revision 111.





[SERVLET_SPEC-84] Problems with links in the Servlet 3.1 Spec Created: 21/Nov/13  Updated: 23/Apr/17  Resolved: 23/Jan/17

Status: Resolved
Project: servlet-spec
Component/s: API
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Arend v. Reinersdorff Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: MS 2 Sprint 2

 Description   

Broken links to java.sun.com:
page 6 - http://java.sun.com/products/servlet - new: http://www.oracle.com/technetwork/java/index-jsp-135475.html
page 6 - http://java.sun.com/javaee/ - new: http://www.oracle.com/technetwork/java/javaee/overview/index.html
page 7 - http://java.sun.com/xml - ?
page 61 - http://java.sun.com/products/jsp - new: http://www.oracle.com/technetwork/java/index-jsp-138231.html
page 124 - http://java.sun.com/products/jsp - new: http://www.oracle.com/technetwork/java/index-jsp-138231.html
page 127 - http://java.sun.com/j2se/1.4/docs/guide/extensions/ - new: http://docs.oracle.com/javase/7/docs/technotes/guides/extensions/index.html

Typo, one 'w' too many
page 7 - http://wwww.ietf.org/rfc/

Closing bracket should not be included in link when clicked:
page 207 - http://jcp.org/jsr/detail/109.jsp]

Example links should use example.com instead of real domains:
page 53, 123 - http://www.mycorp.com/catalog - better: http://www.example.com/catalog
page 82 - http://www.myserver.com/catalog/index.html;jsessionid=1234 - better: http://www.example.com/catalog/index.html;jsessionid=1234
page 238 - http://java.sun.com/products/servlet/index.html - better: http://java.example.com/products/servlet/index.html
page 238 - https://javashop.sun.com/purchase - better: https://example.com/purchase



 Comments   
Comment by Arend v. Reinersdorff [ 20/Dec/15 ]

Update for Servlet 4.0 Spec, Early Draft Review:

Broken links to java.sun.com:
page 61 - http://java.sun.com/products/jsp - new: http://www.oracle.com/technetwork/java/index-jsp-138231.html
page 126 - http://java.sun.com/products/jsp - new: http://www.oracle.com/technetwork/java/index-jsp-138231.html
page 129 - http://java.sun.com/j2se/1.4/docs/guide/extensions/ - new: http://docs.oracle.com/javase/7/docs/technotes/guides/extensions/index.html

Typo, one 'w' too many
page 7 - http://wwww.ietf.org/rfc/

Closing bracket should not be included in link when clicked:
page 194 - http://www.jcp.org/en/jsr/detail?id=109]
page 209 - http://jcp.org/jsr/detail/109.jsp]

Example links should use example.com instead of real domains:
page 53 - http://www.mycorp.com/catalog - better: http://www.example.com/catalog
page 82 - http://www.myserver.com/catalog/index.html;jsessionid=1234 - better: http://www.example.com/catalog/index.html;jsessionid=1234
page 125 - http://www.mycorp.com/catalog - better: http://www.example.com/catalog
page 242 - http://java.sun.com/products/servlet/index.html - better: http://java.example.com/products/servlet/index.html
page 242 - https://javashop.sun.com/purchase - better: https://example.com/purchase

Comment by jagdeesh [ 24/Dec/15 ]

updates on broken link.
If i am wrong please correct me for.
pg : 129 - http://java.sun.com/j2se/1.4/docs/guide/extensions/ - new:
http://docs.oracle.com/javase/8/docs/technotes/guides/extensions/index.html

Comment by Ed Burns [ 23/Jan/17 ]

Committed revision 124.

Comment by Arend v. Reinersdorff [ 23/Apr/17 ]

Looks mostly good, thanks

Some issues remain:
1) Updated link points to Java 7 docs, as Servlet 4.0 requires Java 8, it should link to Java 8 docs:
page 131 - http://docs.oracle.com/javase/7/docs/technotes/guides/extensions/versioning.html - better: http://docs.oracle.com/javase/8/docs/technotes/guides/extensions/versioning.html

2) Example link still points to real domain:
page 53 - http://www.mycorp.com/catalog - better: http://example.com/catalog

3) Found an additional use of a real domain as an example:
page 201 - webmaster@mycorp.com - better: webmaster@example.com

4) Found additional uses of real domains as examples in Java class names:
page 202 - com.mycortp.CatalogServlet - better: com.example.CatalogServlet
page 77 - com.acme.ImageServlet - better: com.example.ImageServlet
pages 106, 107 (x2), 108, 109, 110 - com.foo.Bar.class - better: com.example.Bar.class
pages 108 (x2), 109, 110 - com.foo.Bar2.class - better: com.example.Bar2.class
pages 109, 110 - com.foo.Bar3.class - better: com.example.Bar3.class
pages 112 (x3), 113 (x7), 114 - com.acme.Foo - better: com.example.Foo
pages 142, 143 (x2) - com.acme.MyConnectionManager - better: com.example.MyConnectionManager
pages 142 (x2), 143 (x2) - com.acme.MyLoggingModule - better: com.example.MyLoggingModule





[SERVLET_SPEC-85] Example deployment descriptors still use version 2.5 instead of current version Created: 21/Nov/13  Updated: 23/Apr/17  Resolved: 23/Jan/17

Status: Resolved
Project: servlet-spec
Component/s: API
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Arend v. Reinersdorff Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: MS 2 Sprint 2

 Description   

Servlet 3.1 Spec
page 179, 14.5.1 A Basic Example
page 180, 14.5.2 An Example of Security

The XML schema declarations are hard to remember. It would be nice to have a working example for the current version in the spec.



 Comments   
Comment by Arend v. Reinersdorff [ 20/Dec/15 ]

Update for Servlet 4.0 Spec, Early Draft Review:
page 201, 14.5.1 A Basic Example
page 202, 14.5.2 An Example of Security

Comment by Arend v. Reinersdorff [ 23/Apr/17 ]

The examples have been updated, but not to the current version (4.0) but to the previous version (3.1). I would prefer to have examples of the current version.

Affects:
page 201, 14.5.1 A Basic Example
page 202, 14.5.2 An Example of Security
In both places the xsi:schemaLocation and version attributes.

Is:
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee webapp_
3_1.xsd"
version="3.1">

Should be:
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee webapp_
4_0.xsd"
version="4.0">





[SERVLET_SPEC-174] 3.11 references RFC 2616 Created: 25/Apr/17  Updated: 25/Apr/17  Resolved: 25/Apr/17

Status: Resolved
Project: servlet-spec
Component/s: API
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: reschke Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: MS 5 Sprint 2

 Description   

Section 3.11 references RFC 2616 where it should reference https://greenbytes.de/tech/webdav/rfc7231.html#rfc.section.5.3.5 instead.



 Comments   
Comment by Ed Burns [ 25/Apr/17 ]

I am honored that the man himself is paying such close attention to our little corner of the spec world. Thank you for your interest. I fixed it now.

M requestobject.fm

  • Replace RFC 2616 reference with RFC 7231 reference. Thanks to RFC author
    Julian Reschke himself.
    Sending requestobject.fm
    Transmitting file data .done
    Committing transaction...
    Committed revision 152.




[SERVLET_SPEC-76] Javadoc coding error in javax.servlet.http.HttpSession interface Created: 29/Jul/13  Updated: 30/Jul/13  Resolved: 30/Jul/13

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: Kim Haase Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If you look at the page source for http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpSession.html you will see that the documentation for the setAttribute method contains "<code>" instead of "</code>" after the "()" at the end of this sentence:

If the value passed in is null, this has the same effect as calling removeAttribute().

This causes all the rest of the documentation for this interface to be in code font.

I can make the fix in the HTML output on the web site, but it should be fixed in source so that the erroneous code is not generated in the future. (The problem has actually been there since J2EE 1.3.1 – it was just recently called to my attention.)

This should be an easy fix.



 Comments   
Comment by Shing Wai Chan [ 30/Jul/13 ]

Sending HttpSession.java
Transmitting file data .
Committed revision 62430.





[SERVLET_SPEC-148] HttpServletRequest#getPushBuilder missing @since 4.0 Created: 18/Nov/15  Updated: 20/Jan/17  Resolved: 20/Jan/17

Status: Resolved
Project: servlet-spec
Component/s: API
Affects Version/s: 4.0-m01
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: pbenedict Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Missing @since 4.0



 Comments   
Comment by Ed Burns [ 20/Jan/17 ]

Committed revision 64420.





[SERVLET_SPEC-88] Who decides if the error message is safe to display? Created: 27/May/14  Updated: 09/Feb/17  Resolved: 09/Feb/17

Status: Resolved
Project: servlet-spec
Component/s: Container
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File 20170207-2128Z-SERVLET_SPEC-88.patch    
Sprint: MS 3 Sprint 1

 Description   

Reported by Mark Thomas:

When an application calls HttpServletResponse.sendError(int, String) the
Javadoc states that:

The server defaults to creating the response to look like an
HTML-formatted server error page containing the specified message,
setting the content type to "text/html".

My question is a simple one.

If the message contains user provided data (for example it might say
"ABCDEFG is not a valid UK postcode) who is responsible for ensuring
that the message is safe to use in the error response? Is it the caller
or is it the component that generates the error response?

It is my belief that it is the component generating the error response
that is responsible. The caller does not know what format will be used
for the error response (HTML, XML, JSON, something else) and, therefore,
has no way of determining what is the appropriate escaping / encoding /
safety mechanism of choice to use. Therefore, it has to be the
responsibility of the component generating the response.

Do the other EG members agree and, if so, can we get the spec updated to
make that explicit?



 Comments   
Comment by Ed Burns [ 09/Feb/17 ]

bash-4.1$ svn commit -F changebundle.txt src/main/java/javax/servlet/http/HttpServletResponse.java
Sending src/main/java/javax/servlet/http/HttpServletResponse.java
Transmitting file data .
Committed revision 64527.





[SERVLET_SPEC-170] Update LICENSE.txt for compliance Created: 13/Feb/17  Updated: 13/Feb/17  Resolved: 13/Feb/17

Status: Resolved
Project: servlet-spec
Component/s: API
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: MS 3 Sprint 2

 Description   

See Ed Bratt email.



 Comments   
Comment by Ed Burns [ 13/Feb/17 ]

Turns out this already appears to come for free via maven grabbing the license from the master copy.





[SERVLET_SPEC-121] Create components for this JIRA Created: 17/Dec/14  Updated: 24/Mar/17  Resolved: 06/Dec/16

Status: Resolved
Project: servlet-spec
Component/s: Misc
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Trivial
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 3 hours, 7 minutes
Original Estimate: Not Specified

Attachments: Text File 20161202-servlet-issue-husbandry.txt    
Issue Links:
Blocks
blocks SERVLET_SPEC-166 Add support for http 1.1/2.0 "Trailer... Open

 Description   

The JIRA for Servlet Spec, https://java.net/jira/browse/SERVLET_SPEC/ has this unfortunate text on its admin page, "This project does not use any components." It would be really helpful to have some categories to help us work with issues.



 Comments   
Comment by Ed Burns [ 05/Dec/16 ]

Proposed JIRA Components, by decreasing order of issues in each component

COMP: Configuration (17)
COMP: Container (15)
COMP: HTTP (15)
COMP: Paths/Mappings (14)
COMP: Security (13)
COMP: I/O (10)
COMP: API (8)
COMP: Filter/Servlet (6)
COMP: Listeners (4)
COMP: Sessions (2)
COMP: Project Management (1)
COMP: Deployment (0)

Comment by Ed Burns [ 06/Dec/16 ]

SW> I am not sure about the Paths/Mappings.

EB> I'll drop that one. My intent was to be for issues that have to do with
EB> the mapping of servlets and filters and anything to do with what appears
EB> in the first line of the HTTP request. Do you have another suggestion
EB> for the ones I have in that component? Let me know and I'll add it.

SW> Should we have a Other or Misc?

EB> Yes, good idea. I'll add that as well. I'll put the Paths/Mappings ones
EB> in there until I hear from you with another suggestion.





[SERVLET_SPEC-44] Client close notification Created: 21/Aug/12  Updated: 06/Dec/16

Status: Reopened
Project: servlet-spec
Component/s: I/O
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: jitu Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 17
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

There is no notification event for client close.
Is it possible to add AsyncListener#onClose() when the client is disconnected ? This will be
useful for long running connections like server-sent events connection.

On the other hand, SE socket API itself doesn't provide that option. So there may be no way to get client close notification when there is no pending i/o.



 Comments   
Comment by Marek Potociar [ 23/Aug/12 ]

onDisconnect(...) would be a better name IMO. Also, if that's not possible due to the lack of JavaSE Socket API, should it be clarified that onError(...) could be used for that purpose?

Comment by Shing Wai Chan [ 08/Jan/13 ]

There is no way to know when the socket is closed from SE API.

Comment by jfarcand [ 24/Apr/13 ]

I disagree. Any NIO layer can detect when the underlying connection is getting closed. Look at Grizzly/Tomcat NIO/Netty, they all able to handle that case.

Comment by Shing Wai Chan [ 24/Apr/13 ]

java.nio.channels.Channel#isOpen tests whether or not the channel is open.
So, we will revisit the issue.

Comment by Mikhail Mazursky [ 19/Jul/13 ]

Because this feature is missing it is not possible to stop resource consuming computations on server if client disconnects. Please, see this ticket for example https://sourceforge.net/apps/trac/bigdata/ticket/694

Comment by rstoyanchev [ 10/Dec/13 ]

Adding a link to a discussion on Tomcat's user list.

Comment by rstoyanchev [ 10/Dec/13 ]

As one example of why this matters consider the SockJS protocol that provides HTTP fallback options for WebSocket.

The protocol does not define any client-side "close" frame. It expects the server will detect when the HTTP connection is closed and indeed a variety of server-side implementations in a range of languages (node, erlang, python, ruby) do.

A Java implementation – with Servlet 3 async for the long polling or HTTP streaming – however cannot detect when a client has gone away. This is a very fundamental, missing feature that puts Java Servlet-based implementations at a significant disadvantage.





[SERVLET_SPEC-119] Clarification of threading requirements of section 6.2.3 Created: 15/Dec/14  Updated: 06/Dec/16

Status: Reopened
Project: servlet-spec
Component/s: Container
Affects Version/s: None
Fix Version/s: 4.0, 4.0-m01

Type: Improvement Priority: Minor
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 40 minutes
Original Estimate: Not Specified


 Description   

>>>>> On Sat, 06 Dec 2014 00:14:51 +0000, Mark Thomas <markt@apache.org> said:

MT> Hi,
MT> Section 6.2.3 includes the following text:

Spec> A Filter and the target servlet or resource at the end of the
Spec> filter chain must execute in the same invocation thread.

MT> As a result of a bug raised against Apache Tomcat [1] I am seeking
MT> clarification of the meaning of that sentence.
MT>
MT> [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=57284



 Comments   
Comment by Ed Burns [ 15/Dec/14 ]

If the Filter wants to go async, allowing them to do so would be
consistent with that design intent. In the absence of further data, let
me suggest some alternate text for section 6.2.3.

Proposed623> When operating in synchronous mode, a Filter and the target
Proposed623> servlet or resource at the end of the filter chain must
Proposed623> execute in the same invocation thread. When operating in
Proposed623> asynchronous mode, a Filter and the target servlet or
Proposed623> resource at the end of the filter chain must execute on the
Proposed623> invocation thread to which control is handed when the
Proposed623> asynchronous processing commences.

Comment by Ed Burns [ 15/Dec/14 ]

Further input from Mark Thomas.

Comment by gregwilkins [ 16/Dec/14 ]

I'm not sure this one is sufficiently agreed to be closed.

I'm not sure what the new text means when it says "on the invocation thread to which control is handed when the asynchronous processing commences". Asynchronous processing may not have 1 thread in control, it may have many threads in control.

Currently I am not convinced that we should allow arbitrary threads to call FilterChain.doFilter or RequestDispatcher.forward. I don't think it has been established why the current spec text is not good. I also think that any such change needs to be very carefully reviewed against issues such:
+ what should the getContextPath getSErvletPath methods return? what about the race with the exiting container thread?
+ what about calls to ServletRequestListeners are called and if ThreadLocals can be used.

Can we reopen this one and discuss more on the list?

Comment by Ed Burns [ 18/Dec/14 ]

svn commit -m "Revert change for SERVLET_SPEC-119" filters.fm
Sending filters.fm
Transmitting file data .
Committed revision 103.





[SERVLET_SPEC-11] Clarification required for ServletContext.getRealPath and HttpServletRequest.getPathTranslated Created: 21/Sep/11  Updated: 06/Dec/16

Status: In Progress
Project: servlet-spec
Component/s: Misc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: markt_asf Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

There appear to be different interpretations of the required behaviour of ServletContext.getRealPath(java.lang.String path) and HttpServletRequest.getPathTranslated() if the virtual path can be mapped to a physical path but the physical path does not exist.

My reading of the specification and the Javadoc is that the physical path does not have to exist, just that the mapping has to be possible. However, I can see how someone else could read the specification as requiring the physical path to exist and null to be returned if it does not.

This should be clarified for Servlet 3.1 and ideally the clarification included in any subsequent maintenance releases of the earlier specification versions.



 Comments   
Comment by gregwilkins [ 23/Sep/11 ]

I think the text should be changed to indicate that a path should be returned if it possibly could exist.

Typically this would mean that if getRealPath("/") returns a non null path, then all calls to getRealPath should not be null.

Comment by Rajiv Mordani [ 28/Jun/12 ]

In section 3.6 of the spec we clearly say

In situations where the servlet container cannot determine a valid file path for these methods, such as when the Web application is executed from an archive, on a remote file system not accessible locally, or in a database, these methods must return null. Resources inside the META-INF/resources directory of JAR file must be considered only if the container has unpacked them from their containing JAR file when a call to getRealPath() is made, and in this case MUST return the unpacked location.

and the javadocs also says along the same lines. What do you think will make it clearer?

Comment by markt_asf [ 28/Jun/12 ]

If memory serves me correctly this wasn't a WAR/database/virtual vs local filesystem issue. If was purely in the context of a local file system when everything is unpacked.

Take, for example, a WAR with context path "/foo" unpacked on the local file system to "/usr/local/webapps/foo".

Assume that there also exists the directory "/usr/local/webapps/foo/bar"

When called from the "foo" web application, getRealPath("/bar") will return "/usr/local/webapps/foo/bar".

The question is, what should getRealPath("/other") return?

Should it:
a) return "/usr/local/webapps/foo/other" since that what it maps too?
b) return null since "/usr/local/webapps/foo/other" does not exist?

This really boils down to what does the specification mean by valid in section 3.6? I think we need to make it clear that "valid" does not mean "must exist".

I've dug through the archives and the Tomcat bug that prompted this request for clarification was this one: https://issues.apache.org/bugzilla/show_bug.cgi?id=51799

Comment by Rajiv Mordani [ 29/Jun/12 ]

The getRealPath should return the real paths for resources that are available. So to be specific - in the example above if "other" does not exist in the webapp then it should return null. Looking at the issue filed for tomcat, Remy seems to suggest that it return the path so it is possible to create a file / directory using it. We can discuss this in the EG.





[SERVLET_SPEC-7] Clarify expected behviour of fitlers and welcome files Created: 25/Aug/11  Updated: 06/Dec/16

Status: In Progress
Project: servlet-spec
Component/s: Filter/Servlet
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: markt_asf Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The specification is not explicit regarding the order of welcome file processing and filter mapping. This has caused limited user confusion.

My own expectation is that welcome files are processed first and then filter mappings. Previous conversations with Servlet 3.0 EG members confirmed this. It would be help to get a short note of this added to the Servlet 3.1 spec.



 Comments   
Comment by rojkov [ 07/Dec/11 ]

I am not sure I understand. Can I still a filter request to a welcome file with the proposed change?

Comment by markt_asf [ 07/Dec/11 ]

OK. Here is some additional clarification.

If a user requests "/foo" and "/foo" is a directory, the welcome files "index.jsp" and "index.html" are configured and "index.html" is present then what is compared against the filter mappings. Is it "/foo" or "/foo/index.html"

The clarification I previously received from the Servlet 3.0 EG is that is is "/foo/index.html" that is compared against the filter mappings. It is this clarification I would like to see in the 3.1 spec.

Comment by Rajiv Mordani [ 28/Jun/12 ]

Sounds reasonable to me - one question is what happens in the case of the DefaultServlet being invoked in the case where we don't have a welcome file? Should it then be that the filter is applied to /foo or not? I will start a thread on this in the EG.

Comment by Rajiv Mordani [ 09/Jan/13 ]

Mark I went back and looked at the discussion in the 3.0 and am including some of that here -

My colleague Shing Wai Chan pointed out that the proposed solution is
somewhat unsatisfactory in the sense that it still might be possible
to receive a 404 response when honoring one welcome page even if the
next welcome page in the list would have produced a valid result.

Consider a slight variation of Greg's original example, where
"index.html" is replaced with "foo.bar" in the list of welcome page
declarations:

index.jsp
foo.bar

Further assume that:

  • a servlet mapping (to the "FooBar" servlet) exists for "*.bar",
  • neither index.jsp nor foo.bar exist as file resources, and
  • the FooBar servlet does not depend on foo.bar in order to produce
    its response

The proposed new algorithm would not find any matching static
resources when enumerating the welcome page declarations during the
first round, but would honor the servlet mapping for index.jsp when
enumerating the welcome page declarations in the 2nd round, leading to
a 404, even if skipping "index.jsp" and picking "foo.bar" instead
would have produced a valid response.

I guess there is nothing we can do to help in this case. It would be
nice if it were possible to specify (in a welcome declaration) whether
the welcome page needs to exist as an actual file resource in order
for its mapped-to servlet to be able to produce a response, but the
current syntax for <welcome-file-list> would make this hard if not
impossible.

Comments?

Jan

and Greg's response to that was -

Jan,

I think this is indeed a problem, but I don't think there is much we can
do to fix it without changing the web.xml.

There is a fundamental problem of mixing the search semantics that
can be done on files with dispatching to servlets, which don't
support search semantics.

I think that the current compromise is the best we can do if we
wish to continue allow servlets to be welcome-files even when
the no file exists.

Given that even appending the files may not work, I think we can't really fix it the way you are suggesting.

Comment by markt_asf [ 09/Jan/13 ]

I think in the case of the default servlet returning a 404 then the filter should be applied if url-pattern matches whatever url the default servlet is returning a 404 for.

Regarding the the issues described in the extract of the Servlet 3.0 discussion I think that is a slightly different issue. In Tomcat we introduced a list of "resource only servlets" which essentially only get mapped to welcome files if a file resource (e.g. a JSP) exists at that URL. I do wonder if that container specific solution could be generalised (e.g by a new attribute on Servlet) but that is a discussion for a different issue / the mailing list.





[SERVLET_SPEC-134] Provide API supporting HTTP/2 Server Push Created: 14/Aug/15  Updated: 30/Mar/17

Status: In Progress
Project: servlet-spec
Component/s: HTTP
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 5 hours, 51 minutes
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-21664 Implement Servlet 4.0 Server Push Resolved

 Description   

The most visible user facing feature of HTTP/2 is Server Push. This issue tracks introducing Server Push to the Servlet API.



 Comments   
Comment by Ed Burns [ 14/Aug/15 ]

Doing the work in this branch <https://svn.java.net/svn/glassfish~svn/branches/SERVLET_SPEC-134>.

Comment by Shing Wai Chan [ 08/Mar/17 ]

After EDR, there are changes to PushBuilder as follows:
r64410 | swchan2 | 2017-01-18 11:52:17 -0800 (Wed, 18 Jan 2017) | 2 lines
change etag to eTag in PushBuilder

------------------------------------------------------------------------
r64461 | swchan2 | 2017-02-01 13:00:47 -0800 (Wed, 01 Feb 2017) | 2 lines
change HttpServletRequest#getPushBuilder with default returning null; javadoc fixes

------------------------------------------------------------------------
r64526 | swchan2 | 2017-02-08 17:02:43 -0800 (Wed, 08 Feb 2017) | 2 lines
add "request" header

------------------------------------------------------------------------
r64565 | swchan2 | 2017-02-17 10:53:10 -0800 (Fri, 17 Feb 2017) | 2 lines
throw IllegalArgumentException for non-cacheable or unsafe methods

------------------------------------------------------------------------
r64689 | swchan2 | 2017-03-01 16:06:54 -0800 (Wed, 01 Mar 2017) | 2 lines
change wording: #push "must be non-blocking" rather than "returning immediately without blocking"

------------------------------------------------------------------------
r64726 | swchan2 | 2017-03-06 13:21:32 -0800 (Mon, 06 Mar 2017) | 2 lines
remove IllegalArgumentException from #push

------------------------------------------------------------------------
r64738 | swchan2 | 2017-03-08 13:23:50 -0800 (Wed, 08 Mar 2017) | 2 lines
refer conditional headers to RFC 7232

Comment by Shing Wai Chan [ 15/Mar/17 ]

r64808 | swchan2 | 2017-03-15 13:49:01 -0700 (Wed, 15 Mar 2017) | 2 lines
remove #conditional, #eTag, #lastModified and corresponding getters

Comment by Shing Wai Chan [ 25/Mar/17 ]

rename #getPushBuilder to #newPushBuilder
Sending requestobject.fm
Sending servlet.book
Transmitting file data ..done
Committing transaction...
Committed revision 141.

Comment by Shing Wai Chan [ 30/Mar/17 ]

r64884 | swchan2 | 2017-03-29 15:59:34 -0700 (Wed, 29 Mar 2017) | 2 lines

rename HttpServletRequest#getPushBuilder to #newPushBuilder





[SERVLET_SPEC-107] Expose tls_unique as request attribute Created: 25/Sep/14  Updated: 06/Dec/16

Status: Open
Project: servlet-spec
Component/s: Security
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
is cloned by SERVLET_SPEC-151 CLONE - Expose tls_unique as request ... Resolved
Duplicate
duplicates SERVLET_SPEC-151 CLONE - Expose tls_unique as request ... Resolved

 Description   

>>>>> On Thu, 25 Sep 2014 11:32:41 -0400, Ron Monzillo said:

RM> In addition to the attributes currently required to be supported
RM> when a request has been received over a secure protocol, consider
RM> adding a requirement that that container make the value of
RM> tls_unique availbale via the required to be supported (SSL)
RM> attributes.

RM> tls_unique is defined in http://tools.ietf.org/html/rfc5929

RM> Access to this value will facilitate the practice of creating
RM> cookies and other session identifying tokens that are bound to a
RM> specific TLS connection (iow, that cannot be stolen and reused
RM> outside of the TLS connection under which they were established and
RM> returned).

RM> The attribute could be called: javax.servlet.request.tls_unique

RM> Note that support for this attribute above JSSE will require that
RM> the value of verifyData as conveyed in the TLS finished handshake
RM> message be available from the SSLSession object.



 Comments   
Comment by markt_asf [ 25/Sep/14 ]

What feature(s) does this enable that can't be implemented based on javax.servlet.request.ssl_session_id?

What benefits would this provide over an above using SSL based session tracking as per Servlet 3.1, section 7.1.2?

Comment by Ed Burns [ 23/Sep/15 ]

Mark, I'm not sure, but given that the feature was requested by Ron, I trust there is a valid usecase. I did some brief research and found <https://www.secure-resumption.com/>, where the following is stated:

For example the tls-unique channel binding refers to the first Finished message in the innermost handshake on the current connection, and hence by checking that this value matches on the client and server, they can presumably be assured that their communications are over the same connection.

Also, the RFC5929 Ron cites states

This definition of 'tls-unique' means that a channel's bindings
data may change over time, which in turn creates a synchronization
problem should the channel's bindings data change between the time
that the client initiates authentication with channel binding and
the time that the server begins to process the client's first
authentication message. If that happens, the authentication
attempt will fail spuriously.

So, I think we should add a row in the table in section 3.9 to honor Ron's request.

Comment by Ed Burns [ 23/Sep/15 ]

More text from the RFC.

7. Required Application Programming Interfaces

TLS implementations supporting the use of 'tls-unique' and/or 'tls- unique-for-telnet' channel binding types MUST provide application programming interfaces by which applications (clients and servers both) may obtain the channel bindings for a TLS connection. Such interfaces may be expressed in terms of extracting the channel bindings data for a given connection and channel binding type. Alternatively, the implementor may provide interfaces by which to obtain the initial client Finished message, the initial server Finished message, and/or the server certificate (in a form that matches the description of the 'tls-server-end-point' channel binding type). In the latter case, the application has to have knowledge of the channel binding type descriptions from this document. This document takes no position on which form these application programming interfaces must take.

TLS implementations supporting TLS renegotiation SHOULD provide APIs that allow applications to control when renegotiation can take place. For example, a TLS client implementation may provide a "callback" interface to indicate that the server requested renegotiation, but may not start renegotiation until the application calls a function to indicate that now is a good time to renegotiate.





[SERVLET_SPEC-79] As of Servlet 3.0, there is no way to create code guaranteed to run first before anything else Created: 31/Aug/13  Updated: 06/Dec/16

Status: Open
Project: servlet-spec
Component/s: Container
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Nick Williams Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: order, servlet-container-initializer, web-fragment

 Description   

In Servlet 2.5 and earlier, if you needed code that you could guarantee would always run first, you implemented ServletContextListener, put your important code in the initialization method, and defined it as the very first listener in your deployment descriptor web.xml. This was critically important for many tasks, such as logging initialization. Logging initialization typically must happen before anything else, or else it could be initialized incorrectly.

Servlet 3.0 added the awesome and useful concept of the ServletContainerInitializer, but this introduced a critical problem. There is no longer any way to create code guaranteed to run before anything else. First, a ServletContainerInitializer will always run before any ServletContextListener is initialized, so you can't rely on a ServletContextListener to run your critical startup code. I thought that a ServletContainerInitializer would run in the order of its web-fragment (either <order> in web-fragment.xml or <absolute-ordering> in web.xml), but I was wrong. The spec makes no such guarantee. Initializers are guaranteed nothing more than a random execution order. Because of this, it is impossible to guarantee that critical startup code will always run first.

Some containers appear to abide by the web-fragment order any. For example, Tomcat, TomEE, and JBoss definitely order initializers according to their web-fragment order (this is confirmed in code), while WebLogic and WebSphere appear to order them the same way (they are closed source, so this can't be completely confirmed, but the behavior is consistent). However, GlassFish, Jetty, and Resin order initializers in the order they are returned from the ClassLoader.

The execution of an ServletContainerInitializer should be ordered according to its web-fragment order. Alternatively a separate ordering mechanism could be specified, but this would seem to be unnecessary and burdensome. Furthermore, I think the committee should encourage (though obviously it cannot require) existing 3.0 and 3.1 implementations to apply this change retroactively, since it doesn't change the API.

Failing to require a predictable and controllable order for initializers is a serious oversight in the spec and represents a regression from 2.5, where it was possible to write code guaranteed to always run first.



 Comments   
Comment by markt_asf [ 19/Sep/13 ]

There are some further complicating factors here:
1. Ordering of container provided SCIs vs application provided SCIs
2. Ordering when the container and the application both provide an implementation of an SCI
2a. The application provided implementation may be disabled via ordering
2b. Delegation order determines which implementation (container or application) takes precedence when loading.

I suggest the following approach.

1. Container provided SCIs are always executed first in a container determined order.
a. If an application provides an alternative implementation then that is used at this point
regardless of exclusion via ordering
2. Application provided SCIs are executed in fragment order

Comment by dokovski [ 19/Sep/13 ]

In relation to 1a:
Does this mean that if an app has bundled web library that uses the SCI mechanism this library takes precedence over platform supplied ones? There is a recommendation in Java EE specification EE 8.2.3 Library Conflicts:
In particular:"Note that if the library is also a required component of the Java EE platform version on which the application is being deployed, the platform version may (and typically will) take precedence."

Comment by markt_asf [ 19/Sep/13 ]

Re 1a it actually depends on the configured delegation order (see Servlet 3.0/3.1 section 8.2 final paragraph). The point I was trying to make is if the container defines an SCI then it is loaded with the other SCIs even if it is loaded from the application. For this to happen:

  • the application would have to ship an SCI implementation that the container also defined
  • the container / application would have to configured with an application first class loading delegation order.

The aim is that all container specified SCIs are loaded first even if the implementations of some of them are provided by the application because the application ships with an alternative implementation.





[SERVLET_SPEC-31] Async Request parameters Created: 27/Feb/12  Updated: 06/Dec/16

Status: Open
Project: servlet-spec
Component/s: I/O
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: gregwilkins Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Section 9.7.2 describes a set of request attributes that contain the path values of the original request, so that they may be accessed by a servlet called as a result of a AsyncContext.dispatch(...)

However, this implies that these attributes are only set after a AsyncContext.dispatch(...), which means that they are not available to a thread that might be acting as part of a startAsync().... AsyncContext.complete() pattern.

Note that a thread cannot access the original request paths via AsyncContext.getRequest().getServletPath() because the value returned from that can be affected by forwards that happen before and/or after the startAsync call, or even a forward after an async dispatch. The path methods are inherently volatile.

I think that the ASYNC request parameters should be set when startAsync is called, so that those values are available for the entire async life cycle and not only during async dispatch.



 Comments   
Comment by gregwilkins [ 27/Feb/12 ]

Note also that the language used in this section could be improved, where it says:

The values of these attributes must be equal to the return values of the
HttpServletRequest methods getRequestURI, getContextPath, getServletPath,
getPathInfo, getQueryString respectively, invoked on the request object passed to
the first servlet object in the call chain that received the request from the client.

A request might never be passed to a servlet as it might be handled entirely by filters, or the first servlet object might be changed by a filter doing a dispatch.

Comment by rstoyanchev [ 19/Jul/12 ]

can be affected by forwards that happen before and/or after the startAsync call

Greg, the impression I got from SERVLET_SPEC-41 is that forwards cannot happen after a call to startAsync or are you referring to a different scenario?

Comment by gregwilkins [ 22/Aug/14 ]

very late response.

I don't see why a request can't be forwarded after async is started. It would be strange way to handle a request, but I see no reason for it to be prohibited.

But even if it can't be forwarded, it can be return from previous forwards after startAsync, so the values returned by the request.getXxx() methods will be volatile if access from an asynchronous thread.

Hence I believe the request attributes are the best way to obtain path information as they are immutable once set and thus thread safe.





[SERVLET_SPEC-2] Pluggable resource loaders Created: 14/Jun/11  Updated: 06/Dec/16

Status: Open
Project: servlet-spec
Component/s: Configuration
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Eirik Bjørsnøs Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive resourceloader-poc-2011-12-15.zip     Text File SERVLET_SPEC_2-2011-12-11.patch     Text File SERVLET_SPEC_2_JETTY_8_2011-12-15.patch     Text File SERVLET_SPEC_2_JETTY_servlet-spec_2011-12-15.patch    
Tags: future_release

 Description   

While the pluggability support in Servlet 3.0 was a great improvement, I do still find it to be a somewhat limited. In 3.0, all resources have to be bundled inside META-INF/resources in a jar in WEB-INF/lib in the deployed war. I think this is a bit rigid and that we would benefit from adding more flexibility in how resources can be loaded.

I suggest adding a provider interface to the servlet API which will allow implementors to load resources from arbitrary locations. That could be the file system, the network, OSGi bundles, the classpath, some generated in-memory representation or any other source which can locate and load resources.

How would this be useful? Our particular use case is to support plugin based architectures on the Servlet/JSP platform. For these kinds of applications, it it desirable to distribute apps and plugins independently. It is inconvenient having to reassemble the application war file just to add or upgrade a plugin. It should be possible to add it simply by dropping it in a folder. In the same way, would like to add and remove plugins at runtime. Both of these requirements are impossible to implement with Servlet 3.0, but should be easy to implement with the proposed API.

Other use cases that comes to mind might be: sharing of resources across contexts, loading resources from source during development and being able to separate downloadable application data from the application itself.

Also note that the current Servlet 3.0 way of loading resources from /META-INF/resources on the classpath could be implemented as a resource loader in the suggested design. Likewise, the normal resource loading from the war file could also be modeled as a resource loader. So in a way, we already have multiple ways of loading resources, we just don't have a well defined name and concept around it that people can use.  (Or rather framework developers, I don't see this as something the average developer will commonly have to deal with directly, they'll probably use a framework/library which supports it)

For the purpose of discussion, I'll throw out an initial design idea here:

-----------------------------------------------

  • New interface ResourceLoader:

package javax.servlet.ResourceLoader;

interface ResourceLoader {
 URL getResource(String path);
 Set getResourcePaths(String path);
 InputStream getResourceAsStream(String path);
}

(The methods will behave similar to their cousins in javax.servlet.ServletContext, just being scoped to a single ResourceLoader. "path" is the path being looked up.)

  • New method addResourceLoader(ResourceLoader resourceLoader) in javax.servlet.ServletContext which will register a ResourceLoader for use in the servlet context.
  • New web.xml / web-fragment.xml syntax:

<resource-loader>
   <resource-loader-class>com.example.MyResourceLoader</resource-loader-class>
</resource-loader>

  • Change javax.servlet.ServletContext methods getResource, getResourcePaths and getResourceAsStream to consider registered resource loaders in addition to the resources found in the war and in META-INF/resources. Resource loaders would be consulted in the order of their registration.

I'm very interested in hearing objections, ideas for alternative/improved/simpler designs, security concerns or other considerations. There's probably no shortage of things I haven't thought about



 Comments   
Comment by Eirik Bjørsnøs [ 14/Jun/11 ]

Discussion on users@servlet-spec.java.net :

http://java.net/projects/servlet-spec/lists/users/archive/2011-06/thread/1

Comment by Eirik Bjørsnøs [ 23/Jun/11 ]

I now have a working implementation of this based on Glassfish trunk.

I'll upload a patch, but I need to review the code and do some more testing first.

For now, here's a summary of changes/additions made:

------------
M deployment/schemas/src/main/resources/glassfish/lib/schemas/javaee_6.xsd
M deployment/schemas/src/main/resources/glassfish/lib/schemas/web-common_3_0.xsd

Added support for new XML syntax <resource-loader><resource-loader-class>com.example..</resource-loader-class></resource-loader>

(I know these will need to be moved to the 3.1 / jeee7 versions of these files, but I decided not to do that now after a few failed attempts.

------------
A + deployment/dol/src/main/java/com/sun/enterprise/deployment/node/web/ResourceLoaderNode.java
M deployment/dol/src/main/java/com/sun/enterprise/deployment/node/web/WebCommonNode.java
M deployment/dol/src/main/java/com/sun/enterprise/deployment/node/DescriptorFactory.java
A + deployment/dol/src/main/java/com/sun/enterprise/deployment/AppResourceLoaderDescriptorImpl.java
A + deployment/dol/src/main/java/com/sun/enterprise/deployment/web/AppResourceLoaderDescriptor.java
M deployment/dol/src/main/java/com/sun/enterprise/deployment/WebBundleDescriptor.java
M deployment/dol/src/main/java/com/sun/enterprise/deployment/xml/WebTagNames.java

Changes related to parsing the new <resource-loader> and <resource-loader-class> nodes and representing them as an AppResourceLoaderDescriptor. I pretty much stole the code from <listener> since they're structurally the same.

------------
M web/javax.servlet/src/main/java/javax/servlet/ServletContext.java
A web/javax.servlet/src/main/java/javax/servlet/ResourceLoader.java

Added the ResourceLoader interface and ServletContext.addResourceLoader.

------------
M web/web-core/src/main/java/org/apache/catalina/core/StandardContext.java
M web/web-core/src/main/java/org/apache/catalina/core/ApplicationContext.java
M web/web-core/src/main/java/org/apache/catalina/core/ApplicationContextFacade.java
M web/web-core/src/main/java/org/apache/catalina/servlets/DefaultServlet.java
M web/web-core/src/main/java/org/apache/catalina/Context.java
M web/web-core/src/main/resources/org/apache/catalina/core/LocalStrings.properties

  • Added support for adding resource loaders, programmatically or from a class name given via XML
  • Consult resource loaders when looking up resources in ServletContext's getResource*, getRealPath methods.
  • Consult resource loaders when serving resources in DefaultServlet.serveResource

------------
M web/web-glue/src/main/java/com/sun/enterprise/web/TomcatDeploymentConfig.java

Register the context's resource loaders by using the information available in AppResourceLoaderDescriptor

Comment by Eirik Bjørsnøs [ 23/Jun/11 ]

When adding support for resource loaders to DefaultServlet, I found the serveResource method to be hard to work with.

I've filed an issue in the Glassfish Jira for this, with some suggestions for improvements:

http://java.net/jira/browse/GLASSFISH-16871

Comment by Eirik Bjørsnøs [ 11/Dec/11 ]

Patch includes API changes to the Servlet spec and a working Glassfish implementation of the changes

Comment by Eirik Bjørsnøs [ 12/Dec/11 ]

Demo web application project. The webapp tests that the container implements resourceloader according to the specification.

The project also includes a demo of hot deployment of JSPs from OSGi bundles.

Comment by Eirik Bjørsnøs [ 12/Dec/11 ]

Including post to user list for reference:

Thinking about it, my resource loader proposal for Servlet 3.1 might
have a multi-tenancy story as well as a dynamic deployment story.

I initially focused on a single tenant being able to dynamically
(hot)deploy resources. However, being able to define custom resource
loaders will also enable resource sharing across multiple tenants
without having to use container specific hacks or custom builds of
webapps.

I've uploaded a patch to the Jira issue which adds the ResourceLoader
interface and the ServletContext.addResourceLoader method. The patch
also includes a working implementation of resource loader support in
Glassfish trunk.

Finally, I've also uploaded a proof-of-concept web application. This
application tests the container's implementation of the ResourceLoader
API. And just for fun, I threw in a ResourceLoader backed by OSGi
bundles using Apache Felix.

Comment by Eirik Bjørsnøs [ 15/Dec/11 ]

Updated poc with improved tests and getResourcePaths() implementation for OSGi

Comment by Eirik Bjørsnøs [ 15/Dec/11 ]

Patch implementing ResourceLoader support for Jetty 8

Comment by Eirik Bjørsnøs [ 15/Dec/11 ]

Updates to Jetty's 3.0 Servlet Spec module adding ResourceLoader





[SERVLET_SPEC-25] Require that filters that modify the response body must address content length and range requests Created: 07/Oct/11  Updated: 06/Dec/16

Status: Open
Project: servlet-spec
Component/s: Filter/Servlet
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: markt_asf Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If a filter modifies the response body it may cause problems for a servlet if the servlets set a content length or respond correctly to range requests.

The specification currently implies that wrapping the response is necessary if the response body is modified. This issue requests that filters that modify the response body are required to correctly handle (which will almost certainly mean wrapping the response) range requests and the content-length of the response.



 Comments   
Comment by Rajiv Mordani [ 08/Feb/13 ]

Isn't it the job of the filter? Do you want the specification to state that the Response MUST be wrapped if the response is modified?

Comment by markt_asf [ 08/Feb/13 ]

This came out of a Filter in one of the TCK tests modifying a resource returned by Tomcat's default servlet and the test failing because the Filter lengthened the request body but left the content length header unchanged. My aim with this request was to push responsibility for failures in this case onto the Filter.

I've done some further thinking on this. Since not all Servlets will return a range for a range request or set an explicit content length it seems unreasonable to expect all Filters that modify response bodies to ensure range requests and content length issues are correctly handled. I don't think we should place an unnecessary burden on Filter developers. On that other hand, I'd like the specification to be clearer about the consequences of a Filter modifying a response body and where the responsibility lies if it breaks. How about along the lines of the following - probably at the end of section 6.1:

"Filters that modify the response body generated by a Servlet SHOULD not break the functionality of that Servlet. For example, if the Servlet supports range requests or sets an explicit content-length, the Filter SHOULD take steps to ensure that the response to the client is correct."

Part of me would like to replace the "SHOULD"s with "MUST"s but I think that would be too prescriptive.

Comment by Rajiv Mordani [ 05/Mar/13 ]

The problem with this is that even though the target Servlet may support range, content-length etc, how does the filter find out? Also a subsequent Filter in the filter chain may dispatch the request to some other servlet altogether. I am ok with the line you suggest above, but that does not guarantee that all containers will implement it that way.





[SERVLET_SPEC-26] Valid response header names and values Created: 07/Oct/11  Updated: 06/Dec/16

Status: Open
Project: servlet-spec
Component/s: HTTP
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: markt_asf Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE

 Description   

Currently no validation is required when setting a response HTTP header or value. Should the specification require that invalid values are rejected? Should the specification provide a mechanism for escaping header names and values? What about values that cannot be escaped such as UTF-8 values?



 Comments   
Comment by Shing Wai Chan [ 22/Feb/13 ]

Adding it to the bucket of FUTURE_RELEASE

Comment by markt_asf [ 24/Sep/15 ]

My own view is that invalid headers names and/or values should be rejected with an IllegalArgumentException.

Comment by gregwilkins [ 25/Sep/15 ]

I'm fine with ISE being thrown, but I think the spec cannot define what is or is not a valid header name. That will be determined by the underlying transport and level of RFC implementation. So I think these methods MAY throw rather than MUST throw.

Comment by Shing Wai Chan [ 25/Sep/15 ]

I agree that Servlet spec cannot define what valid header names are as they defined by RFCs, etc. And there may be new RFCs in the future. So, the method may throw IllegalArgumentException seems to be better.





[SERVLET_SPEC-24] Clean-up of JNDI resources on application stop Created: 07/Oct/11  Updated: 06/Dec/16

Status: Open
Project: servlet-spec
Component/s: Container
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: markt_asf Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE

 Description   

To facilitate a graceful shutdown of resources that does not rely on GC (which may not happen for some time) it would be helpful if there was a way to signal to JNDI resources that they were no longer required.

The suggestion is that on application stop, the resource is checked for a zero argument close() method and that this method is called if it is present.



 Comments   
Comment by arjan tijms [ 01/Dec/11 ]

>the resource is checked for a zero argument close() method and that this method is called if it is present.

What about checking for the java.lang.AutoCloseable interface instead?

Comment by markt_asf [ 02/Dec/11 ]

That would work if the minimum Java version is Java 7. The proposal was written based on a current Tomcat feature that runs on earlier Java versions.

The disadvantage of using java.lang.AutoCloseable is that it requires that the resource being closed is written for Java 7. That is not always the case. A fall-back for non-Java 7 resources would be nice.

Comment by arjan tijms [ 03/Dec/11 ]

>That would work if the minimum Java version is Java 7

Indeed, but a newer version of the Servlet spec could at least support newer Java versions, couldn't it?

>A fall-back for non-Java 7 resources would be nice.

Sure, although I would be wary of just calling unknown methods that happen to match a given signature. With the java.lang.AutoCloseable we can be sure the resource creator has written the resource being aware that the close() method will be automatically called.

At the very least I think there should be an option to disable the fall-back. It would be strange if a close method didn't just did what it said, but you never known. It's perhaps a bit far-fetched, but what if the JNDI resource represents some administrative system and close() means a domain specific action is carried out, like closing a 'payment period'?

Comment by rojkov [ 07/Dec/11 ]

I am obviously missing something, but how do we know a given resource belongs to the app in question and the app should be closing it.

Comment by markt_asf [ 07/Dec/11 ]

Definition of JNDI resources is container specific but the container will know if the resource is specific to an application or shared and can call / not call the close method accordingly.

Comment by rojkov [ 07/Dec/11 ]

If /foo binds a resource to JNDI for use by /bar, should shutting down /foo close the resource?

I think assumption that a container close any resource with a close() method may go too far, so there should at least be a way to exclude and include resources. And that needs to be weighted against advising programmers to use application specific ContextListener to clean up JNDI tree on shutdown.

Comment by Shing Wai Chan [ 22/Feb/13 ]

Adding it to the bucket of FUTURE_RELEASE





[SERVLET_SPEC-20] Clarify implicit mappings and welcome file behaviour Created: 07/Oct/11  Updated: 06/Dec/16

Status: Open
Project: servlet-spec
Component/s: Misc
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: markt_asf Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Consider the following:
*.do is mapped to a servlet
welcome files are index.jsp, index.do

The intention is that the index.jsp page should be used if present and index.do (which always maps to the servlet) used if it is not. However, a strict reading of the servlet spec requires that a 404 is returned in index.jsp is not present .



 Comments   
Comment by gregwilkins [ 10/Oct/11 ]

The problem with this mechanism is that it was designed (and named) for welcome files. This has been somewhat subverted to allow for welcome servlets - ie if *.jsp is mapped to a servlet, then you get this 404 issue.

I believe the solution is to have a separate welcome servlet configuration, that would allow index.do to be attempted even though there is not a index.do file that exists.





[SERVLET_SPEC-21] Clarify behaviour with pre-emptive authentication Created: 07/Oct/11  Updated: 06/Dec/16

Status: Open
Project: servlet-spec
Component/s: Security
Affects Version/s: None
Fix Version/s: None

Type: