[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-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-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-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-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.





Generated at Fri Jul 03 13:26:35 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.