<< Back to previous view

[TYRUS-203] the value associated to @PathParam is not correct Created: 21/Jun/13  Updated: 24/Jun/13  Resolved: 24/Jun/13

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: 1.0
Fix Version/s: 1.1

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

Tags:
Participants: Pavel Bucek and Shing Wai Chan

 Description   

@ServerEndpoint(value="/echo/")
public class EchoServerEndpoint {
@OnMessage
public String echo(String message, @PathParam("color") String color) { return color + ":" + message; }
}

Suppose we have the following:
1. Client A: access /echo/black with message "one". Get "black:one".
2. Client B: access /echo/green with message "two". Get "green:two".
3. Client A: with previous websocket connection open, send "three". Instead of getting "black:three". We get "green:three".

From debugger, in org.glassfish.tyrus.core.SessionImpl, the pathParameters is the same in (1) and (3). However the value inside have changed.

Look like the last access path param wins in this case.



 Comments   
Comment by Pavel Bucek [ 24/Jun/13 12:59 PM ]

firstly, I can see an issue in your code. @ServerEndpoint value should be something like "/echo/", so it is little weird that your endpoint is matched. Anyway, will investigate.

Comment by Pavel Bucek [ 24/Jun/13 04:10 PM ]

reproduced; fix sent to internal review.

Comment by Pavel Bucek [ 24/Jun/13 04:16 PM ]

fixed in the trunk (rev 687).

Comment by Shing Wai Chan [ 24/Jun/13 04:53 PM ]

There is a typo in description.
It should be
@ServerEndpoint(value="/echo/")





[SERVLET_SPEC-83] ServletContext#getInitParameter with null parameter Created: 09/Oct/13  Updated: 09/Oct/13

Status: Open
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: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Shing Wai Chan

 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?






[SERVLET_SPEC-82] Clarify my responsibilities when I use Threadlocal variables in my Servlet. Created: 07/Oct/13  Updated: 09/Oct/13

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

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

Tags:
Participants: dtbullock, markt_asf and Shing Wai Chan

 Description   

A typical Servlet container services requests from a pool of threads. The Servlet container controls the lifecycle of those threads.

This creates a problem when my servlet (or a library which my servlet relies on) uses Threadlocal variables. For Tomcat, it means that when the context is undeployed, it has to check the viability of the threads in the pool to see if my code has 'polluted' them with Threadlocals. For example, it gives a warning like the following:

SEVERE: The web application [] created a ThreadLocal with key of type [org.apache.xmlbeans.impl.store.CharUtil$1] (value [org.apache.xmlbeans.impl.store.CharUtil$1@2aace7a7]) and a value of type [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@3d9c9ad4]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. Dec 13, 2012 12:54:30 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks

Is this really an exceptional situation though? Can't I expect that the container will do as Tomcat has done, without feeling the need to blame me for it? Even if I did have the opportunity to provide some kind of 'thread-will-no-longer-perform-work-for-this-webapp' hook, I wouldn't necessarily be able to clean up - sometimes it is 3rd-party libraries which use Threadlocal.

See the question here for more discussion if you like.



 Comments   
Comment by markt_asf [ 07/Oct/13 09:18 AM ]

If an application uses a ThreadLocal within a request then the application should ideally clean up that ThreadLocal before the request completes as there is no guarantee that the application will ever see that thread again. However, libraries often use ThreadLocals to retain expensive to create objects across requests. This makes clean-up more difficult although libraries that do this should also clean-up after themselves.

I'd have no objection to the requirement that code that creates a ThreadLocal is responsible for cleaning up that ThreadLocal when it is no longer required being spelt out in the Servlet spec.

I would argue that many uses of a ThreadLocal would be better implemented in a container environment by the use of a pool of objects bound to the ServletContext.

Comment by dtbullock [ 07/Oct/13 04:47 PM ]

As an app-author, I don't mind providing a handler with a signature like void thisThreadIsBeingRetired() to try and clean up as best I can. However, please note that:

  1. yes, I'd probably instead bind object pools to the ServletContext ... in my code;
  2. I'd only be trying to clean up after 3rd-party libraries;
  3. those 3rd party libraries:
    1. might not provide a way for me to say "hey, clean up the thread"
    2. might be using ThreadLocal for purposes other than object-pooling

As such, putting the responsibility on me (even with a handler to make it possible at all), is a half-way measure.

I'd rather not have to do anything, anyhow.

In the ultra-big picture of things, why would a container permit worker-threads to visit multiple ServletContexts over time and allow ThreadLocals to be set, yet have no way to perform reliable clean-up when the association between the worker-thread and the ServletContext is broken?





[SERVLET_SPEC-81] Clarify to users that the container will ensure work done in Servlet#init(ServletConfig) will be visible to threads which later invoke service methods. Created: 07/Oct/13  Updated: 09/Oct/13

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

Type: Improvement Priority: Minor
Reporter: dtbullock Assignee: Rajiv Mordani
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: dtbullock, markt_asf, Rajiv Mordani and Shing Wai Chan

 Description   

As a longtime user of the Servlet specification, I have recently become more aware of thread-safety concerns, and when making my last servlet, I realised that if doGet() and friends are invoked from a thread pool, they are only guaranteed to see assignments I make in init(ServletConfig) if someone else has taken adequate care that the work done by that thread is visible to others.

Presumably, containers have in fact done this for nearly two decades. But it would be nice to have it spelled out somewhere, so that I can rely on this behaviour, and don't need to second-guess the environment and perform my own locking/synchronization.



 Comments   
Comment by markt_asf [ 07/Oct/13 09:07 AM ]

This looks like an application concern rather than a container concern to me.

The container will guarantee that init(ServletConfig) completes successfully before processing any requests (as per the Javadoc for init) but makes no other guarantees.

How do you propose that the container ensures that "work" completed in init() is visible to all the request processing threads?

Comment by dtbullock [ 07/Oct/13 04:01 PM ]

That's just the point - the spec needs to provide a slightly stronger guarantee, and say that the end of init(ServletConfig) 'happens before' invocations of doGet() and friends, in the sense that it is defined in section 17.4.5 of the JLS

Without this guarantee, javax.servlet.GenericServlet by definition has a threading bug, because it does not synchronize access to the 'config' field.

I'm not a container-author nor an expert in the Java Memory Model, and I'm not asking for the spec to proscribe a particular mechanism. I just need the spec to relieve me of the responsibility. The beauty of the Servlet spec is that I don't have to think about concurrency matters and can basically pretend I'm in a single-threaded environment for most use-cases. However, when I do think about it, I want to be sure I'm thinking about it right.

However, I believe that the requirement could be satisfied by ensuring that worker-threads are forced to lock the same object-monitor which a given Servlet's initializer-thread unlocked, before they become eligible to handle requests for that Servlet. They need not lock it every time they need to invoke a service-method - just when they are first given a reference to the properly-initialized Servlet. This is a pretty natural way to arrange for thread co-operation, and probably happens de-facto all the time anyway. Hence this amendment would likely not put any further obligations on container-authors.

Comment by Shing Wai Chan [ 07/Oct/13 04:50 PM ]

In javadoc of Servlet#init(ServletConfig), we have
"The servlet container calls the init method exactly once after instantiating the servlet. The init method must complete successfully before the servlet can receive any requests."

This guarantees that the #init is invoked before #doGet.

Comment by dtbullock [ 07/Oct/13 05:38 PM ]

That would be entirely adequate if the servlet container calls init() and services requests using the same thread. However, containers do not necessarily do this. Therefore, the spec needs to specify whether the container-implementer or the servlet-author is responsible for handling the resultant thread-safety 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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: rgallard and Shing Wai Chan

 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 09:54 PM ]

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





[SERVLET_SPEC-78] Clarify welcome-files defined in fragments Created: 20/Aug/13  Updated: 09/Oct/13

Status: Open
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: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: janbartel and Shing Wai Chan

 Description   

Considering the definition of welcome-files, the 3.1 specification says that:

pg 8-79: The web.xml of the web application has the highest precedence when resolving conflicts between the web.xml, web-fragment.xml and annotations.

pg 8-79: a. Configuration settings in web fragments are used to augment those specified in the main web.xml in such a way as if they had been specified in the same web.xml.

pg 9-80: g. After the above conflicts have been resolved, these additional rules are applied
i. Elements that may be declared any number of times are additive across the web-fragments in the resulting web.xml. For example, <context-param> elements with different <param-name> are additive.
ii. Elements that may be declared any number of times, if specified in the web.xml overrides the values specified in the web-fragments with the
same name.
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-on-startup> 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.

pg 8-81 v. <welcome-file> declarations are additive.

Therefore, what should happen in the following situations:

1. web.xml defines a list of welcome-files and a fragment-web.xml also defines a list of welcome-files. Are the ones from the fragment additive or does web.xml take precedence?

2. the servlet container provides a default set of welcome-files, the web.xml does NOT define any welcome-files, but a fragment-web.xml defines a different list. Should the final list of welcome files contain the union of those defined by the servlet container and the fragment, or only those defined by the fragment.






[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Eugene Chung and Shing Wai Chan

 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 07:23 PM ]

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





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Kim Haase and Shing Wai Chan

 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 10:52 PM ]

Sending HttpSession.java
Transmitting file data .
Committed revision 62430.





[SERVLET_SPEC-74] HttpServletResponse#sendRedirect(String) could use some improvement; needs 301/302/303 support; needs way to set request body Created: 25/May/13  Updated: 09/Oct/13

Status: Open
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: Unresolved Votes: 1
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day

Tags: http response redirect permanent get 301 302 303
Participants: Nick Williams and Shing Wai Chan

 Description   

Currently, HttpServletResponse#sendRedirect(String) specifies the following hard-wired behavior that cannot be changed:

  • Send the redirect using status code 302 Found and the Location header.
  • Clear the buffer and set the response body to a short hypertext note with a hyperlink to the new URI.

I have three issues with this behavior that I summarize below, and at the bottom I propose a solution:

Issue 1

RFC 2616, says the following about 302 Found:

If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method.

The two keys here are 1) that the spec says browsers MUST NOT automatically redirect the request and 2) that there could be some browsers that send the second request with the original method (POST, PUT, etc.).

As an application not concerned with legacy HTTP/1.0 user-agents and more concerned with ensuring that user agents do not prompt the user for permission to redirect and do not redirect using a POST or a PUT, etc., I prefer to use the 303 See Other response as opposed to the 302 Found response:

The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. ... The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.

Issue 2

As an application that has recently been refactored, I want to be able to easily send a permanent redirect to users for old URLs that have been removed and should be changed. This can be achieved with the 301 Moved Permanently response:

The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. ... The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). ... If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

Issue 3

The exact wording of the short hypertext response included with the current 302 Found responses is not consistent across containers. As an application developer that cares about branding and consistency, I would like to be able to customize this text within my code and do so in a way that is consistent across all containers.

Recommendation

I believe the following additions to the Servlet API will greatly improve the current HttpServletResponse#sendRedirect(String) and satisfy the needs outlined here.

New HttpRedirectType Enum
public enum HttpRedirectType {
    /*
     * Indicates that the {@code 301 Moved Permanently} status should be used.
     * Could alternatively be called MOVED_PERMANENTLY.
     */
    PERMANENT,

    /*
     * Indicates that the {@code 302 Found} status should be used.
     * Could alternatively be called FOUND.
     */
    TEMPORARY_SAME_METHOD,

    /*
     * Indicates that the {@code 303 See Other} status should be used.
     * Could alternatively be called SEE_OTHER.
     */
    TEMPORARY_USE_GET;
}
Additions to HttpServletResponse
public interface HttpServletResponse {
...
    void sendRedirect(String location, HttpRedirectType type);

    void sendRedirect(String location, boolean replaceBuffer);

    void sendRedirect(String location, HttpRedirectType type, boolean replaceBuffer);
...
}
  • If replaceBuffer is true, the container should clear the buffer and replace it with the data set by this method. If replaceBuffer is false, the container should send the existing buffer and should not add to it (even if it is empty) or remove from it.
  • The existing sendRedirect(String) should call sendRedirect(location, HttpRedirectType.TEMPORARY_SAME_METHOD, true) to preserve current behavior.
  • The new sendRedirect(String, HttpRedirectType) should call sendRedirect(location, type, true) to use the default response body.
  • The new sendRedirect(String, boolean) should call sendRedirect(location, HttpRedirectType.TEMPORARY_SAME_METHOD, replaceBuffer) to use the default 302 Found response.





[SERVLET_SPEC-72] HttpUpgradeHandler and resource injection Created: 01/May/13  Updated: 27/Jun/13

Status: Open
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: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: janbartel, Shing Wai Chan and wizard.liyd

 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 03:48 AM ]

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

Comment by janbartel [ 01/May/13 06:55 AM ]

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 04:37 PM ]

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





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: janbartel and Shing Wai Chan

 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 05:20 AM ]

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 07:42 AM ]

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





[SERVLET_SPEC-70] Programmatic configuration API missing setting to replace <session-timeout> Created: 23/Mar/13  Updated: 09/Aug/13

Status: Open
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: Unresolved Votes: 3
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour

Tags: servlet-context sessions session-timeout
Participants: Eugen Paraschiv, kithouna, Nick Williams and Shing Wai Chan

 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 09:48 AM ]

This would definitely help get rig of the last remaining XML pieces.

Comment by kithouna [ 09/Aug/13 04:31 PM ]

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.





[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
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour

Tags:
Participants: Nick Williams and Shing Wai Chan

 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 07:11 PM ]

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 04:43 PM ]

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





[SERVLET_SPEC-66] Need way to track progress of requests; proposal included Created: 10/Mar/13  Updated: 24/Apr/13

Status: Open
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: Unresolved Votes: 1
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours
Environment:

n/a


Tags: multipart upload progressbar
Participants: Eugene Chung, Nick Williams and Shing Wai Chan

 Description   

Servlet 3.0 added multipart request processing to, in part, make handling file uploads easier (and easier it did make it). Before 3.0, many users used Commons FileUpload to accomplish this task. However, 3.0's multipart processing did not, unfortunately, completely eliminate the need for FileUpload. One of the major features lacking is the ability to track the progress of a large request.

This feature is sometimes called "file upload progress," but that name is misleading. It's actually "request progress," and it's the ability to measure and periodically report the number of bytes actually received versus the number of bytes indicated in the "Content-Length" header. As I propose below, I believe this should be relatively easy to add to the servlet spec, relatively easy to implement, and quite easy to use.

As proposed, this is independent of protocol (not strictly tied to HTTP/multipart/Content-Length). That could be changed, but I think this makes sense.

First, create a new interface:

ServletRequestProgressListener
package javax.servlet;

public interface ServletRequestProgressListener
{
    /**
     * Called whenever the number of bytes read changes, at least every 64 kilobytes.
     *
     * @param bytesRead The number of bytes that have been read so far, at least 0
     * @param bytesExpected The number of bytes expected to be read, -1 if unknown
     * @param itemsRead The number of items (parts in an HTTP multipart) processed so far
     */
    void update(long bytesRead, long bytesExpected, int itemsRead);

    /**
     * Called whenever the request has ended, either by being canceled or completed, 
     * normally or abnormally.
     */
    void destroy();
}

Next, add a method to ServletRequest:

ServletRequest
...
    /**
     * Attaches a progress listener to this request. Progress listeners must be attached in
     * a filter, before the request gets to the Servlet, in order to be effective.
     * 
     * @param progressListener The progress listener to update when the bytes read increases
     * @throws UnsupportedOperationException if the protocol does not support progress listeners
     */
    void setProgressListener(ServletRequestProgressListener progressListener);
...

Because the listener can be a source of performance problems, containers would only be required to call update (1) when first attached, and (2) every 64 kilobytes. Containers may call it more often, but do not have to. As proposed, I estimate 30 minutes to create the proposed interfaces and 1.5 hours to update the servlet specification documentation. Should only take 2-3 hours to add to the Tomcat implementation based on my examination of the code. Can't speak for the other implementations.

Using multipart as the primary example, since multipart processing is completed before the Servlet gets the request, the listener would have to be attached in a filter. A typical use case would be to create a listener and add it to a session so that it can later be queried by some Ajax call:

Psuedo-Code
...
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
    {
        if(request-is-large)
        {
            MyProgressListener listener = new MyProgressListener(request);
            request.getSession().addAttribute("progressListener", listener);
            request.setProgressListener(listener);
        }
    }
...


 Comments   
Comment by Nick Williams [ 10/Mar/13 11:47 PM ]

One unfortunate problem with NOT adopting this suggestion (in some form or another) is that here is no work-around that works within the spec. Either you don't have progress bars, or you don't use the multipart support added in 3.0. There's no "hard way" in the spec that this makes easier. This is making something possible that is currently impossible within the spec.

Comment by Eugene Chung [ 11/Mar/13 12:50 AM ]

+1

But all listeners of servlet are added via configuration(at deploy time). I think your suggestion, which is adding a listener at service time, can break consistency.

Comment by Nick Williams [ 11/Mar/13 01:15 AM ]

I thought about that, and my original draft had this set up as a configuration item, but there's a problem with that. All of the other listeners are configured across the servlet context. A session listener listens for new sessions or changes to sessions; a request listener gets notified of request events; a servlet context listener observes when the context starts and stops.

But this listener is very different. In fact, it is nothing like the other listeners at all. One of these listeners would be created for exactly one request. When that request was over, the listener would be destroyed and would no longer have any purpose. The update method makes it apparent why this is the case.

Perhaps, to make it clear that this is not a listener in the Servlet sense, it should have a different name, such as ServletRequestProgressFollower and setProgressFollower, but "listener," in a generic sense, really does describe what it's for.

(Also: should there be a getProgressListener/getProgressFollower method on ServletRequest in addition to the mutator?)

Comment by Nick Williams [ 11/Mar/13 01:45 AM ]

Actually, now that I think about it, maybe ServletRequestProgressFollower would be a better name...

Comment by Nick Williams [ 11/Mar/13 01:36 PM ]

I know this suggestion is pushing the line for Servlet 3.1, but I think it's a big improvement worth consideration. If there's anything I can do to help, I'm willing to drop whatever I'm working on to make it happen. I'm hoping there's time for just one more thing for Servlet 3.1.

If it comes to choosing between this and issue #67, 67 can definitely wait until 3.next, because it has a workaround. This issue, unfortunately, does not have a workaround.

Comment by Nick Williams [ 01/Apr/13 04:05 PM ]

I'd love to get some feedback on this. I haven't seen any discussion about it on the EG mailing list. Does the proposal need changes? Is it too late to add? That would be unfortunate, since there is no workaround.





[SERVLET_SPEC-65] Add CORS (Cross-Origin Resource Sharing) support in web.xml Created: 05/Mar/13  Updated: 05/Mar/13

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

Type: Improvement Priority: Major
Reporter: Samuel Santos Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE cors security servlet
Participants: Samuel Santos and Shing Wai Chan

 Description   

http://www.w3.org/TR/cors/ describes a mechanism to allow secure cross-origin resource sharing.
Please consider adding support for it in web.xml.






[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: janbartel and Shing Wai Chan

 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 02:13 AM ]

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 10:36 PM ]

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 04:27 AM ]

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-63] Consider adding an option to set Strict-Transport-Security header in web.xml Created: 21/Feb/13  Updated: 01/Mar/13

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

Type: Improvement Priority: Major
Reporter: Samuel Santos Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE security web-a
Participants: markt_asf, Samuel Santos and Shing Wai Chan

 Description   

Transparent redirection to HTTPS means that the vast majority of the time your users are on your site, they'll be using a secure connection. It does, however, leave a small window of opportunity for attack: the initial HTTP connection is wide open, vulnerable to SSL stripping and related attacks. Given that a man in the middle has complete access to the initial HTTP request, it can act as a proxy between you and the server, keeping you on an insecure HTTP connection regardless of the server's intentions.

You can mitigate the risk of this class of attack by asking the browser to enforce HTTP Strict Transport Security (HSTS). Sending the Strict-Transport-Security HTTP header instructs the browser to do the HTTP to HTTPS redirection client-side, without ever touching the network (this also happens to be great for performance; the best request is the one you don't have to make).

Please consider adding an option to set this header in web.xml.



 Comments   
Comment by markt_asf [ 21/Feb/13 01:07 PM ]

HSTS itself has a fairly large flaw in that the MITM can just remove the header before it ever reaches the client.

I'm not convinced of the usefulness of this mitigation. Sites that want to use it can always write a simple filter to add it.

Comment by Shing Wai Chan [ 22/Feb/13 10:23 PM ]

Adding it to the bucket of FUTURE_RELEASE





[SERVLET_SPEC-62] Provide a getAllUserRoles method Created: 20/Feb/13  Updated: 13/Feb/14

Status: Open
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: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE
Participants: arjan tijms, kithouna and Shing Wai Chan

 Description   

The Servlet API offers a method to retrieve the current user's principal (HttpServletRequest#getUserPrincipal) and a method that can be used to determine if the current user has a specific role (HttpServletRequest#isUserInRole).

There is however no corresponding method or way to retrieve a list with all roles that the current user has in a portable way. There is potentially a way to do this via JACC, but that's not exactly a straightforward way, plus JACC is not universally available in Servlet containers. A use case for this is e.g. displaying to the user a list of all roles he or she has, or the ability to input such a list of roles into a custom authorization system.

I would be great if such a method could be added.



 Comments   
Comment by Shing Wai Chan [ 22/Feb/13 09:42 PM ]

JACC provide a way to plugin a custom authorization system.
There are corresponding API to add role in javax.security.jacc.PolicyConfiguration.

I am not sure whether it is necessary to add those API in Servlet as we already have a mechanism to do that in JACC.

Adding it to the bucket of FUTURE_RELEASE.

Comment by arjan tijms [ 22/Feb/13 10:42 PM ]

I am not sure whether it is necessary to add those API in Servlet as we already have a mechanism to do that in JACC.

I indeed mentioned JACC as a potential way, but it's not exactly trivial. See this post (it's one of the few sources on this topic): https://blogs.oracle.com/monzillo/entry/using_jacc_to_determine_a and an associated forum thread: http://glassfish.10926.n7.nabble.com/Fetch-all-roles-assigned-to-an-user-td30843.html

If you look at the code and some of the assumptions, then it can be seen that it's really not trivial. In practice I rarely see people using such code, and I'm not 100% convinced it really works everywhere.

Whether it should be in Servlet is perhaps another question. Maybe there should be an overarching modern and easy to use security system in Java EE so a similar method would not have to be duplicated for e.g. EJB. However, since such overarching security system is not there now and HttpServletRequest already has methods that come close, it seems like a natural addition.

Comment by kithouna [ 13/Feb/14 01:25 PM ]

I am not sure whether it is necessary to add those API in Servlet as we already have a mechanism to do that in JACC.

But JACC tells us only how to interface with a custom authorization system. If we don't want that (majority of the cases) but just want to use the default authorization system, it's still reasonable to want to know the roles of the current user.

If JACC only required that each server had a default JACC implementation corresponding to the standard Servlet and EJB authorization rules, then yeah, JACC would work. But as it stands it doesn't.





[SERVLET_SPEC-61] Provide an isAccessAllowed method to see if user has access to URL Created: 20/Feb/13  Updated: 13/Feb/14

Status: Open
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: Unresolved Votes: 3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE
Participants: arjan tijms, balusc, Darious3, kithouna and Shing Wai Chan

 Description   

Following the Servlet spec, security constraints can be specified in web.xml. The Servlet container internally uses these to determine whether the current user has access to a given URL (Servlet 3.0 specification Section 12.1).

There is however no method in the public API that user code can use to do the same check. A use case for this would be the rendering of a list of links (e.g. in a menu), where the requirement is to not render those links where the user does not have access to. Without a means to ask the Servlet container about the access for every link, the code must either duplicate the URL-role association somewhere (perhaps in a custom XML file), or has to duplicate the algorithm from Section 12.1.

Both solutions are not ideal, since the container already maintains this association and already has an implementation of said algorithm.

Therefor I would like to request a "boolean isAccessAllowed(String url, String role)" method to be provided by the Servlet API, perhaps added to HttpServletRequest, that user code can use to determine if the current user has access to a given URL (relative to the context root of the web app).



 Comments   
Comment by balusc [ 20/Feb/13 08:30 PM ]

Putting it on ServletContext makes more sense. Having it on HttpServletRequest would be only useful if you'd like to check it against the currently logged-in user as in boolean isAccessAllowed(String url).

Comment by arjan tijms [ 20/Feb/13 09:57 PM ]

@balusc, you're right. Unfortunately I can't edit the description anymore.

Having two versions of the requested method would be ideal; one to do the check for the current user, and one to do the check for a given role independent of who the current user is.

Comment by Shing Wai Chan [ 22/Feb/13 10:22 PM ]

This can be achieved by checking javax.security.jacc.WebResourcePermission in JACC.

I am not sure whether it is necessary to provide the same functionality in Servlet spec.
Adding it to the bucket of FUTURE_RELEASE.

Comment by Darious3 [ 09/Jun/13 11:14 AM ]

Shing, does this mean that JACC will be a mandatory part of Servlet in the future?

At the moment JACC is not available in the Java EE Web Profile, and certainly not in Servlet Containers. JACC is also a bit difficult and arcane to work with. Even in the Java EE Full Profile an easier method to do this check would be a plus.

Comment by arjan tijms [ 05/Feb/14 10:26 PM ]

This can be achieved by checking javax.security.jacc.WebResourcePermission in JACC.

The problem is that even in containers that should support JACC (i.e. full Java EE implementations) JACC just isn't always there, but has to be "enabled". See e.g. the weblogic instructions:

To enable the WebLogic JACC Provider from the command line, you must specify the following system property/value pairs:

Property: java.security.manager

Value: No value required.

Property: java.security.policy

Value: A valid weblogic.policy file, specified using either a relative or an absolute pathname

Property: javax.security.jacc.PolicyConfigurationFactory.provider

Value: weblogic.security.jacc.simpleprovider.PolicyConfigurationFactoryImpl

Property: javax.security.jacc.policy.provider

Value: weblogic.security.jacc.simpleprovider.SimpleJACCPolicy

Property: weblogic.security.jacc.RoleMapperFactory.provider

Value: weblogic.security.jacc.simpleprovider.RoleMapperFactoryImpl

Source: http://docs.oracle.com/cd/E24329_01/web.1211/e24485/server_prot.htm#i1037363

I think it would not be unreasonable to assume that very few if any developers let alone anyone from IT will do this just to enable what should be a relatively simple utility method.

I also wonder how exactly you would code both versions of the required functionality with JACC. I can think of code such as the following;

Subject subject = (Subject) PolicyContext.getContext("javax.security.auth.Subject.container");
              
          boolean test = Policy.getPolicy().implies( new ProtectionDomain(
                new CodeSource(null, (Certificate[]) null),
                null, null, 
                subject.getPrincipals().toArray(new Principal[subject.getPrincipals().size()])
                ), 
                new WebResourcePermission("/protected/Servlet", ""))
            ;

But this will test if the current authenticated user has access, not if a given role has access. We can't just pass in a Principal for just the role we're looking for since the representation of that is container specific, isn't it?

Comment by kithouna [ 13/Feb/14 01:20 PM ]

The problem is that even in containers that should support JACC (i.e. full Java EE implementations) JACC just isn't always there, but has to be "enabled".

It's even worse...

Some containers don't even ship with a default JACC provider! WebSphere only ships with a JACC provider that is a client for an external Tivolo Access Manager server. There is no such thing as a default internal JACC provider. See http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm.websphere.nd.multiplatform.doc%2Fae%2Fcsec_jaccintegrate.html

In other words, the JACC methods for getting the current Subject and asking for roles etc are just not available on WebSphere. Since WebSphere is fully Java EE certified and TCK tested we can only conclude that JACC isn't really part of Java EE. I mean, the SPI to interface with a JACC provider is, but the actual JACC functionality isn't.





[SERVLET_SPEC-59] Add 'query_string' request attribute to the Error dispatched requests Created: 20/Feb/13  Updated: 01/Mar/13

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

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

Tags: FUTURE_RELEASE
Participants: martin_grigorov and Shing Wai Chan

 Description   

The servlet specification defines javax.servlet.forward.query_string and javax.servlet.include.query_string, but no javax.servlet.error.query_string.
If there is not specific reason why this attribute is excluded from the specification please add it for the next release.



 Comments   
Comment by Shing Wai Chan [ 22/Feb/13 09:18 PM ]

Adding it to the bucket of FUTURE_RELEASE





[SERVLET_SPEC-58] Support getting parameters from PUT requests Created: 19/Feb/13  Updated: 01/Mar/13

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

Type: Improvement Priority: Major
Reporter: sslavic Assignee: Rajiv Mordani
Resolution: Unresolved Votes: 7
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE
Participants: Rajiv Mordani, Shing Wai Chan and sslavic

 Description   

Many web frameworks, and some servlet containers have custom solutions which allow accessing request parameters from PUT requests. See related servlet-spec users mailing list discussion for more details.
It would benefit all if this support was covered in servlet spec.

Latest, Servlet 3.1 public review spec, has related paragraph:

3.1.1 When Parameters Are Available
The following are the conditions that must be met before post form data will be
populated to the parameter set:
1. The request is an HTTP or HTTPS request.
2. The HTTP method is POST.
3. The content type is application/x-www-form-urlencoded.
4. The servlet has made an initial call of any of the getParameter family of methods
on the request object.
If the conditions are not met and the post form data is not included in the parameter
set, the post data must still be available to the servlet via the request object's input
stream. If the conditions are met, post form data will no longer be available for
reading directly from the request object's input stream.

If there is no valid reason not to support PUT requests this paragraph should be changed to something like:

3.1.1 When Parameters Are Available
The following are the conditions that must be met before form data will be
populated to the parameter set:
1. The request is an HTTP or HTTPS request.
2. The HTTP method is POST or PUT.
3. The content type is application/x-www-form-urlencoded.
4. The servlet has made an initial call of any of the getParameter family of methods
on the request object.
If the conditions are not met and the form data is not included in the parameter
set, the data must still be available to the servlet via the request object's input
stream. If the conditions are met, form data will no longer be available for
reading directly from the request object's input stream.



 Comments   
Comment by Shing Wai Chan [ 22/Feb/13 09:14 PM ]

Adding it to the bucket of FUTURE_RELEASE





[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
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours
Environment:

All


Tags: HttpServletRequest Part file_upload filename
Participants: carojkov, markt_asf, Nick Williams and Shing Wai Chan

 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 06:59 PM ]

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 07:15 PM ]

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 07:18 PM ]

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 07:23 PM ]

+1

Comment by Nick Williams [ 20/Feb/13 03:35 PM ]

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 12:21 AM ]

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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: monzillo and Shing Wai Chan

 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 07:31 PM ]

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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: monzillo and Shing Wai Chan

 Description   

submitting recommendation from Jeff Williams



 Comments   
Comment by Shing Wai Chan [ 05/Mar/13 07:33 PM ]

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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: markt_asf and Shing Wai Chan

 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 11:36 PM ]

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





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: markt_asf and Shing Wai Chan

 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 07:33 PM ]

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





[SERVLET_SPEC-52] Clarify behaviour when the same filter is matched by several filter-mapping elements Created: 07/Jan/13  Updated: 09/Jan/13

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

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

Tags:
Participants: kkolinko and Shing Wai Chan

 Description   

The chapter 6.2.4 Configuration of Filters in a Web Application defines how a container builds the chain of filters to be applied to a particular request URI.

My question is what should happen if there are several matching filter-mappings for the same filter (either by different <url-pattern>s, or by an <url-pattern> and a <servlet-name>):
whether
a) the filter has to be called several times, as many as how many matching <filter-mapping>s are there.
or
b) the filter has to be called only once, honoring the first filter-mapping that matches,

An example:

<filter-mapping>
<filter-name>filterA</filter-name>
<url-pattern>/view/*</url-pattern>
<url-pattern>*.do</url-pattern>
</filter-mapping>

If the requested URI is "/view/bar.do", does the filter have to be called twice?

My own reading is that "a)" (multiple calls) is what is implied by that chapter, but I would like this to be mentioned explicitly.

If actually the requirement is "b)" (single call), then I would like someone to clarify what mapping takes priority when there is both an url-pattern and a servlet-name match. As the servlet-name mappings are processed first, it seems that the servlet-name mapping wins, but it is confusing as those filters are positioned later in the resulting filter chain than the ones mapped by url-patterns.

In Tomcat 7 the "b)" behaviour was implemented but with url-patterns having the priority, stemming from the following issue:
https://issues.apache.org/bugzilla/show_bug.cgi?id=49922






[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: BGehrels, markt_asf, Shing Wai Chan and violetagg

 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 05:08 PM ]

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 09:56 PM ]

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 10:35 PM ]

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 08:05 AM ]

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 05:33 PM ]

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 09:21 PM ]

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





[SERVLET_SPEC-50] Configure <error-page> programmatically in Servlet 3.0 Created: 01/Nov/12  Updated: 01/Mar/13

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

Type: Improvement Priority: Major
Reporter: shijas Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE
Participants: arjan tijms, Rajiv Mordani, shijas and Shing Wai Chan

 Description   

Web.xml can be programmatically created using Servlet 3.0. But features like <error-page> , < session-timeout> still needs to be configured in a web.xml.Can you provide a way to programmatically create these as well? Especially, error-page configuration.



 Comments   
Comment by Rajiv Mordani [ 09/Jan/13 07:55 AM ]

While we did provide programmatic APIs for adding servlets, filters and listeners, we have not exposed a full API for processing every element in the descriptor via APIs. Note that the programmatic APIs are not a complete replacement for the descriptor. It still makes sense to specify certain aspects via descriptors - just like in the case of annotations.

Comment by arjan tijms [ 09/Feb/13 09:15 PM ]

Ideally, every element (with some exceptions) would be settable in 3 ways, namely via:

  • The traditional descriptor
  • An annotation
  • A high level programmatic API

Note that JSF 2.2 introduced a method that's between the descriptor and the programmatic API: a call-back in which the descriptor is exposed as a DOM tree and can be programmatically manipulated. See http://jdevelopment.nl/jsf-22/#533 You could call this a low level programmatic API.

It might make sense to adopt the JSF 2.2 method for web.xml.





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: janbartel and Shing Wai Chan

 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 05:30 AM ]

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 08:06 PM ]

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 08:32 PM ]

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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Shing Wai Chan

 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 07:53 AM ]

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

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





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Shing Wai Chan

 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 05:16 AM ]

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-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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: janbartel and Shing Wai Chan

 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 12:42 AM ]

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





[SERVLET_SPEC-45] Access to connector/socket container info Created: 03/Sep/12  Updated: 01/Mar/13

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

Type: Improvement Priority: Major
Reporter: c.beikov Assignee: Rajiv Mordani
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE
Participants: c.beikov, Rajiv Mordani and Shing Wai Chan

 Description   

As discussed in the mailing list[1] a suggestion on how to extend the current api to expose information about the underlying connectors/sockets.
This is just the first idea that came into my head. Please suggest better ideas if you can think of any. Since I was just targeting to expose something like the https port to the application, I did't thought of better changes.

public interface ServletContext { // existing members public Set<ServletConnector> getConnectors(); }

public interface ServletConnector{ public int getPort(); public String getProtocol(); public boolean isSecure(); }

[1] http://java.net/projects/servlet-spec/lists/users/archive/2012-08/message/7



 Comments   
Comment by Shing Wai Chan [ 22/Feb/13 09:15 PM ]

Adding it to the bucket of FUTURE_RELEASE





[SERVLET_SPEC-44] Client close notification Created: 21/Aug/12  Updated: 10/Dec/13

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

Type: Improvement Priority: Major
Reporter: jitu Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 13
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: jfarcand, jitu, Marek Potociar, Mikhail Mazursky, rstoyanchev and Shing Wai Chan

 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 03:08 PM ]

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 10:31 PM ]

There is no way to know when the socket is closed from SE API.

Comment by jfarcand [ 24/Apr/13 12:06 AM ]

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 01:25 AM ]

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 07:50 AM ]

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 01:34 PM ]

Adding a link to a discussion on Tomcat's user list.

Comment by rstoyanchev [ 10/Dec/13 01:51 PM ]

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-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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: markt_asf and Shing Wai Chan

 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 01:22 AM ]

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 09:35 AM ]

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-39] Form Authentication redirection Created: 22/May/12  Updated: 22/Feb/13

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

Type: Bug Priority: Major
Reporter: gregwilkins Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE
Participants: gregwilkins and Shing Wai Chan

 Description   

When a request is received that requires form authentication, the server remembers the original URL (and perhaps form encoded parameters) and redirects to a login page. Once the user completes the login form a request is sent to j_security_check, which if authentication is successful a redirection is sent to the saved URL.

However, since browsers have caches, iframes and javascript that issues ajax style requests, and since users can decline to authenticate on the first presentation of a web form, it is possible that for a given session multiple requests are received that are redirected to the login form. The problem for the server is to decide if it should eventually redirect to the first of the saved URLs; to the last of the saved; or to some heuristically chosen one in between.



 Comments   
Comment by gregwilkins [ 22/May/12 10:40 AM ]

A potential solution would be to allow a token to be passed from the initial redirect to the login form page, and for the login form page to be able to pass that token to the j_security_check request, so that the server can precisely determine the request that was redirected to the login form and thus redirect back to that request and not to some other stray request that came before or after.

If no token is present, then we should still firm up the definition of what saved URL j_security_check should redirect to.

Comment by Shing Wai Chan [ 22/Feb/13 10:27 PM ]

Adding it to the bucket of FUTURE_RELEASE





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Christian Ludt and Shing Wai Chan

 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 06:36 PM ]

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-37] Update Cookie class and other specifications for RFC 6265 Created: 29/Mar/12  Updated: 22/Feb/13

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

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

Tags: FUTURE_RELEASE
Participants: gregwilkins, markt_asf and Shing Wai Chan

 Description   

Currently the Cookie class defaults to supporting RFC 2019 cookies.
RFC2019 was obsoleted by RFC2965 in 2000, which in turn was obsoleted by RFC6265 in 2011

The latest RFC appears to be well supported by browsers (eg Google cookies often contain commas which are not allowed by 2019, but are by 6265).



 Comments   
Comment by gregwilkins [ 29/Mar/12 04:03 AM ]

Actually my example of a , in the cookie value is wrong, as although google appears do be doing that, it is not allowed by RFC6265.
However, I do believe it is worthwhile reviewing the Cookie class and other cookie related parts of the spec against the latest RFC.

Comment by markt_asf [ 29/Mar/12 09:00 AM ]

My experience has been that no matter what cookie specification is followed by the container, there will be a client or application that can't handle specification compliant values. We have had to add no end of hacks to Tomcat's cookie handling to allow checks to be bypassed to enable stuff to actually work. For example, anything that requires quoting (such as using commas in values) is often not handled correctly if it is quoted.

There is a clear unwillingness on the part of some browser vendors to adhere to the cookie specifications and no sign of this being a something that causes users to migrate to a more standards compliant browser.

I don't particularly like the situation that has lead to RFC 6265 (I would have preferred to see user demand driving browser compliance but that hasn't happened) but RFC 6265 is probably the best option since it is closer to what is actually happening than anything else. That said, I suspect container vendors will still need to add additional options to bypass some checks.

Comment by Shing Wai Chan [ 22/Feb/13 10:28 PM ]

Adding it to the bucket of FUTURE_RELEASE





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: janbartel, Mark Struberg, markt_asf, Rajiv Mordani and Shing Wai Chan

 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 05:38 PM ]

The metadata-complete and invocation of ServletContainerInitializers are independent.

Comment by markt_asf [ 22/Jun/12 08:04 AM ]

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 10:04 PM ]

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 10:39 PM ]

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 12:37 AM ]

<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 08:31 AM ]

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 10:23 PM ]

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 05:30 AM ]

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 07:39 AM ]

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 08:37 AM ]

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 08:39 AM ]

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 04:38 PM ]

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 05:33 PM ]

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 08:40 PM ]

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 09:24 PM ]

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 10:15 PM ]

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 11:42 PM ]

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 07:18 AM ]

> 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 12:24 AM ]

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-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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: security
Participants: elygre and Shing Wai Chan

 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 02:01 AM ]

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 08:30 AM ]

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 09:53 PM ]

"*" 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 10:24 PM ]

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 12:29 AM ]

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 12:30 AM ]

See also section 13.4.1.3 in Servlet 3.1 PFD.





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Christian Ludt, markt_asf and Shing Wai Chan

 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 09:50 PM ]

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 11:26 PM ]

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 12:43 AM ]

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 06:08 PM ]

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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Shing Wai Chan

 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 07:38 PM ]

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

Comment by Shing Wai Chan [ 08/Mar/12 09:49 PM ]

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





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gregwilkins and Shing Wai Chan

 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 01:52 AM ]

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 07:42 PM ]

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





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: arjan tijms and Shing Wai Chan

 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 12:20 AM ]

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-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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-17721 @WebServlet annotation does not suppo... Resolved
Tags:
Participants: Amy Roh, emailnbw, rojkov and Shing Wai Chan

 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 03:11 AM ]

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

Comment by emailnbw [ 07/Dec/11 02:25 PM ]

@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 05:34 PM ]

@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 06:48 PM ]

@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 07:01 PM ]

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 07:36 PM ]

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 01:49 AM ]

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 10:31 PM ]

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-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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: markt_asf and Shing Wai Chan

 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 06:39 PM ]

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





[SERVLET_SPEC-26] Valid response header names and values Created: 07/Oct/11  Updated: 22/Feb/13

Status: Open
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: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE
Participants: markt_asf and Shing Wai Chan

 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 10:29 PM ]

Adding it to the bucket of FUTURE_RELEASE





[SERVLET_SPEC-24] Clean-up of JNDI resources on application stop Created: 07/Oct/11  Updated: 22/Feb/13

Status: Open
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: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE
Participants: arjan tijms, markt_asf, rojkov and Shing Wai Chan

 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 11:32 PM ]

>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 09:33 AM ]

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 05:03 PM ]

>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 03:22 AM ]

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 06:03 PM ]

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 06:18 PM ]

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 10:29 PM ]

Adding it to the bucket of FUTURE_RELEASE





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: markt_asf and Shing Wai Chan

 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 09:24 PM ]

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-21] Clarify behaviour with pre-emptive authentication Created: 07/Oct/11  Updated: 12/Feb/13

Status: Open
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: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: arjan tijms, markt_asf, monzillo and Shing Wai Chan

 Description   

The HTTP spec allows pre-emptive authentication - i.e. sending credentials before the server asks for them. It is unclear from the Servlet spec how getRemoteUser() and friends should behave in this regard when the resource being requested does not require authentication. Should the credentials be processed or ignored?



 Comments   
Comment by markt_asf [ 07/Oct/11 01:37 AM ]

Note: pre-emptive authentication can never work with DIGEST auth

Comment by monzillo [ 10/Jan/13 06:46 PM ]

imv, we should apply an established authentication session when we access
an unprotected resource within the session; that is, assuming the authentication session
conforms to the session mechanism configured for the application. iirc, the spec is not
clear on that, and it could be worth adding that as a requirement.

Regarding the processing of authenticators included in requests to unconstrained resources, I think such authenticators should be ignored during constraint processing (for the required to be supported authentication mechanism processors). Conversely they should be processed if the target resource makes a call to HttpServletRequest.authenticate.

That said, I think we should allow custom authentication mechanisms to decide how they will treat authenticators sent to unprotected resources. In the servlet profile of jsr 196, the the configured authentication system is called on every request, leaving it up to it, to decide whether or not to process a received authenticator.

Comment by arjan tijms [ 09/Feb/13 08:04 PM ]

In the servlet profile of jsr 196, the configured authentication system is called on every request, leaving it up to it, to decide whether or not to process a received authenticator.

Ron, is this tested in the TCK? At least JBoss EAP and AS don't do this at all, yet they are certified for Java EE 6.

Comment by arjan tijms [ 11/Feb/13 11:01 PM ]

Doing some more digging in the JBoss code, I found an optional "valve" (it's not documented), via which JBoss EAP/AS do process unprotected resources as well. It has an interesting comment:

/**
 * <p>
 * This class implements a JASPI authenticator for unprotected resources. In the JASPI Servlet profile, authentication
 * for unprotected resources is optional but it is still allowed. When performed, the JASPI authentication modules must
 * grant access to the unprotected resources irrespective of the caller, which may be anonymous (i.e, no security info
 * supplied).
 * </p>
 *
 * @author <a href="mailto:sguilhen@redhat.com">Stefan Guilhen</a>
 */
@SuppressWarnings("unused")
public class WebJASPIOptionalAuthenticator extends ValveBase {

(see http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.as/jboss-as-web/7.1.2.Final/org/jboss/as/web/security/jaspi/WebJASPIOptionalAuthenticator.java#WebJASPIOptionalAuthenticator)

I couldn't really find a spec reference that says authentication for unprotected resources is optional.

Comment by monzillo [ 11/Feb/13 11:24 PM ]

Arjan, You are correct that the Servlet profile of jsrs 196 requires that ServerAuthContex#validateRequest be called on every request that satisfies the connection requirements (i.e., any user-data-constraint). Other than the above exception this includes all request urls independent of whether the resource would have been authorized prior to the the call to ValidateRequest. That said, once the validateRequest is called, the authentication module is expected to behave differently if authentication is not mandatory for the request url. This is spelled out in section 3.8. The module specific details are described in 3.8.3.1.
I will ask that the TCK add a test.

In the context of this issue in Servet, I would expect the same behavior to be required to handle "preemptive" authenticators, but as suggested by Mark, this could be limited to some specific auth mechanisms, in which case, it likely will be necessary to require the processing of an included authenticator.

Comment by markt_asf [ 12/Feb/13 09:10 AM ]

One additional point of clarification. If the user pre-emtively sends a user name and password that are not valid (user doesn't exist, wrong password, etc.) to an unprotected resource how should the container react? Should it reject the request because the credentials are invalid or should it allow the request and just ignore the credentials. I lean towards the former as I am concerned that the latter approach may open the door to brute force password cracking attempts.





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: markt_asf and Shing Wai Chan

 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 12:13 AM ]

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





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: markt_asf, monzillo and Shing Wai Chan

 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 11:11 PM ]

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 08:11 PM ]

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 08:31 PM ]

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 12:37 AM ]

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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gregwilkins, janbartel, markt_asf and Shing Wai Chan

 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 04:17 PM ]

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 10:59 PM ]

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 11:05 PM ]

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 12:46 AM ]

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 12:08 AM ]

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





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: markt_asf and Shing Wai Chan

 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 07:54 AM ]

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 05:49 PM ]

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 03:33 PM ]

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 07:10 PM ]

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-9] Make web.xml accessible prior to ServletContext initialisation Created: 06/Sep/11  Updated: 22/Feb/13

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

Type: New Feature Priority: Major
Reporter: bleathem Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE
Participants: bleathem, rojkov and Shing Wai Chan

 Description   

It would be useful if one could access the contents of the web.xml file, prior to the ServletContext being available.

A use case for this is in writing CDI extensions, where it would be useful to access web.xml configuration data. Currently this is not possible to achieve in a portable way, as the ServletContext has not yet started, and is not available to CDI extensions (in EE environments at least).

Since the WEB-INF folder is not on the classpath, using the context ClassLoader is not possible. Perhaps the solution to this is as simple as adding the WEB-INF folder to the application classpath?



 Comments   
Comment by rojkov [ 07/Dec/11 02:38 AM ]

I think this needs a use case. I can't not suggest that parsing web.xml yet another time should be avoided. Possibly, we can define a pre-start phase that makes the xml available in parsed state.

Comment by bleathem [ 07/Dec/11 07:38 AM ]

A use case is as I stated in the issue description, where one wants to access the web.xml from a CDI extension. For instance, to determine the JSF project stage, to conditionally activate different beans in production and development.

Comment by Shing Wai Chan [ 08/Jan/13 10:18 PM ]

At this time, we don't expose the content of web.xml in Servlet API.
Where do you want to access the information contained in the descriptor and how can we reconcile the information specified by annotation?
It will be consider in the future release.

Comment by Shing Wai Chan [ 22/Feb/13 10:28 PM ]

Adding it to the bucket of FUTURE_RELEASE





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Shing Wai Chan

 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 06:28 PM ]

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 12:52 AM ]

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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gregwilkins, markt_asf, Rajiv Mordani, rstoyanchev and Shing Wai Chan

 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 05:51 AM ]

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 07:52 PM ]

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 12:05 AM ]

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 12:56 AM ]

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 06:18 AM ]

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 07:17 PM ]

Need further investigation on request issuee.

Comment by markt_asf [ 30/Jan/12 07:31 PM ]

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 01:40 AM ]

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 01:13 AM ]

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 10:49 PM ]

@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 02:06 AM ]

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 12:33 AM ]

@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 01:44 PM ]

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 01:44 PM ]

Update title

Comment by Rajiv Mordani [ 12/Dec/12 12:32 AM ]

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 06:27 PM ]

Per discussion in expert group discussion, 12/11/12, 1/9/13, 2/4/13, ISE will be thrown in this 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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Shing Wai Chan

 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 10:30 PM ]

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 08:02 PM ]

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 09:27 PM ]

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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Shing Wai Chan

 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 11:13 PM ]

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 08:01 PM ]

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 11:22 PM ]

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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Shing Wai Chan

 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 07:58 PM ]

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.





[SAILFIN-1763] Content-Language header is empty Created: 08/May/09  Updated: 04/Aug/09  Resolved: 04/Aug/09

Status: Resolved
Project: sailfin
Component/s: sip_container
Affects Version/s: 2.0
Fix Version/s: b27

Type: Bug Priority: Major
Reporter: yule_jie Assignee: jluehe
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


File Attachments: File SimpleHTTPServlet-ear-1.0.ear    
Issuezilla Id: 1,763
Tags:
Participants: ehsroha, jluehe, Shing Wai Chan and yule_jie

 Description   

When a payload or cluster is reloaded, Tibsim always get the following response
from SGCS/MMAS after a request from each payload:
(After this first request/reply, everything is answered 200 OK)

<HTTP/1.1 404 Not Found
X-Powered-By: Servlet/2.5
Server: Sun GlassFish Communications Server 1.0
Content-Type: text/html
Content-Language:
Content-Length: 1024
Date: Wed, 08 Oct 2008 13:21:36 GMT

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html><head><title>Sun
GlassFish Communications Server 1.0 - Error report</title><style
type="text/css"><!--H1

{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}

H2

{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}

H3

{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}

BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P
{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A
{color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status
404 - </h1><hr/><p><b>type</b> Status
report</p><p><b>message</b></p><p><b>description</b>The requested resource () is
not available.</p><hr/><h3>Sun GlassFish Communications Server
1.0</h3></body></html>>

15:21:36.646014 DEBUG XCAP_Functions.ttcn:1445 method_name: <HTTP/1.1>

As you can see, the Content-Language header is empty.

According RFC2616 chapter 14.12, http://www.ietf.org/rfc/rfc2616.txt,
Content-Language header must contain a value, or a * for accepting everything.



 Comments   
Comment by ehsroha [ 10/Jun/09 07:39 AM ]

Reassign to Sankar

Comment by yule_jie [ 10/Jun/09 07:48 AM ]

Created an attachment (id=1031)
Simple Http Servlet

Comment by yule_jie [ 10/Jun/09 07:50 AM ]

There is no function test testing this now.

I have attached an servlet to this issue to help reproduce the problem.

Comment by jluehe [ 04/Aug/09 01:56 PM ]

...

Comment by jluehe [ 04/Aug/09 02:26 PM ]

Suppress Content-Language response header if language is null or empty:

Index: java/com/sun/enterprise/web/connector/grizzly/DefaultProcessorTask.java
===================================================================
RCS file:
/cvs/glassfish/appserv-http-engine/src/java/com/sun/enterprise/web/connector/grizzly/DefaultProcessorTask.java,v
retrieving revision 1.16.2.10
diff -u -r1.16.2.10 DefaultProcessorTask.java
— java/com/sun/enterprise/web/connector/grizzly/DefaultProcessorTask.java
15 Jul 2009 18:29:57 -0000 1.16.2.10
+++ java/com/sun/enterprise/web/connector/grizzly/DefaultProcessorTask.java
4 Aug 2009 21:24:30 -0000
@@ -1452,7 +1452,7 @@
}

String contentLanguage = response.getContentLanguage();

  • if (contentLanguage != null) {
    + if (contentLanguage != null && !"".equals(contentLanguage)) { headers.setValue("Content-Language") .setString(contentLanguage); }

Checking in java/com/sun/enterprise/web/connector/grizzly/DefaultProcessorTask.java;
/cvs/glassfish/appserv-http-engine/src/java/com/sun/enterprise/web/connector/grizzly/DefaultProcessorTask.java,v
<-- DefaultProcessorTask.java
new revision: 1.16.2.11; previous revision: 1.16.2.10
done

Comment by Shing Wai Chan [ 04/Aug/09 03:33 PM ]

The same fixes have been applied to Grizzly.
Sending
extras/grizzly1.0/src/main/java/com/sun/enterprise/web/connector/grizzly/DefaultProcessorTask.java
Sending modules/http/src/main/java/com/sun/grizzly/http/ProcessorTask.java
Transmitting file data ..
Committed revision 3492.





[JAVASERVERFACES-2844] ADF Essentials application (ADF Faces, EJB, JPA) fails intermittently in any browser, works ok in Weblogic Created: 10/Apr/13  Updated: 07/Nov/13  Resolved: 07/Nov/13

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: westend Assignee: Ed Burns
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, 64 bits. Java EE 6 SDK Update 4 with JDK 7 (with Glassfish 3.1.2.2). JDeveloper 11.1.2.3


Tags: ADF adf lifecycle session
Participants: Ed Burns, Hong Zhang, Manfred Riem, Shing Wai Chan and westend

 Description   

Hello,

I have an ADF application developed using ADF Faces, EJB, JPA, in Jdeveloper 11.1.2.3. It works perfectly in the integrated Weblogic.

Then I make the changes in the application, following de recommended steps in http://docs.oracle.com/cd/E35521_01/web.111230/e16182/toc.htm, to deploy it in GlassFish Server v3.1.2.2. with ADF Essentials.

But when executing the application I get the following error intermittently in any browser, getting the following text in the browser:

HTTP Status 500 - ADF_FACES-30179:For more information, please see the server's error log for an entry beginning with: The UIViewRoot is null.
Fatal exception during PhaseId: RESTORE_VIEW 1.
--------------------------------------------------------------------------------

type Status report

messageADF_FACES-30179:For more information, please see the server's error log for an entry beginning with: The UIViewRoot is null.
Fatal exception during PhaseId: RESTORE_VIEW 1.

descriptionThe server encountered an internal error (ADF_FACES-30179:For more information, please see the server's error log for an entry beginning with: The UIViewRoot is null.
Fatal exception during PhaseId: RESTORE_VIEW 1.) that prevented it from fulfilling this request.
--------------------------------------------------------------------------------

GlassFish Server Open Source Edition 3.1.2.2

There seems to be a problem with the session in which it is in a non-closed state but then it contains nothing. Any ideas on what is going on? Any fixes?

Many thanks!!

and in the server log file:
[#|2013-04-10T10:57:38.167+0100|WARNING|glassfish3.1.2|oracle.adfinternal.view.faces.context.RichExceptionHandler|_ThreadID=89;_ThreadName=Thread-2;|ADF_FACES-60098:Faces lifecycle receives unhandled exceptions in phase RESTORE_VIEW 1
oracle.adf.controller.ControllerException: ADFC-00008: Failed to find DataControlFrame for a task flow.
+ at oracle.adfinternal.controller.util.Utils.createAndLogControllerException(Utils.java:212)+
+ at oracle.adfinternal.controller.util.model.DCFrameImpl.makeCurrent(DCFrameImpl.java:137)+
+ at oracle.adfinternal.controller.state.ViewPortContextImpl.makeCurrent(ViewPortContextImpl.java:1038)+
+ at oracle.adfinternal.controller.state.RequestState.setCurrentViewPortContext(RequestState.java:216)+
+ at oracle.adfinternal.controller.state.ControllerState.setRequestState(ControllerState.java:877)+
+ at oracle.adfinternal.controller.state.ControllerState.synchronizeStatePart1(ControllerState.java:376)+
+ at oracle.adfinternal.controller.application.SyncNavigationStateListener.beforePhase(SyncNavigationStateListener.java:219)+
+ at oracle.adfinternal.controller.lifecycle.ADFLifecycleImpl$PagePhaseListenerWrapper.beforePhase(ADFLifecycleImpl.java:550)+
+ at oracle.adfinternal.controller.lifecycle.LifecycleImpl.internalDispatchBeforeEvent(LifecycleImpl.java:100)+
+ at oracle.adfinternal.controller.lifecycle.LifecycleImpl.dispatchBeforePagePhaseEvent(LifecycleImpl.java:147)+
+ at oracle.adfinternal.controller.faces.lifecycle.ADFPhaseListener$PhaseInvokerImpl.dispatchBeforePagePhaseEvent(ADFPhaseListener.java:119)+
+ at oracle.adfinternal.controller.faces.lifecycle.ADFPhaseListener.beforePhase(ADFPhaseListener.java:63)+
+ at oracle.adfinternal.controller.faces.lifecycle.ADFLifecyclePhaseListener.beforePhase(ADFLifecyclePhaseListener.java:44)+
+ at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl._executePhase(LifecycleImpl.java:327)+
+ at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:202)+
+ at javax.faces.webapp.FacesServlet.service(FacesServlet.java:508)+
+ at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1550)+
+ at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)+
+ at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)+
+ at oracle.adf.model.servlet.ADFBindingFilter.doFilter(ADFBindingFilter.java:173)+
+ at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)+
+ at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)+
+ at oracle.adfinternal.view.faces.webapp.rich.RegistrationFilter.doFilter(RegistrationFilter.java:125)+
+ at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl$FilterListChain.doFilter(TrinidadFilterImpl.java:468)+
+ at oracle.adfinternal.view.faces.activedata.AdsFilter.doFilter(AdsFilter.java:60)+
+ at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl$FilterListChain.doFilter(TrinidadFilterImpl.java:468)+
+ at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:293)+
+ at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:199)+
+ at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)+
+ at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)+
+ at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)+
+ at oracle.adf.library.webapp.LibraryFilter.doFilter(LibraryFilter.java:180)+
+ at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)+
+ at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)+
+ at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)+
+ at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)+
+ at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)+
+ at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)+
+ at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)+
+ at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)+
+ at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)+
+ at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)+
+ at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)+
+ at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)+
+ at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)+
+ at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)+
+ at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)+
+ at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)+
+ at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)+
+ at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)+
+ at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)+
+ at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)+
+ at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)+
+ at com.sun.grizzly.ContextTask.run(ContextTask.java:71)+
+ at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)+
+ at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)+
+ at java.lang.Thread.run(Thread.java:722)+

#]


 Comments   
Comment by Hong Zhang [ 10/Apr/13 02:55 PM ]

As the issue talks about non-closed session, assign to web team for initial evaluation..

Comment by Shing Wai Chan [ 11/Apr/13 09:11 PM ]

Assign to JSF team.

Comment by Manfred Riem [ 12/Apr/13 09:12 PM ]

Can you send a reproducing example to issues@javaserverfaces.java.net?

Comment by westend [ 18/Apr/13 03:42 PM ]

A simple application like the JDeveloper ADF tutorial works fine.

So we are providing the ear file of the application (ftp://ftp.iac.es/out/ADFwestend/catsolar.ear). To deploy it in GlassFish it is necessary to create a JDBC Resource jdbc/catXADS that uses a valid connection pool (that responds to ping, we have used the example HR database)

Once deployed, you access it with localhost:8080/ To reproduce the error you will eventually stumble into it if you click on the language flag icon in the upper right (if you click fast enough!). Using IE you get it earlier.

If you need anything else please ask. TIA!

Comment by Manfred Riem [ 21/May/13 06:56 PM ]

Can you please try it on version 2.1.7-01?

Comment by westend [ 23/May/13 10:55 AM ]

Hi, same error, even removing the WEB-INF/lib/jsf-api.jar and WEB-INF/lib/jsf-impl.jar from the .ear that insistently get deployed with JDeveloper 1.2.4 and substituting them for the javax.faces.jar of 2.1.7-01

Comment by Manfred Riem [ 12/Aug/13 04:52 PM ]

Since this is an issue with ADF essentials have you asked them?

Comment by westend [ 19/Aug/13 12:40 PM ]

we opened an issue in the OTN forums at approximately the same time, but got no response:
https://forums.oracle.com/thread/2525044

Comment by westend [ 03/Sep/13 10:34 AM ]

I'm happy to inform that it has been solved with ADF Essentials 12.1.2 deploying on a Glassfish 3.1.2.2 from JDeveloper 12c. Thanks for the feedback!

Comment by Manfred Riem [ 07/Nov/13 04:51 PM ]

Closing as per reporter





[GRIZZLY-1463] html encoding in response reason phase Created: 14/Mar/13  Updated: 02/Apr/13  Resolved: 15/Mar/13

Status: Resolved
Project: grizzly
Component/s: http
Affects Version/s: None
Fix Version/s: 2.3, 3.0

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

Tags:
Participants: oleksiys and Shing Wai Chan

 Description   

In Grizzly 1.9.x, there is no html encoding (for instance, & -> &) in response reason phase.
In Grizzly 2.x, there is such html encoding.
This is an issue in GlassFish as it will have an encoded message as reason phase.
So, we need a way to set an encoded reason phase.



 Comments   
Comment by oleksiys [ 15/Mar/13 12:20 AM ]

fixed

HttpResponsePacket.is/setHtmlEncodingCustomReasonPhrase(...) is introduced

default value is "true"

[master]
Revision: c33e500abfdad0b7742f3aee1cf0c89d47e053fe
Date: 2013-03-14 21:56:33 UTC

[2.3.x]
Revision: b0e93c927e544b4dee8c925efe70804e099c4799
Date: 2013-03-14 21:56:33 UTC

Log Message:
------------
+ fix the issue #1463
http://java.net/jira/browse/GRIZZLY-1463
"html encoding in response reason phase"





[GRIZZLY-1452] missing API CharChunk#endsWith Created: 06/Mar/13  Updated: 02/Apr/13  Resolved: 07/Mar/13

Status: Resolved
Project: grizzly
Component/s: http
Affects Version/s: None
Fix Version/s: 2.3, 3.0

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

Tags:
Participants: oleksiys and Shing Wai Chan

 Description   

While implementing a feature in GlassFish, we need to check whether a CharChunk is ended with a given String.
CharChunk has no such API even though it has #startsWith.

Note that the CharChunk in Tomcat has the following implementation.

public boolean endsWith(String s) {
        char[] c = buff;
        int len = s.length();
        if (c == null || len > end-start) {
            return false;
        }
        int off = end - len;
        for (int i = 0; i < len; i++) {
            if (c[off++] != s.charAt(i)) {
                return false;
            }
        }
        return true;
    }


 Comments   
Comment by oleksiys [ 07/Mar/13 08:39 PM ]

fixed.

[master]
Revision: b43598334461982bb400648c240394e91be40041
Date: 2013-03-07 20:35:52 UTC

[2.3.x]
Revision: 13334561a64f7bb194cc2ae4d60ff776b71af776
Date: 2013-03-07 20:35:52 UTC

Log Message:
------------
+ implement feature #1452
http://java.net/jira/browse/GRIZZLY-1452
"missing API CharChunk#endsWith"





[GRIZZLY-1420] Need a way to configure the timeout for nonblocking IO Created: 31/Jan/13  Updated: 01/Feb/13  Resolved: 01/Feb/13

Status: Resolved
Project: grizzly
Component/s: None
Affects Version/s: None
Fix Version/s: 2.3, 3.0

Type: New Feature Priority: Major
Reporter: Shing Wai Chan Assignee: Ryan Lubke
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ryan Lubke and Shing Wai Chan

 Description   

The timeout for nonBlocking IO is 30 sec by default.
This can be configured by setter of NIOConnectionImpl.
However this is not exposed to OutputBuffer and InputBuffer.
This is needed for GlassFish integration.

Also, I notice that the above timeout is still 30 seconds even though we have "Connection: KeepAlive" header.



 Comments   
Comment by Ryan Lubke [ 01/Feb/13 08:31 PM ]

commit 281e7a3c3efdf680467f6902116a2b316c5f3e4e
Author: Ryan Lubke <ryan.lubke@oracle.com>
Date: Fri Feb 1 12:28:30 2013 -0800

With respect to GlassFish, the configuration of the timeouts can be achieved by setting either write-timeout-millis and/or read-timeout-millis on the transport element.

Comment by Ryan Lubke [ 01/Feb/13 09:30 PM ]

Port changes to master.

commit 58df60be0b978d84b755b720605a144b260c2a50
Author: Ryan Lubke <ryan.lubke@oracle.com>





[GRIZZLY-1411] Need to support replace HttpRequest Created: 16/Jan/13  Updated: 02/Apr/13  Resolved: 01/Mar/13

Status: Resolved
Project: grizzly
Component/s: http-servlet
Affects Version/s: None
Fix Version/s: 2.2.22, 2.3, 3.0

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

Tags:
Participants: oleksiys and Shing Wai Chan

 Description   

In Tomcat, one can replace the HttpRequest with the following:
1. request.getCoyoteRequest().action(ActionCode.REQ_SET_BODY_REPLAY, body);
2. request.getCoyoteRequest().getParameters().recycle();
3. request.getCoyoteRequest().getParameters().setQueryStringEncoding(
request.getConnector().getURIEncoding());

With the current implementation, the REPLAY is not supported.
Also, the Parameters is not exposed.
These two issues need to be fixed in order to implement the saving http request during form based authentication.



 Comments   
Comment by oleksiys [ 17/Jan/13 05:49 PM ]

I see this is implemented in Grizzly 1.9.x in JK connector only.
Is it still the case or you need general solution for HTTP and JK?

Comment by oleksiys [ 17/Jan/13 05:51 PM ]

and pls. give me a reference to the code, which uses that feature.

thanks.

Comment by Shing Wai Chan [ 17/Jan/13 10:27 PM ]

It will be used similar to Tomcat code
trunk/java/org/apache/catalina/authenticator/FormAuthenticator.java

Comment by oleksiys [ 01/Mar/13 05:46 PM ]

fixed

[master]
Revision: 7ebbc61ade8f2f6c2425b34d4d35501524ef7039
Date: 2013-02-22 23:52:59 UTC

[2.3.x]
Revision: 8a1fd84ea37395219a475f6723aa208d502e976f
Date: 2013-02-22 23:52:59 UTC

Log Message:
------------
+ implement feature #1411 (part #3)
http://java.net/jira/browse/GRIZZLY-1411
"Need to support replace HttpRequest"

Comment by oleksiys [ 02/Mar/13 05:41 AM ]

fixed in 2.2.x (2.2.22)

Revision: 58ad9413e789153f4fc5d34d2a8c75b23fd45b78
Date: 2013-02-22 23:52:59 UTC





[GRIZZLY-1335] org.glassfish.grizzly.http.server.Response#reset does not work properly Created: 20/Sep/12  Updated: 29/Oct/12  Resolved: 29/Oct/12

Status: Resolved
Project: grizzly
Component/s: http
Affects Version/s: None
Fix Version/s: 2.3, 3.0

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

Tags:
Participants: Ryan Lubke and Shing Wai Chan

 Description   

@WebServlet("/test")
public class TestServlet extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws IOException, ServletException { res.setContentType("text/html"); res.setCharacterEncoding("ISO-8859-1"); res.reset(); res.getWriter().println("Done"); }
}

The servlet response has the header, "Content-Type: text/html;charset=ISO-8859-1".
In this case, the reset does not clear the content-type and the charset which is part of a header.



 Comments   
Comment by Ryan Lubke [ 29/Oct/12 07:28 PM ]

Changes applied:

2.3.x: be81c18b8a2fc95b812edd080cf429339351b5a5 (already merged into GF)
master: 2b83aaede6d9ec9c724a794b4ba76225f2f05404





[GRIZZLY-1334] org.glassfish.grizzly.http.server.Response#setCharacterEncoding does not work properly Created: 20/Sep/12  Updated: 02/Apr/13  Resolved: 20/Sep/12

Status: Resolved
Project: grizzly
Component/s: http
Affects Version/s: None
Fix Version/s: 2.3, 3.0

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

Tags:
Participants: oleksiys, Ryan Lubke and Shing Wai Chan

 Description   

When we invoke
org.glassfish.grizzly.http.server.Response#setCharacterEncoding,
the Content-Type header does not have the corresponding charset.

In GlassFish env, the following servlet:
@WebServlet("/test")
public class TestServlet extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws IOException, ServletException { res.setCharacterEncoding("Big5"); res.getWriter().println("Done"); }
}

has the following response:
HTTP/1.1 200 OK
X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 4.0 Java/Apple Inc./1.6)
Server: GlassFish Server Open Source Edition 4.0
Date: Thu, 20 Sep 2012 03:54:49 GMT
Connection: close
Content-Length: 5

Done



 Comments   
Comment by Ryan Lubke [ 20/Sep/12 05:47 PM ]

Per section 5.4 of the Servlet 3.0 specification, this behavior is correct:

Note that the character encoding cannot be communicated via HTTP headers
if the servlet does not specify a content type; however, it is still used to encode text
written via the servlet response's writer.

Comment by oleksiys [ 20/Sep/12 09:47 PM ]

reopen to note the fixes we made for case, when default content-type is not null

Comment by oleksiys [ 20/Sep/12 09:49 PM ]

2.3.x:
Revision: 1648f9410273c65b524362db14b49b9b03354511
Date: 2012-09-20 21:32:49 UTC

trunk:
Revision: bb7a82066cf2b1485f68c9348cf6284d21e47f4d
Date: 2012-09-20 21:32:49 UTC

Log Message:
------------
fix issue #1334
http://java.net/jira/browse/GRIZZLY-1334
"org.glassfish.grizzly.http.server.Response#setCharacterEncoding does not work properly"
+ unittests added





[GRIZZLY-1278] ChunkedInputFilter#recycle need to clean up correctly Created: 04/Jun/12  Updated: 04/Jun/12  Resolved: 04/Jun/12

Status: Resolved
Project: grizzly
Component/s: http
Affects Version/s: 1.9.49
Fix Version/s: 1.9.50

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

Tags:
Participants: Shing Wai Chan

 Description   

Port Tomcat fix
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/filters/ChunkedInputFilter.java?r1=1342795&r2=1342794&pathrev=1342795



 Comments   
Comment by Shing Wai Chan [ 04/Jun/12 11:09 PM ]

fix in 1.9.x: 26e140aec487f3e2a11bf6e2f4459f6f8aa0841f

fix in 1.0.x: 11b795f87431e3af3746edc0b73ded8a9df69c8d





[GRIZZLY-1148] Need Grizzly support for async request / comet / web socket in cluster env Created: 09/Dec/11  Updated: 08/Apr/13  Resolved: 08/Apr/13

Status: Closed
Project: grizzly
Component/s: None
Affects Version/s: None
Fix Version/s: None

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

Tags:
Participants: Ryan Lubke and Shing Wai Chan

 Description   

Grizzly is used in GlassFish for supporting async request / comet / web socket.
In this moment, it is not limited to an instance, not in cluster env.
One can achieve this, for example, through JMS.



 Comments   
Comment by Ryan Lubke [ 08/Feb/12 07:48 PM ]

I'm afraid we're going to need more details. We won't be adding direct JMS support in Grizzly. That said, if you have some ideas for interfaces that would make your life easier implementing such a feature for GlassFish, then we can discuss that.

Either way, please provide more details as the description alone isn't enough to go on.

Comment by Shing Wai Chan [ 16/Apr/12 11:22 PM ]

There is a misunderstanding here. I am not suggesting that Grizzly should use JMS directly. I suggest that Grizzly should provide a way so that one can plug in a mechanism that can support JMS, for example.
Note JMS is only an example here. One can use other mechanism if possible.

Comment by Ryan Lubke [ 08/Apr/13 10:18 PM ]

No plans to support clustering within Grizzly.





[GRIZZLY-1133] Need to protect errors while calling error handler in ProcessorTask#doProcess Created: 29/Nov/11  Updated: 30/Nov/11  Resolved: 30/Nov/11

Status: Resolved
Project: grizzly
Component/s: http
Affects Version/s: 1.9.36
Fix Version/s: 1.9.42

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

Tags:
Participants: oleksiys and Shing Wai Chan

 Description   

In ProcessorTask#doProcess, there is a call to ErrorHandler.onParsingError.
It would be good to have error handling for this call.



 Comments   
Comment by oleksiys [ 30/Nov/11 10:00 AM ]

fixed.
Project: grizzly
Repository: git
Revision: 4c53d12005adc502068e4aae2a5f310bb887a1ad
Date: 2011-11-30 09:56:17 UTC
Link:

Log Message:
------------
+ fix issue #1133
http://java.net/jira/browse/GRIZZLY-1133
"Need to protect errors while calling error handler in ProcessorTask#doProcess"





[GLASSFISH_SAMPLES-28] async-request-war sample does not work for Safari Created: 04/Jan/10  Updated: 04/Jan/10  Resolved: 04/Jan/10

Status: Resolved
Project: glassfish-samples
Component/s: web
Affects Version/s: javaee6
Fix Version/s: milestone 1

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 28
Tags:
Participants: Shing Wai Chan

 Description   

The async-request-war sample works for IE and Firefox. It does not work for Safari.



 Comments   
Comment by Shing Wai Chan [ 04/Jan/10 02:11 PM ]

Per discussion with JeanFrancois,
http://weblogs.java.net/blog/jfarcand/archive/2009/08/25/tricks-and-tips-comet-part-1-browser-difference,
one need to write extra bytes for that.

Checking in src/java/web/servlet/async_request_war/AjaxCometServlet.java;
/cvs/glassfish-samples/ws/javaee6/web/servlet/async-request-war/src/java/web/servlet/async_request_war/AjaxCometServlet.java,v
<-- AjaxCometServlet.java
new revision: 1.7; previous revision: 1.6
done





[GLASSFISH_SAMPLES-4] ssl-jaxws-ear does not use SSL at all, although it should following it's description Created: 18/Sep/08  Updated: 25/Jan/10

Status: Open
Project: glassfish-samples
Component/s: webservices
Affects Version/s: javaee5
Fix Version/s: milestone 1

Type: Bug Priority: Minor
Reporter: kgardas Assignee: msreddy
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Solaris
Platform: Sun


Issuezilla Id: 4
Tags:
Participants: Bhakti Mehta, jagadesh, kgardas, msreddy and Shing Wai Chan

 Description   

Hello,
it seems demo webservices/ssl-jaxws-ear is not using SSL at all, although its
usage is advertised here: http://java.sun.com/javaee/reference/code/ as:
``Demonstrates the creation of a secure JAX-WS web service endpoint (https) and
accessing it using a Java application client. The service is protected at
transport level and accessed by performing SSL server-side authentication.''
Thanks for fixing this,
Karel



 Comments   
Comment by msreddy [ 02/Nov/09 11:33 AM ]

requesting Bhakti's help

Comment by Bhakti Mehta [ 03/Nov/09 12:49 PM ]

Reassigning to Shingwai who I think wrote this sample

Comment by msreddy [ 04/Nov/09 12:52 PM ]

Lowering priority considering the resources.

Comment by Shing Wai Chan [ 06/Nov/09 04:57 PM ]

I have not worked on that sample before.
According cvs log, the sample was created by msreddy.
Reassigning to msreddy for further investigation.

Comment by msreddy [ 25/Jan/10 11:38 AM ]

Requested the sample owner Jagadesh to respond.

Comment by jagadesh [ 25/Jan/10 12:20 PM ]

Hi Karel,

Have you checked the debugging steps mentioned in the sample instructions?
See the link here -
https://glassfish-samples.dev.java.net/source/browse/*checkout*/glassfish-samples/ws/javaee5/webservices/ssl-jaxws-ear/docs/index.html

Please let us know if it is not working as stated in the instructions.

Thanks.
– Jagadesh





[GLASSFISH-21043] Glassfish 4 admin gui class loading issue when built from source (as at svn revision 63170) Created: 17/Apr/14  Updated: 17/Apr/14

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 4.0.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Dave Whitla Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes
Environment:

Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 23:51:28+1000)
Maven home: /opt/local/share/java/maven3
Java version: 1.7.0_55, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_55.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: utf-8
OS name: "mac os x", version: "10.9.2", arch: "x86_64", family: "mac"


Tags: admin-gui
Participants: Anissa Lam, Dave Whitla and Shing Wai Chan

 Description   

The default domain starts without error. Attempting to access the admin application fails with the root cause being failure to locate com.sun.webui.jsf.faces.UIComponentELResolver.
The class in question exists within $INSTALL_ROOT/lib/install/applications/__admingui/WEB-INF/extra/webui-jsf-4.0.2.10.jar and was compiled using the same JDK I am using to start the container.

Root cause:

The current source for sun-web.xml in the __admingui module contains the following:

<class-loader delegate="true"
extra-class-path="WEB-INF/extra/webui-jsf-suntheme-4.0.2.10.jar
:WEB-INF/extra/dojo-ajax-nodemo-0.4.1.jar
:WEB-INF/extra/webui-jsf-4.0.2.10.jar
:WEB-INF/extra/commons-fileupload-1.1.1.jar
:WEB-INF/extra/commons-io-1.3.1.jar
:WEB-INF/extra/json-1.0.jar
:WEB-INF/extra/prototype-1.5.0.jar" />

com.sun.enterprise.glassfish.web.WarHandler.configureLoaderAttributes() does not strip whitespace characters when splitting extra-class-path into path elements.
See com.sun.enterprise.glassfish.web.WarHandler:286 for details.

Consequently at line 310:
URL url = file.toURI().toURL();

the spaces are URL encoded as %20 before passing the string to:
cloader.addRepository(url.toString());

which then silently fails to add the jar to the classpath.
Strangely addRepository(String) converts the string back to a URL before passing it (eventually) to URLClassPath.addURL(). I don't have the source for this class but it evidently doesn't like the trailing encoded whitespace characters, because after this call returns the classpath has not changed.

A patch for the issue is attached to https://www.java.net/forum/topic/glassfish/glassfish/glassfish-4-admin-console-class-loading-issue-when-built-source where the problem was first reported.



 Comments   
Comment by Dave Whitla [ 17/Apr/14 07:00 PM ]

When reviewing my changes to commit the fix (to my git clone) I noticed that the reformatting of sun-web.xml had actually been done automagically by my IDE (IntelliJ).
This explains the issue not affecting others.

While the conditions were thus self inflicted, I think this is still a latent bug.
The documentation does state that the extra-class-path consists of path elements separated by ':' or ';' with no explicit allowance for whitespace. However whitespace at the end of a path is perfectly valid and failure to handle it robustly is a future problem. Further, the root cause failure is silent in the shipped configuration, giving new users/developers no clue at all as to why their application fails to load.

Request that you apply the patch.

Comment by Anissa Lam [ 17/Apr/14 07:02 PM ]

Thanks for filing and debugging the issue.
The suspect code is in web container, I am transferring this to that team for further evaluation.
If we can't load the console, then this is very critical and we will need to upgrade this to P2 and need to be fixed for 4.0.1.





[GLASSFISH-21032] NPE if alternatedocroot_1 has from=/* Created: 07/Apr/14  Updated: 15/Apr/14

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 4.0.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: m.zdila Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish-4.0.1-b04-04_05_2014-ml
java version "1.7.0_51"
OpenJDK Runtime Environment (IcedTea 2.4.5) (7u51-2.4.5-2)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)


Tags:
Participants: m.zdila and Shing Wai Chan

 Description   

glassfish-4.0.1-b04-04_05_2014-ml

In glassfish-web.xml I have following element:
<property name="alternatedocroot_1" value="from=/* dir=/home/martin/teris-client"/>

On deploy Glassfish throws exception:

2014-04-07T16:32:31.149+0200|SEVERE: ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: org.apache.catalina.LifecycleException: start:
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5898)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2286)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1932)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:500)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
at org.glassfish.grizzly.http.server.StaticHttpHandlerBase.service(StaticHttpHandlerBase.java:189)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:215)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:291)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:209)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:137)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:115)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:550)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:744)
Caused by: org.apache.catalina.LifecycleException: start:
at org.apache.catalina.loader.WebappLoader.start(WebappLoader.java:770)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5864)
... 49 more
Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 0
at java.lang.String.charAt(String.java:658)
at org.apache.naming.resources.WebDirContext.getAbsoluteJarResourceName(WebDirContext.java:416)
at org.apache.naming.resources.WebDirContext.lookupAllFromJars(WebDirContext.java:349)
at org.apache.naming.resources.WebDirContext.list(WebDirContext.java:214)
at org.apache.catalina.loader.WebappLoader.copyDir(WebappLoader.java:1321)
at org.apache.catalina.loader.WebappLoader.setRepositories(WebappLoader.java:1116)
at org.apache.catalina.loader.WebappLoader.start(WebappLoader.java:759)
... 50 more

In Glassfish 4.0 it works.






[GLASSFISH-21026] SEVERE failure in FRESH GlassFish 4.0 installation Created: 01/Apr/14  Updated: 01/Apr/14

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: mkarg Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish 4.0 GA ZIP, Win 7 Pro SP1 (64 Bit), JDK 1.8.0 (32 Bit)


Tags:
Participants: mkarg and Shing Wai Chan

 Description   

After fresh installation of GF 4.0 I am getting the following SEVERE message in server.log.
I think it is not nice that a brand-new freshly installed GlassFish produces several of these.
It is scary for an administrator to find ANY SEVERE stuff in a freshly installed server having NO MODIFICATIONS and NO DEPLOYED APPLICATIONS.

[2014-04-01T14:40:50.083+0200] [glassfish 4.0] [SEVERE] [] [javax.enterprise.web.util] [tid: _ThreadID=184 _ThreadName=Thread-26] [timeMillis: 1396356050083] [levelValue: 1000] [[
The web application [] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@27535138]) and a value of type [org.glassfish.admingui.theme.AdminguiThemeContext] (value [org.glassfish.admingui.theme.AdminguiThemeContext@5d1efaf3]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.]]






[GLASSFISH-21015] beans.xml clear getInputStream on servlet Created: 24/Mar/14  Updated: 16/Apr/14  Resolved: 16/Apr/14

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b89_RC5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lmertins Assignee: jjsnyder83
Resolution: Works as designed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux, Java 7/8, Netbeans 7.4.1/8, glassfish 4


Tags: HttpServletRequest getInputStream
Participants: jjsnyder83, lmertins and Shing Wai Chan

 Description   

I'd like to migrate some applications (EARs) from glassfish 3.2.2.1 to 4, but I'm having some issues.
The first is lost of parameters on InputStream in ajax requests. I'm try to simulate the problem in small projects.
I find a problem if my web project have the file beans.xml in the WEB-INF. When I call getInputStream don't have information on inputstream. But don't throws excetions.
Is it normal? I have a sample project that can to show the issue. Could help? On glassfish 3 it's ok



 Comments   
Comment by Shing Wai Chan [ 25/Mar/14 12:46 AM ]

Can you attach your test case?

Comment by lmertins [ 25/Mar/14 01:40 AM ]

Sure! But I don't know how!
It's a maven project. Must I copy the code here?

Comment by Shing Wai Chan [ 25/Mar/14 08:44 AM ]

There is a "Attach file to this issue" on the left panel.

Comment by lmertins [ 25/Mar/14 11:44 AM ]

Sorry, but I don't have this option. Operations are: Go to Planning Board, Clone, Comment, sub-task, Voting, Watching and "You don't have permission to work on this issue". When I opened this issue I looked for attach file, but I didn't find.

Comment by lmertins [ 25/Mar/14 04:48 PM ]

Maybe must I put the code here?

pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>br.com.mm.site</groupId>
    <artifactId>TesteGlass4</artifactId>
    <version>1.0</version>
    <packaging>war</packaging>

    <name>TesteGlass4</name>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>
    
    <dependencies>
        <dependency>
            <groupId>javax</groupId>
            <artifactId>javaee-api</artifactId>
            <version>6.0</version>
            <scope>provided</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.1</version>
                <configuration>
                    <source>1.7</source>
                    <target>1.7</target>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-war-plugin</artifactId>
                <version>2.4</version>
                <configuration>
                    <failOnMissingWebXml>false</failOnMissingWebXml>
                </configuration>
            </plugin>
        </plugins>
    </build>

</project>
index.html
<!DOCTYPE html>
<html>
    <head>
        <title>TODO supply a title</title>
        <meta charset="UTF-8">
        <meta http-equiv="content-type" content="text/html; charset=UTF-8">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
    </head>
    <body>
        <form action="ServletTest" method="post">
            <input type="text" name="txtTeste"/>
            <input type="submit"/>
        </form>
    </body>
</html>

Exclude or rename file below to see correct job.

WEB-INF/beans.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://java.sun.com/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
</beans>

With beans.xml bufferTemp.toString() is empty. Without beans.xml, not.

jfrm.test.servlet.ServletTest.java
package jfrm.test.servlet;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.PrintWriter;
import javax.servlet.ServletException;
import javax.servlet.ServletInputStream;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@WebServlet(name = "ServletTest", urlPatterns = {"/ServletTest"})
public class ServletTest extends HttpServlet {

    @Override
    protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        resp.setContentType("text/html;charset=UTF-8");
        try (PrintWriter out = resp.getWriter()) {
            /* TODO output your page here. You may use following sample code. */
            out.println("<!DOCTYPE html>");
            out.println("<html>");
            out.println("<head>");
            out.println("<title>Servlet ServletTest</title>");
            out.println("</head>");
            out.println("<body>");
            
            ServletInputStream inputStream = req.getInputStream();
            if (inputStream != null) {
                final StringBuilder bufferTemp = new StringBuilder();
                BufferedReader bufferReader = new BufferedReader(new InputStreamReader(inputStream));
                char[] charBuffer = new char[1024];
                int bytesRead = -1;
                while ((bytesRead = bufferReader.read(charBuffer)) > 0) {
                    bufferTemp.append(charBuffer, 0, bytesRead);
                }
                out.println("<h1>");
                out.println( bufferTemp.toString());
                out.println("</h1>");
            }

            out.println("</body>");
            out.println("</html>");
        }

    }
}
Comment by Shing Wai Chan [ 25/Mar/14 06:51 PM ]

In case of CDI, Request.getParameter has been involved as follows:

java.lang.Exception: Stack trace
	at java.lang.Thread.dumpStack(Thread.java:1342)
	at org.apache.catalina.connector.Request.getParameter(Request.java:1550)
	at org.apache.catalina.connector.RequestFacade.getParameter(RequestFacade.java:448)
	at org.jboss.weld.servlet.ConversationContextActivator.getConversationId(ConversationContextActivator.java:115)
	at org.jboss.weld.servlet.ConversationContextActivator.activateConversationContext(ConversationContextActivator.java:82)
	at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:157)
	at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:108)
	at org.apache.catalina.core.StandardContext.fireRequestInitializedEvent(StandardContext.java:5257)
	at org.apache.catalina.core.StandardHostValve.preInvoke(StandardHostValve.java:655)

According to 3.1.1 of Servlet 3.1, once #getParameter is called, the parameter is not available in the inputStream. This explains what we observed.

Assign to the bug to CDI to check the spec whether it is requirement to call #getParameter.

Comment by lmertins [ 26/Mar/14 02:01 PM ]

> According to 3.1.1 of Servlet 3.1, once #getParameter is called, the parameter is not available in the inputStream. This explains what we observed.

Correct. Because of this I had to extend HttpServletRequestWrapper and which was initially detected the error in my code.

I'm curious with the Glassfish code and how it is built. I compiled the version of trunk and fathered a distribution. My reference is this link https://glassfish.java.net/public/devindex.html
Are there way to debug glassfish code? I didn't find how.

Comment by jjsnyder83 [ 16/Apr/14 06:58 PM ]

Please see: https://java.net/jira/browse/GLASSFISH-20957

It explains the problem and provides links to Weld and CDI spec that discuss the problem.





[GLASSFISH-21007] HTTP Upgrade handler init called twice when access log is turned on Created: 17/Mar/14  Updated: 19/Mar/14

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 4.0.1
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: mreichman Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 4.0.1b4 Promoted, Windows 7 x64, JDK 1.7.0_51


Issue Links:
Dependency
blocks TYRUS-306 java.lang.IllegalStateException: Alre... Open
Tags:
Participants: mreichman and Shing Wai Chan

 Description   

When HTTP access logging is turned on, the init method of HttpUpgradeHandler implementations is called twice at upgrade-time. I'd previously filed TYRUS-306 for this, the necessary information, test components to reproduce are in that ticket. In the Tyrus case, the effect is that two websockets are created for one request which creates management difficulty and potential leaks.






[GLASSFISH-20988] session replication occasionally not work on different physical machine Created: 18/Feb/14  Updated: 18/Feb/14

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: makschim Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK1.7, Glassfish 3.1.2,apache 2.4.4


Tags:
Participants: makschim and Shing Wai Chan

 Description   

I create a cluster using above mentioned enviroment. In this cluster, we have two different physical machine. We name them instance1 and instance2.
But the session replication between the two physical machine occasionally doesn't work. When the login request is sent to instance1, a session is created and the authentication information is stored in this session. When another new request for query data is forwarded by apache server to the instance2, the ssesion of instance1 is not correctly replicated from instance1. So there is no authentication information in instance2. Then the new request cannot query data from instance2.

I read before reported bugs for GF 3.1.1, and it indicates that this session replication lost bug has been fixed in GF 3.1.2. But for us, this bug is still exist. How can we fix this issue.

This is our glassfih-web.xml

<glassfish-web-app error-url="">
<context-root>/</context-root>

<session-config>
<session-manager persistence-type="replicated">
<manager-properties>
<property name="persistenceFrequency" value="time-based"/>
<property name="reapIntervalSeconds" value="30"/>
<property name="relaxCacheVersionSemantics" value="true"/>
</manager-properties>
<store-properties>
<property name="persistenceScope" value="session"/>
</store-properties>
</session-manager>
</session-config>
</glassfish-web-app>






[GLASSFISH-20980] Convert private JDK API usage to new public equivalent (web container) Created: 11/Feb/14  Updated: 13/Feb/14  Resolved: 13/Feb/14

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: None
Fix Version/s: 4.0.1

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

Issue Links:
Dependency
blocks GLASSFISH-19812 Prevent usage of proprietary API" war... Open
Tags:
Participants: Romain Grécourt, Shing Wai Chan and Tim Quinn

 Description   

Some time ago the JDK team provided a private entry point sun.misc.ClassLoaderUtil.releaseLoader for cleaning up open JARs held by a class loader.

The JDK team would like to remove this private method in JDK 9 given that JDK 7 provides the equivalent URLClassLoader.close method.

Currently the only place in GlassFish where grep finds sun.misc.ClassLoaderUtil is

main/appserver/web/war-util/src/main/java/org/glassfish/web/loader/WebappClassLoader.java



 Comments   
Comment by Romain Grécourt [ 13/Feb/14 03:47 PM ]

Tim, you may also want to look at GLASSFISH-19812, it's an umbrella issue for all the private APIs reported by javac during the build.

Comment by Tim Quinn [ 13/Feb/14 04:15 PM ]

Add "web container" to the title

Comment by Shing Wai Chan [ 13/Feb/14 08:55 PM ]

Sending src/main/java/org/glassfish/web/loader/WebappClassLoader.java
Transmitting file data .
Committed revision 63126.





[GLASSFISH-20933] When the session is newly made by asynchronization Servlet, the time-outis not done while locked Created: 18/Dec/13  Updated: 18/Dec/13

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 4.0.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: xianwu Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS
Windows 7 Enterprise (Service Pack 1)

JDK
java version "1.7.0_11"
Java(TM) SE Runtime Environment (build 1.7.0_11-b21) Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode)

GlassFish build: glassfish-4.0.1-b02-07_22_2013


Tags:
Participants: Shing Wai Chan and xianwu

 Description   

We have a web application atest2.war, which contains two servlets: "simple" and "test".
"simple" is a non-async servlet and "test" is an async servlet.
The session time out was set to 1 minute in web.xml

When accessing non-async servlet "/simple", a session was created, then destroyed when time out was reached

However, when accessing async servlet "/test", a session was created but not destroyed time out was reached.

Reproducible operational steps:

1) deploy atest2.war
asadmin deploy c:\tmp\atest2.war
Application deployed with name atest2.
Command deploy executed successfully.

2) access non-async servlet
http://localhost:8080/atest2/simple

The lifecycle of the session can be confirmed in the server.log. The session (2d5e8779e02499f08d42ea52cd0a)was created then destroyed when time out was reached.

[2013-12-18T10:13:29.719+1100] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=106 _ThreadName=Thread-7] [timeMillis: 1387322009719] [levelValue: 800] [[
SessionCreated: 2d5e8779e02499f08d42ea52cd0a]]

[2013-12-18T10:14:52.990+1100] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=147 _ThreadName=Thread-7] [timeMillis: 1387322092990] [levelValue: 800] [[
SessionDestroyed: 2d5e8779e02499f08d42ea52cd0a]]

3) access async servlet
http://localhost:8080/atest2/test

The lifecycle of the session can be confirmed in the server.log. The session (2f028ea7bf9fc3aa8c6680ed196e)was created but it was not destroyed when time out (about 1 minute) was reached.

[2013-12-18T10:42:10.154+1100] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=180 _ThreadName=Thread-7] [timeMillis: 1387323730154] [levelValue: 800] [[
SessionCreated: 2f028ea7bf9fc3aa8c6680ed196e]]

[2013-12-18T10:42:10.154+1100] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=180 _ThreadName=Thread-7] [timeMillis: 1387323730154] [levelValue: 800] [[
AsyncHandler#onComplete]]

4) stop domain to stop the process of async servlet
asadmin stop-domain domain1
Waiting for the domain to stop .
Command stop-domain executed successfully.

When the server was shutdown, then, the session of async servlet (2f028ea7bf9fc3aa8c6680ed196e) was destroyed.

[2013-12-18T10:47:25.246+1100] [glassfish 4.0] [INFO] [NCLS-CORE-00092] [javax.enterprise.system.core] [tid: _ThreadID=182 _ThreadName=Thread-35] [timeMillis: 1387324045246] [levelValue: 800] [[
Server shutdown initiated]]

[2013-12-18T10:47:25.246+1100] [glassfish 4.0] [INFO] [NCLS-BOOTSTRAP-00028] [javax.enterprise.bootstrap] [tid: _ThreadID=182 _ThreadName=Thread-35] [timeMillis: 1387324045246] [levelValue: 800] [[
Unregistered com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl@658f8f43 from service registry.]]

[2013-12-18T10:47:25.246+1100] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=182 _ThreadName=Thread-7] [timeMillis: 1387324045246] [levelValue: 800] [[
FileMonitoring shutdown]]

[2013-12-18T10:47:25.246+1100] [glassfish 4.0] [INFO] [NCLS-JMX-00002] [javax.enterprise.system.jmx] [tid: _ThreadID=182 _ThreadName=Thread-35] [timeMillis: 1387324045246] [levelValue: 800] [[
JMXStartupService: Stopped JMXConnectorServer: null]]

[2013-12-18T10:47:25.246+1100] [glassfish 4.0] [INFO] [NCLS-JMX-00001] [javax.enterprise.system.jmx] [tid: _ThreadID=182 _ThreadName=Thread-35] [timeMillis: 1387324045246] [levelValue: 800] [[
JMXStartupService and JMXConnectors have been shut down.]]

[2013-12-18T10:47:25.277+1100] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=186 _ThreadName=Thread-7] [timeMillis: 1387324045277] [levelValue: 800] [[
SessionDestroyed: 2f028ea7bf9fc3aa8c6680ed196e]]



 Comments   
Comment by xianwu [ 18/Dec/13 12:16 AM ]

I have uploaded the sample application atest.war at

https://www.dropbox.com/s/x5tbo5yqca9whrg/atest2.war





[GLASSFISH-20932] Error occurs when default-web-module is set. Created: 17/Dec/13  Updated: 24/Jan/14

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 4.0.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: xianwu Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS
Windows 7 Enterprise (Service Pack 1)

JDK
java version "1.7.0_11"
Java(TM) SE Runtime Environment (build 1.7.0_11-b21) Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode)

GlassFish build: glassfish-4.0.1-b02-07_22_2013


Tags:
Participants: jifeng, Shing Wai Chan and xianwu

 Description   

Reproducible operational steps:

1) deploy a web application e.g. HelloServlet.war
asadmin deploy c:\tmp\HelloServlet.war
Application deployed with name HelloServlet.
Command deploy executed successfully.

2) set default-web-module to HelloServlet
asadmin set server.http-service.virtual-server.server.default-web-module=HelloServlet
server.http-service.virtual-server.server.default-web-module=HelloServlet
Command set executed successfully.

3) set http-listener-1.http.max-post-size-bytes
asadmin set server.network-config.protocols.protocol.http-listener-1.http.max-post-size-bytes=2000
server.network-config.protocols.protocol.http-listener-1.http.max-post-size-bytes=2000
Command set executed successfully.

4) error occurs in server.log

[2013-12-17T16:29:08.916+1100] [glassfish 4.0] [SEVERE] [AS-WEB-GLUE-00115] [javax.enterprise.web] [tid: _ThreadID=145 _ThreadName=pool-50-thread-1] [timeMillis: 1387258148916] [levelValue: 1000] [[
Exception processing HttpService configuration change
org.apache.catalina.LifecycleException: java.lang.Exception: No context matching /HelloServlet deployed on virtual server server
at com.sun.enterprise.web.WebContainer.updateDefaultWebModule(WebContainer.java:2340)
at com.sun.enterprise.web.WebContainer.updateHost(WebContainer.java:3157)
at com.sun.enterprise.web.reconfig.WebConfigListener$1.changed(WebConfigListener.java:156)
at org.jvnet.hk2.config.ConfigSupport.sortAndDispatch(ConfigSupport.java:331)
at com.sun.enterprise.web.reconfig.WebConfigListener.changed(WebConfigListener.java:132)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:400)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:390)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:280)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:278)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.Exception: No context matching /HelloServlet deployed on virtual server server
at org.glassfish.grizzly.http.server.util.Mapper.addDefaultContext(Mapper.java:791)
at org.glassfish.grizzly.http.server.util.Mapper.setDefaultContextPath(Mapper.java:755)
at com.sun.enterprise.web.WebContainer.updateDefaultWebModule(WebContainer.java:2332)
... 13 more
]]

5) get http-listener-1.http.max-post-size-bytes
asadmin get server.network-config.protocols.protocol.http-listener-1.http.max-post-size-bytes
server.network-config.protocols.protocol.http-listener-1.http.max-post-size-bytes=2000
Command get executed successfully.



 Comments   
Comment by jifeng [ 13/Jan/14 11:12 AM ]

Hi
Shing Wai Chan
xianwu

After a few investigation about the source, I found the exact precise place where the failure happens:

org.glassfish.grizzly.http.server.util.Mapper
private void addDefaultContext(Host host, String defaultContextPath)
            throws Exception {

        boolean defaultContextFound = false;

        Context[] contexts = host.contextList.contexts;

        if (contexts != null) {
            for (Context context1 : contexts) {
                if (context1.name.equals(defaultContextPath)) {
                    host.defaultContexts[0] = context1;
                    defaultContextFound = true;
                    break;
                }
            }
        }

        if (!defaultContextFound) {
            throw new Exception("No context matching " + defaultContextPath
                                + " deployed on virtual server "
                                + host.name);★
        }
    }

I have debuged the 'Mapper' class and found the [context.name] object has never been valued。

The [context.name] object's initialization processing as follows:

package com.sun.enterprise.v3.services.impl.ContainerMapper
private final static String ROOT = "";★
protected void configureMapper() {
    ......
    try {
    ....
         mapper.addContext(defaultHostName, ROOT★,
                    new ContextRootInfo(this, null),
                    new String[]{"index.html", "index.htm"}, null);
    ....
        } finally {
            mapperLock.writeLock().unlock();
        }
}

org.glassfish.grizzly.http.server.util.Mapper
public void addContext
            (String hostName, String path★, Object context,
            String[] welcomeResources, NamingContext resources,
            List<AlternateDocBase> alternateDocBases) {
    ......
    newContext.name = path;★//the [context.name] object's 
                             //value always equals to ""
    ......
 }
Comment by jifeng [ 24/Jan/14 07:25 AM ]

Hi
Shing Wai Chan
xianwu

I modify the following code, it works fine,could you please confirm it and give me some suggestions?

package com.sun.enterprise.v3.services.impl.ContainerMapper
@@ -69,6 +69,8 @@
 import org.glassfish.grizzly.http.util.MimeType;
 import org.glassfish.internal.grizzly.ContextMapper;
 import org.glassfish.kernel.KernelLoggerInfo;
+import com.sun.enterprise.config.serverbeans.ConfigBeansUtilities;
+import com.sun.enterprise.config.serverbeans.VirtualServer;
 
 /**
  * Container's mapper which maps {@link ByteBuffer} bytes representation to an  {@link HttpHandler}, {@link
@@ -148,7 +150,7 @@
         try {
             mapper.setDefaultHostName(defaultHostName);
             mapper.addHost(defaultHostName, new String[]{}, null);
-            mapper.addContext(defaultHostName, ROOT,
+            mapper.addContext(defaultHostName, getContextRoot(),
                     new ContextRootInfo(this, null),
                     new String[]{"index.html", "index.htm"}, null);
             // Container deployed have the right to override the default setting.
@@ -157,7 +159,29 @@
             mapperLock.writeLock().unlock();
         }
     }
-
+    
+    private String getContextRoot() {
+        String defaultWebModule = null;
+        String contextRoot = null;
+        Collection<VirtualServer> list = grizzlyService.getHabitat().getAllServices(VirtualServer.class);
+        ConfigBeansUtilities cbu = grizzlyService.getHabitat().getService(ConfigBeansUtilities.class);
+        for (VirtualServer virtualServer : list) {
+            if (virtualServer.getId().equals(defaultHostName)) {
+                defaultWebModule = virtualServer.getDefaultWebModule();
+                if (cbu == null) {
+                    contextRoot = null;
+                }
+                else {
+                    if (defaultWebModule != null) {
+                        contextRoot = cbu.getContextRoot(defaultWebModule);
+                    }
+                }
+                break;
+            }
+        }
+        return contextRoot == null ?ROOT:contextRoot;
+    }
+




[GLASSFISH-20917] a wrong implementation for web-fragment.xml with <distributable/> issue Created: 06/Dec/13  Updated: 15/Apr/14

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jumperchen Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

fail with both Glassfish 3 and 4 version


Tags:
Participants: jumperchen and Shing Wai Chan

 Description   

If a web application contains with a jar (for example Spring 3.2.2 version) that enables the attribute <distributable/> in the web-fragment.xml, this setting will cause glassfish server run in cluster environment.

You may refer to this fixed in Spring's tracker - https://jira.springsource.org/browse/SPR-10219

To reproduce this issue is to save a non-serializable object to session attribute, for example

<%
   session.setAttribute( "test", new java.io.ByteArrayOutputStream(20) );
%>

Note that the web.xml doesn't specify the <distributable/>.






[GLASSFISH-20916] Terminating Browser Leaves Open/Lingering WebSockets Created: 05/Dec/13  Updated: 09/Dec/13

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: kag0782 Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 32bit


Tags: websockets
Participants: kag0782, Pavel Bucek and Shing Wai Chan

 Description   

If a browser that has opened a websocket is killed (not closed, but terminated abruptly), the websocket connection on the server is still considered "open" (i.e. onClose is not called on the endpoint), and still allows data to be written to the session without exceptions being thrown.

Example:

@ServerEndpoint("/test")
@WebServlet(urlPatterns={"/connections"})
public class Test extends HttpServlet {

    private static final HashSet<Session> sessions = new HashSet<Session>();

    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        resp.getWriter().print(sessions.size());
    }

    @OnOpen
    public void onOpen(Session session, EndpointConfig config) {
        sessions.add(session);
    }
    
    @OnClose
    public void onClose(Session session, CloseReason reason) {
        sessions.remove(session);
    }
    
}

Establishing a websocket connection to /test above will cause the /connections servlet to respond with "1". If the browser is terminated, /connections will still return "1". If another websocket connection to /test is made, then /connections will show "2". This is leading to a memory leak.



 Comments   
Comment by Pavel Bucek [ 06/Dec/13 08:32 AM ]

are you sure that @OnClose is not ever called? (It probably might take some time, since it looks that underlying TCP connection is not properly closed - it will need to hit some idle timeout).

There is not much we can do in Tyrus (WebSocket RI) to improve this - we do rely on Servlet's mechanism to report us that connection has been closed and if that don't happens, the connection is considered to be open. Furthermore, the fact that you are able to write the data to the session means that the TCP connection is still open.

You can try to reproduce jt by using just plain Servlet API (HttpUpgradeHandler#destroy should be called when client disconects) and then maybe file a bug against it..

Comment by kag0782 [ 07/Dec/13 01:03 AM ]

Thank you. Destroy is apparently only ever called when the WebConnection object is closed; which means that the web socket must be closed through the handshake method. That is not good.

Comment by kag0782 [ 07/Dec/13 11:33 AM ]

I reproduced the issue using the plain servlet API as you said. The servlet does indeed instruct the handler that the connection was closed; however, it is not done through the destroy method, but rather through the ServletInputStream of the WebConnection object as given to the HttpUpgradeHandler. When the socket is closed, the ReadListener's onDataAvailable method is called indicating some data has arrived. When the input stream is then read from it throws a EOFException. This should instruct the web socket implementation to forcibly close the connection by calling close on the WebConnection (and incidentally the @OnClose method of the endpoint). This in turn calls the destroy method on the HttpUpgradeHandler.

Here is my example:

@WebServlet(urlPatterns={"/test5"})
public class UpgradeTest extends HttpServlet implements HttpUpgradeHandler {

    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        try {
            MessageDigest cipher = MessageDigest.getInstance("SHA-1");
            cipher.reset();
            cipher.update((req.getHeader("sec-websocket-key") + "258EAFA5-E914-47DA-95CA-C5AB0DC85B11").getBytes());
            resp.setHeader("Sec-Websocket-Accept", new BASE64Encoder().encode(cipher.digest()));
            resp.setHeader("Upgrade", "websocket");
            resp.setHeader("Connection", "Upgrade");
            resp.setStatus(101);
            resp.flushBuffer();
            req.upgrade(UpgradeTest.class);
        } catch (Exception e) {
        }
    }
    
    public void destroy() {
        System.err.println("Destroyed");
    }
    
    public void init(final WebConnection wc) {
        System.err.println("Initialized");
        try {
            R r = new R(wc.getInputStream());
            wc.getInputStream().setReadListener(r);
            wc.getOutputStream().setWriteListener(r);
        } catch (IOException e) {
        }
    }
    
    public static class R implements ReadListener, WriteListener {
        private final ServletInputStream i;
        
        public R(ServletInputStream i) {
            this.i = i;
        }
        
        public void onAllDataRead() {
            System.err.println("All data read");
        }

        public void onDataAvailable() {
            System.err.println("Data available");
            try {
                System.err.println(i.readLine(new byte[1000], 0, 1000));
            } catch (IOException e) {
                e.printStackTrace();
            }
        }

        public void onError(Throwable t) {
            t.printStackTrace();
        }

        public void onWritePossible() {
            System.err.println("Write possible");
        }
    }
    
}
Comment by Pavel Bucek [ 09/Dec/13 02:32 PM ]

I cannot reproduce it on my Mac. I guess this might be platform related issue.

.. anyway, this is not related to Tyrus, it is more Servlet issue from my point of view. Reassigning to Servlet group for further evaluation.





[GLASSFISH-20884] Does not full fit the javax.servlet.ServletContainerInitializer's functions Created: 07/Nov/13  Updated: 07/Nov/13

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: chafer Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour

Tags:
Participants: chafer and Shing Wai Chan

 Description   

The interface javax.servlet.ServletContainerInitializer has declared that "Implementations of this interface may be annotated with HandlesTypes, in order to receive (at their onStartup(java.util.Set>, javax.servlet.ServletContext) method) the Set of application classes that implement, extend, or have been annotated with the class types specified by the annotation. "
While, when I define an interface A as IA,an interface B as IB which extends IA,and a class C implements IB, the HandlesTypes annotation declared to receive IA classes, the onStartup method does receive the class C.






[GLASSFISH-20872] Update DefaultServlet to leverage non-blocking APIs added in Servlet 3.1. Created: 24/Oct/13  Updated: 24/Oct/13

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 4.0
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Ryan Lubke Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ryan Lubke and Shing Wai Chan

 Description   

Per the summary.






[GLASSFISH-20868] Alternate Docroot does not work as server property Created: 23/Oct/13  Updated: 23/Oct/13

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 4.0_b89_RC5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: UncleMoose Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu(64) jdk1.7.0_17 non-clustered


Tags:
Participants: Shing Wai Chan and UncleMoose

 Description   

Glassfish 4 build 89 jdk1.7 Ubuntu::
Server property: alternatedocroot_1 from=/exports/* dir=/apps/myApp
"166.34.148.150" "NULL-AUTH-USER" "22/Oct/2013:15:04:56 -0700" "GET /exports HTTP/1.1" 404 1082
Expected results is a directory listing

Glassfish 3.1.1 (build 12) clustered, jdk1.6, Solaris::
Does not work as server configuration or application property.
Server property results in 404.
Application property results in Invalid alternate_docroot from=/exports/* dir=/apps/myApp

Works in glassfish 2.1.1 on Solaris jdk1.5 in clustered environment

Does not matter how many times the cluster and server is bounced.



 Comments   
Comment by Shing Wai Chan [ 23/Oct/13 06:55 PM ]

There is no support for directory listing for alternated docroot.
http://docs.oracle.com/cd/E19798-01/821-1752/geqpl/index.html

Comment by UncleMoose [ 23/Oct/13 07:42 PM ]

So how do you get this added back? It works in version 2.1.1?





[GLASSFISH-20849] "maxHistoryFile" is not honored if "GFFileHandler.file" does not point to default location in logging.properties Created: 11/Oct/13  Updated: 26/Feb/14

Status: Open
Project: glassfish
Component/s: None
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: bhuvangu Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RedHat 6, glassfish v3.1.2.2


Tags: logging
Participants: bhuvangu and Shing Wai Chan

 Description   

In "logging.properties" under "domains/mydomain/config"
If i change
com.sun.enterprise.server.logging.GFFileHandler.file=/TO/MY/LOCATION/file.log

then i can see log getting created, but
"com.sun.enterprise.server.logging.GFFileHandler.maxHistoryFiles=1"
is not honored.

If i change the
com.sun.enterprise.server.logging.GFFileHandler.file=/GF_LOCATION/domains/mydomain/logs/server.log
Then maxHistoryFiles works fine.



 Comments   
Comment by bhuvangu [ 26/Oct/13 08:13 AM ]
nucleus/core/logging/src/main/java/com/sun/enterprise/server/logging/GFFileHandler.java?rev=62871
...
private static final String LOG_FILE_NAME = "server.log";
...
public void cleanUpHistoryLogFiles() {
...
   File[] fset = dir.listFiles();
   ArrayList candidates = new ArrayList();

   for (int i = 0; fset != null && i < fset.length; i++) {

      if (!LOG_FILE_NAME.equals(fset[i].getName()) && fset[i].isFile()
         && fset[i].getName().startsWith(LOG_FILE_NAME)) {  -----This will always be false if log filename is changed in logging.properties file.

         candidates.add(fset[i].getAbsolutePath());
      }
   }
...

Here LOG_FILE_NAME always remain as "server.log" and while cleanup the if condition always fails.

Instead of using "LOG_FILE_NAME" in if condition we should use "absoluteFile.getName()"





[GLASSFISH-20788] Order ServletContainerInitializers according to web-fragment order Created: 31/Aug/13  Updated: 31/Aug/13

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1.2.2, 4.0
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Nick Williams Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: servlet-container-initializer web-fragment order
Participants: Nick Williams and Shing Wai Chan

 Description   

For context, see https://java.net/jira/browse/SERVLET_SPEC-79.

The Servlet 3.0 and 3.1 specs require no specific order for ServletContainerInitializers. This is a serious flaw in the spec, because it eliminates the ability to guarantee that certain code runs before any other code (for example, initialization of logging frameworks). In Servlet 2.5 and earlier, you could guarantee a exact ordering of startup code, but you can't do that anymore. To be clear, the spec does not prohibit the container from ordering them in a certain way, it just doesn't specify an order that should be followed.

Tomcat (confirmed), TomEE (confirmed), JBoss (confirmed), WebLogic (apparent), and WebSphere (apparent) order SCIs according to the order of the web-fragments they appear in. That way, either using <order> or <absolute-ordering>, an application can guarantee that a particular SCI will run first. GlassFish executes SCIs in the order they are returned by the ClassLoader.

I believe it would be an improvement for GlassFish and for the community as a whole if GlassFish would order SCIs according to the web-fragment order, just like the five aforementioned containers. Furthermore, since GlassFish currently copies the URL array from the ClassLoader, rips out URLs that would be excluded by the web-fragment order, then creates a NEW ClassLoader just to load SCIs using the ServiceLoader (a very clunky process, to say the least), this change would represent a major improvement to the process GlassFish uses to load SCIs, and could even improve startup performance.

Finally, I intend to lobby hard for this to be the required behavior in the Servlet 3.2 spec. If GlassFish 3 and 4 implemented this behavior, it would make the argument more compelling, and also require no changes in GlassFish 5 once Servlet 3.2 is finalized.

(FYI: I am filing similar enhancement requests for Resin and Jetty.)






[GLASSFISH-20777] Web fragment resources not found on exploded War Created: 22/Aug/13  Updated: 22/Aug/13

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1.2_b04
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: michael.friedrich Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows


Tags: exploded web-fragment war
Participants: michael.friedrich and Shing Wai Chan

 Description   

I tried to use exploded Wars with included and also exploded Web Fragments for shorter development turn arounds.
This didn't really work out because the WebappClassLoader ignores resources in META-INF/resources.
Example war directory structure:
ExplodedWar
WEB-INF
lib
WebFragment.jar(directory)
META-INF/resources
hello.html
If WebFragment.jar is packaged as Jar 'hello.html' is found fine.
Our workaround for now is to use custom javax.faces.view.facelets.ResourceResolver which first calls WebappClassLoader#getResource("META-INF/resources" + path) in Development project stage.






[GLASSFISH-20747] SessionCookieConfig#getName should return null if SessionCookieConfig#getName has not been invoked Created: 07/Aug/13  Updated: 13/Aug/13  Resolved: 13/Aug/13

Status: Resolved
Project: glassfish
Component/s: None
Affects Version/s: None
Fix Version/s: 4.0_b90

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

Tags:
Participants: Amy Roh and Shing Wai Chan

 Description   

In javadoc of SessionCookieConfig#getName of Servlet 3.0 and Servlet 3.1, we have the following:

Returns:
the cookie name set via setName(java.lang.String), or null if setName(java.lang.String) was never called

So, if SessionCookieConfig#setName has not been invoked, then SessionCookieConfig#getName should be null rather than "JSESSIONID".



 Comments   
Comment by Shing Wai Chan [ 07/Aug/13 06:13 PM ]

Sending appserver/web/web-core/src/main/java/org/apache/catalina/core/SessionCookieConfigImpl.java
Transmitting file data .
Committed revision 62457.

Comment by Shing Wai Chan [ 07/Aug/13 06:53 PM ]

fix in 4.0 branch
Sending src/main/java/org/apache/catalina/core/SessionCookieConfigImpl.java
Transmitting file data .
Committed revision 62458.

Comment by Amy Roh [ 13/Aug/13 07:13 PM ]

This fix is causing a deployment failure for Servlet TCK sessioncookieconfig.war.

[2013-08-13T02:17:44.565-0700] [glassfish 4.0] [SEVERE] [AS-WEB-CORE-00174] [javax.enterprise.web.core] [tid: _ThreadID=64 _ThreadName=AutoDeployer] [timeMillis: 1376385464565] [levelValue: 1000] [[
Startup of context /servlet_pluh_sessioncookieconfig_web failed due to previous errors]]

Caused by: java.lang.NullPointerException
at com.sun.ts.tests.servlet.api.javax_servlet_http.sessioncookieconfig.TestListener.contextInitialized(TestListener.java:74)
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:5394)
at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:743)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5932)

The failing code is looking up SessionCookieConfig#getName and is returning NULL.

SessionCookieConfig scf =
sce.getServletContext().getSessionCookieConfig();

if (!scf.getName().equals("JSESSIONID")) {

Comment by Shing Wai Chan [ 13/Aug/13 07:23 PM ]

This is a bug in CTS. I have talked to CTS team before checkin the fix. Per discussion, they are working on the fix.





[GLASSFISH-20734] Encoding mappings defined in deployment descriptor file are ignored. Created: 31/Jul/13  Updated: 06/Aug/13  Resolved: 06/Aug/13

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 4.0_b89_RC5
Fix Version/s: 4.0_b90

Type: Bug Priority: Minor
Reporter: djiao Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Solaris


Tags:
Participants: djiao and Shing Wai Chan

 Description   

When an encoding mapping is defined in deployment descriptor,

<locale-encoding-mapping-list>
<locale-encoding-mapping>
<locale>ja</locale>
<encoding>euc-jp</encoding>
</locale-encoding-mapping>
<locale-encoding-mapping>
<locale>zh_CN</locale>
<encoding>gb18030</encoding>
</locale-encoding-mapping>
</locale-encoding-mapping-list>

call
response.setLocale(Locale.JAPAN);
fails to set encoding to euc-jp.



 Comments   
Comment by Shing Wai Chan [ 06/Aug/13 07:47 PM ]

fix in trunk
Sending deployment/dol/src/main/java/com/sun/enterprise/deployment/LocaleEncodingMappingDescriptor.java
Sending web/web-glue/src/main/java/org/glassfish/web/deployment/descriptor/WebBundleDescriptorImpl.java
Sending web/web-glue/src/main/java/org/glassfish/web/deployment/node/WebCommonNode.java
Transmitting file data ...
Committed revision 62449.

Comment by Shing Wai Chan [ 06/Aug/13 08:38 PM ]

fix in 4.0 branch
Sending appserver/deployment/dol/src/main/java/com/sun/enterprise/deployment/LocaleEncodingMappingDescriptor.java
Sending appserver/web/web-glue/src/main/java/org/glassfish/web/deployment/descriptor/WebBundleDescriptorImpl.java
Sending appserver/web/web-glue/src/main/java/org/glassfish/web/deployment/node/WebCommonNode.java
Transmitting file data ...
Committed revision 62451.





[GLASSFISH-20729] ServletRequest.getLocales() and BCP47 style Language tags. Created: 26/Jul/13  Updated: 02/Oct/13

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: v2.1.1, v3.0.1, 4.0
Fix Version/s: 4.0

Type: Bug Priority: Minor
Reporter: Ed Burns Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns, Ryan Lubke and Shing Wai Chan

 Description   

If a user agent sends an Accept-Language: header with language tags that conform to BCP47 <http://tools.ietf.org/html/bcp47>, the current implementation of ServletRequest.getLocales() may not behave correctly. This is because additional actions must be taken with new methods in the java.util.Locale API added in JavaSE 7.

For more on this issue see bugdb bug 14676641.



 Comments   
Comment by Ed Burns [ 29/Jul/13 01:47 PM ]

>>>>> On Fri, 26 Jul 2013 12:27:47 -0700, Blake Sullivan said:

B> The correct thing to do in Java 7 is to create the correct locale by
B> calling Locale, forLanguageTag() on each locale passed in (which is
B> one of the reasons for preserving the BCP locales) and fixing your
B> locale matching code to take the scripts into account (the scripts
B> are more important than the territories, which is why they appear
B> after the languages in the BCP locales). The Locale code in Java7
B> should make the comparisons you want work correctly because I believe
B> that "zh-TW" will be turned into "zh-Hant-TW. Therefore a request
B> for "zh-Hant" will match "zh-Hant-TW", which is what you want.

Comment by Shing Wai Chan [ 07/Aug/13 06:58 PM ]

In GlassFish, ServletRequest.getLocale has delegated to Grizzly which is in JDK 6.
We can override that in GlassFish if necessary. Let me do further investigation.

Comment by Ryan Lubke [ 09/Aug/13 08:39 PM ]

Fixed in Grizzly 2.3.5 (not yet released) under https://java.net/jira/browse/GRIZZLY-1570 .

Comment by Ed Burns [ 02/Oct/13 03:32 PM ]

Because this is fixed in GRIZZLY-1570, can we close this issue?

Comment by Shing Wai Chan [ 02/Oct/13 06:37 PM ]

The trunk is in Grizzly 2.3.3, not even Grizzly 2.3.4. That is why I have not closed the issue yet.





[GLASSFISH-20720] EAR deployment with multiple embedded WARs broken in 3.1.2.2 and 4.0 Created: 22/Jul/13  Updated: 09/Jan/14

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1, 4.0_b89_RC5
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: nabizamani Assignee: kchung
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RedHat Linux, Windows, Ubuntu Linux


File Attachments: File TestApp.ear     File TestApp.ear    
Tags: 3_1-next 3_1_1-scrubbed 3_1_2-exclude metro2_2-waived
Participants: kchung, Lukas Jungmann, nabizamani, pbelbin, replicant77, Shing Wai Chan and TangYong

 Description   

We are trying to upgrade to 3.1. Our application is packaged and deployed as an EAR file with multiple EJB and WARs embedded. Some of the WAR files have web services for deployment, and some do not. The 3.1 deployment mechanism is fundamentally broken in this case. It appears that the web service deployment piece ends up scanning all the wars in the EAR for metadata (annotations), and then trying to deploy the collected web services in every WAR in the EAR, not just the one that had the annotated web service classes.

This appears to be the same symptoms as the following bug, but for web services instead.

http://java.net/jira/browse/JAVASERVERFACES-1995

I have attached a very simple test EAR file. Trying to deploy this will demonstrate the error. You will see error messages about duplicate web service deployments and class not found exceptions.



 Comments   
Comment by nabizamani [ 22/Jul/13 07:44 PM ]

I created this clone of https://java.net/jira/browse/GLASSFISH-16249 because the issue reported still exists in GF 3.1.2.2.
A similar issue also exists in GF 4.0.

Below you can see the different outputs (I used an own ear which contains an ejb module and 2 war modules of which one contains restful classes):

  • Glassfish 3.1.2.2 (build 5)
    WARNING: WEB9052: Unable to load class com.demo.service.exception.RestExceptionCatcher, reason: java.lang.ClassNotFoundException: com.demo.service.exception.RestExceptionCatcher
    WARNING: WEB9052: Unable to load class com.demo.service.rss.NewsFeed, reason: java.lang.ClassNotFoundException: com.demo.service.rss.NewsFeed
  • Glassfish 4.0 (build 89).
    WARNING: Class 'javax.ejb.PostActivate' not found, interception based on it is not enabled
    WARNING: Class 'javax.ejb.PrePassivate' not found, interception based on it is not enabled
    INFO: Registering the Jersey servlet application, named com.demo.jaxrs.application.ApplicationConfig, at the servlet mapping /*, with the Application class of the same name.
    WARNING: Unable to load class com.demo.jaxrs.application.ApplicationConfig, reason: java.lang.ClassNotFoundException: com.demo.jaxrs.application.ApplicationConfig
    WARNING: Unable to load class com.demo.tutorials.mavenstruts.service.MessageService, reason: java.lang.ClassNotFoundException: com.demo.tutorials.mavenstruts.service.MessageService
    WARNING: Unable to load class com.demo.tutorials.mavenstruts.service.MessageService, reason: java.lang.ClassNotFoundException: com.demo.tutorials.mavenstruts.service.MessageService
    WARNING: Unable to load class com.demo.jaxrs.provider.MyJacksonJsonProvider, reason: java.lang.ClassNotFoundException: com.demo.jaxrs.provider.MyJacksonJsonProvider
    WARNING: Unable to load class com.demo.jaxrs.application.ApplicationConfig, reason: java.lang.ClassNotFoundException: com.demo.jaxrs.application.ApplicationConfig

Furthermore In GF 4.0 I get a lot of messages of this kind (which I really hate):
INFO: visiting unvisited references

Comment by Lukas Jungmann [ 01/Aug/13 12:54 PM ]

passing to jax-rs for evaluation since jar-rs seems to be involved here

Comment by Lukas Jungmann [ 01/Aug/13 12:55 PM ]

assign as needed, please. thx.

Comment by replicant77 [ 09/Sep/13 02:57 PM ]

We also get the ClassNotFoundException messages in multi-war deployments. But not only for rest service classes, but also for jsf related classes, like jsf converters and validators:

WARNING: WEB9052: Unable to load class gf4test.rest.TestService, reason: java.lang.ClassNotFoundException: gf4test.rest.TestService
WARNING: WEB9052: Unable to load class gf4test.converters.TestConverter1, reason: java.lang.ClassNotFoundException: gf4test.converters.TestConverter1

If you have a lot of such classes in your application this can get really annoying. We noticed these warning messages on GF 3.1.2 as well as GF4.

Comment by TangYong [ 10/Sep/13 03:04 AM ]

replicant77

Your attachment has problem and while deploying your attachment into 4.0.1-b02, the following error happened,

[2013-09-10T11:18:40.508+0900] [glassfish 4.0] [WARNING] [] [org.apache.jasper.runtime.TldScanner] [tid: _ThreadID=51 _ThreadName=admin-listener(1)] [timeMillis: 1378779520508] [levelValue: 900] [[
PWC6351: In TLD scanning, the supplied resource file:/E:/NanjingJUG/glassfish-4.0.1-b02/glassfish4/glassfish/domains/domain1/applications/TestApp/TestApp-ejbClient.jar does not exist
java.io.FileNotFoundException: E:\NanjingJUG\glassfish-4.0.1-b02\glassfish4\glassfish\domains\domain1\applications\TestApp\TestApp-ejbClient.jar (指定されたファイルが見つかりません。)
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:214)
at java.util.zip.ZipFile.<init>(ZipFile.java:144)
at java.util.jar.JarFile.<init>(JarFile.java:152)
at java.util.jar.JarFile.<init>(JarFile.java:89)
at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:93)
at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69)
at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:98)
at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:89)
at org.apache.jasper.runtime.TldScanner.scanJar(TldScanner.java:442)
at org.apache.jasper.runtime.TldScanner.scanJars(TldScanner.java:694)
at org.apache.jasper.runtime.TldScanner.scanTlds(TldScanner.java:350)
at org.apache.jasper.runtime.TldScanner.onStartup(TldScanner.java:239)
at org.apache.catalina.core.StandardContext.callServletContainerInitializers(StandardContext.java:6031)
at com.sun.enterprise.web.WebModule.callServletContainerInitializers(WebModule.java:774)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5929)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2286)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1932)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:404)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:140)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:158)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:101)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:353)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:343)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:237)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:318)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:211)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:982)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:330)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:173)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:496)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:175)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:187)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:837)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:722)
]]

[2013-09-10T11:18:40.867+0900] [glassfish 4.0] [INFO] [AS-WEB-GLUE-00172] [javax.enterprise.web] [tid: _ThreadID=51 _ThreadName=admin-listener(1)] [timeMillis: 1378779520867] [levelValue: 800] [[
Loading application TestApp#TestApp-war.war at [TestApp-war]]]

[2013-09-10T11:18:40.883+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=51 _ThreadName=admin-listener(1)] [timeMillis: 1378779520883] [levelValue: 900] [[
Unable to load class com.test.web.TestWebService, reason: java.lang.ClassNotFoundException: com.test.web.TestWebService]]

[2013-09-10T11:18:40.898+0900] [glassfish 4.0] [INFO] [AS-WEB-GLUE-00172] [javax.enterprise.web] [tid: _ThreadID=51 _ThreadName=admin-listener(1)] [timeMillis: 1378779520898] [levelValue: 800] [[
Loading application TestApp#TestApp2-war.war at [TestApp2-war]]]

[2013-09-10T11:18:40.977+0900] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=51 _ThreadName=admin-listener(1)] [timeMillis: 1378779520977] [levelValue: 800] [[
TestApp was successfully deployed in 10,876 milliseconds.]]

So, I have uploaded a new attachment.

OK, current issue should be the following:

[2013-09-10T11:18:40.883+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=51 _ThreadName=admin-listener(1)] [timeMillis: 1378779520883] [levelValue: 900] [[
Unable to load class com.test.web.TestWebService, reason: java.lang.ClassNotFoundException: com.test.web.TestWebService]]

1. the issue is not related to jax-rs comp
2. instead, firstly forwarding to web_services comp to evaluate, and I also add web_container comp to ask shing wai to evaluate it.

Comment by TangYong [ 10/Sep/13 03:58 AM ]

I made an initial investigation for the issue,

1) removing web_webservices comp because I have confirmed the warning info is related to web_container comp. so, pl. Shing Wai confirms

2) the warning happened in checkAgainstInterestList method from org.glassfish.web.loader.ServletContainerInitializerUtil class

In this attachment, there are two wars and TestApp2-war does not contain any class, TestApp-war contains a class with @WebService, while checkAgainstInterestList is executed, the method also scans TestApp2-war for @WebService, so, ClassNotFoundException happened.

I think this has some wrong logic because "interestList" variable in checkAgainstInterestList always saves previous result(eg. TestApp-war), for TestApp2-war, these annotations do not exist.

However, I think this issue itself should be not important and I think this should be an improvement rather than a bug.

Thanks
Tang

Comment by Shing Wai Chan [ 10/Sep/13 06:16 PM ]

The ClassNotFoundException warning is related to GLASSFISH-16937 .
Assign to Kinman to investigate TLDScanning FileNotFoundException.

Comment by pbelbin [ 09/Jan/14 10:39 PM ]

is there a fix for this issue? or, perhaps I'm having a different issue.

I have a .ear which has multiple .war contained within it that refuses to deploy.

I do see the WEB9052 warnings.

but, after that, I also see this:

[#|2014-01-09T16:29:49.206-0600|WARNING|glassfish3.1.2|javax.enterprise.webservices.org.glassfish.webservices|_ThreadID=130;_ThreadName=Thread-2;|Deployment failed
java.lang.AbstractMethodError
at org.glassfish.webservices.WsUtil.parseRelativeImports(WsUtil.java:414)
at org.glassfish.webservices.WsUtil.getWsdlsAndSchemas(WsUtil.java:1884)
at org.glassfish.webservices.WsUtil.getWsdlsAndSchemas(WsUtil.java:1858)
at org.glassfish.webservices.WSServletContextListener.registerEndpoint(WSServletContextListener.java:143)
at org.glassfish.webservices.WSServletContextListener.contextInitialized(WSServletContextListener.java:102)
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:4750)
at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:550)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5366)
at com.sun.enterprise.web.WebModule.start(WebModule.java:498)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:917)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:901)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:733)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2019)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1669)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:109)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:301)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:389)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:461)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:722)

#]




[GLASSFISH-20712] Session Replication (Possibly CNF error in web container?) Created: 19/Jul/13  Updated: 13/Aug/13

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: alev50 Assignee: Rajiv Mordani
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

1 node, 1 cluster, 2 instances


File Attachments: Zip Archive logs_180713_1612.zip    
Tags:
Participants: alev50, Ed Bratt, Rajiv Mordani, Sanjeeb Sahoo and Shing Wai Chan

 Description   

Here is the scenario I played :

1 - Start cluster
2 - Deploy web app
3 - Connect through load balancer -> instance 2
4 - Log on
5 - Stop instance 2
6 - Refresh browser -> instance 1
7 - Session lost + StreamCorruptedException
8 - Stop cluster

Logs are attached.

Thanks for help.

Regards,

Anthony

-----------------------------------------------------------------------------------------------------------------
Fialli Joe joe.fialli@oracle.com via shoal.java.net

Thanks for providing a full set of server logs just containing the test scenario that is failing for you.

I just want to make an overall statement that we are trying to track down class loading issues in the web container.
So you might want to post this issue to glassfish alias instead of the shoal alias.
So it is overkill to turn on the shoal logging to FINEST since that subsystem could not even be responsible
for corrupted stream (grizzly is the transport for messages between cluster members and the web container passes a
byte of serialized content into Shoal messaging system and when trying to reconstitute replicated session,
the byte array is taken out of shoal messaging subsystem and deserialized should be deserialized using web container class path.
While the failure is stating corrupted stream, the failure is always exactly the same type code of "00". If it truely was a corrupted stream,
we would see different values all the time. The best bet for Type Code 00 in stream is a class not being found.
The ClassNotFoundException is getting consumed and not reported.

Possible reason for the ClassNotFoundException is the following.

My observations when looking at the server log you sent yesterday was that it was incorrect
for there not to be a Web Container classloader context to deserialize the session context
(after all, the class is the app loaded in the container, the default ObjectInputStream is not going
to be able to deserialize that.)

So this failure is significant and needs interpretation by someone who works on web container. It happens quite a bit in the server logs that you sent in.
I am not aware why this would happen. The following might explain trying to deserialize replicated content in web container without using a web container
class path.

[#|2013-07-18T16:00:02.639+0200|FINEST|glassfish3.1.2|org.apache.catalina.loader.WebappLoader|_ThreadID=10;_ThreadName=Thread-2;ClassName=null;MethodName=null;|getClasspath
java.lang.NoSuchMethodException: com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.getClasspath()
at java.lang.Class.getMethod(Class.java:1607)
at org.apache.catalina.loader.WebappLoader.getClasspath(WebappLoader.java:1196)
at org.apache.catalina.loader.WebappLoader.setClassPath(WebappLoader.java:1145)
at org.apache.catalina.loader.WebappLoader.start(WebappLoader.java:692)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5298)
at com.sun.enterprise.web.WebModule.start(WebModule.java:498)
at org.apache.catalina.core.ContainerBase.startChildren(ContainerBase.java:1518)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1184)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:995)
at org.apache.catalina.core.ContainerBase.startChildren(ContainerBase.java:1518)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1184)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:529)
at org.apache.catalina.startup.Embedded.start(Embedded.java:942)
at com.sun.enterprise.web.WebContainer.postConstruct(WebContainer.java:604)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
at org.glassfish.internal.data.EngineInfo.getContainer(EngineInfo.java:93)
at com.sun.enterprise.v3.services.impl.WebContainerStarter.startWebContainer(WebContainerStarter.java:202)
at com.sun.enterprise.v3.services.impl.WebContainerStarter.postConstruct(WebContainerStarter.java:134)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:253)
at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:145)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:136)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.start(GlassFishDecorator.java:63)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishImpl.start(OSGiGlassFishImpl.java:69)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)

#]

*************

Here is time of first stream corrupted warning log message.
#|2013-07-18T16:06:35.588+0200|WARNING|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.ha.session.management|_ThreadID=75;_ThreadName=Thread-2;|Exception occurred in getSession

java.io.StreamCorruptedException: invalid type code: 00

Here is ClassNotFoundException that was probably related to that failure. (Note that this is a nested anonymous class. Typically difficult to serialize correctly.)
So the class below is probably one to look at.

[#|2013-07-18T16:06:35.584+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(com.transat.ga2010.service.BanqueServiceImpl$$EnhancerByCGLIB$$fedb0661)|#]

[#|2013-07-18T16:06:35.584+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| --> Passing on ClassNotFoundException|#]

Here are a large number classes that are being looked for just before this ClassNotFoundException log message.
[#|2013-07-18T16:06:34.749+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| --> Passing on ClassNotFoundException|#]

Note that the classes are mostly UI classes related to ajax, java faces.

[#|2013-07-18T16:06:37.493+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(com.transat.ga2010.web.messages)|#]
[#|2013-07-18T16:06:37.508+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(com.transat.ga2010.web.messages_fr)|#]
[#|2013-07-18T16:06:37.514+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(com.transat.ga2010.web.messages_fr_FR)|#]

[#|2013-07-18T16:06:38.123+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(org.ajax4jsf.xml.serializer.XMLEntities)|#]
[#|2013-07-18T16:06:38.129+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(org.ajax4jsf.xml.serializer.XMLEntities_fr)|#]

[#|2013-07-18T16:06:38.137+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(org.ajax4jsf.xml.serializer.XMLEntities_fr_FR)|#]

[#|2013-07-18T16:06:35.921+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(org.ajax4jsf.component.AjaxViewRootBeanInfo)|#]

[#|2013-07-18T16:06:35.925+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(javax.faces.component.UIViewRootBeanInfo)|#]

[#|2013-07-18T16:06:35.926+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(javax.faces.component.UIComponentBaseBeanInfo)|#]

[#|2013-07-18T16:06:36.012+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(org.ajax4jsf.messages_fr)|#]

[#|2013-07-18T16:06:36.019+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(org.ajax4jsf.messages_fr_FR)|#]

[#|2013-07-18T16:06:37.178+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(com.sun.facelets.compiler.UIInstructionsBeanInfo)|#]

[#|2013-07-18T16:06:37.183+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(com.sun.facelets.compiler.UILeafBeanInfo)|#]

[#|2013-07-18T16:06:37.190+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(login)|#]
[#|2013-07-18T16:06:37.198+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(login_fr_FR)|#]

[#|2013-07-18T16:06:37.205+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(javax.faces.component.html.HtmlFormBeanInfo)|#]
[#|2013-07-18T16:06:37.207+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(javax.faces.component.UIFormBeanInfo)|#]

[#|2013-07-18T16:06:37.253+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(javax.faces.component.html.HtmlMessagesBeanInfo)|#]
[#|2013-07-18T16:06:37.255+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(javax.faces.component.UIMessagesBeanInfo)|#]
[#|2013-07-18T16:06:37.265+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(org.richfaces.component.html.HtmlInputTextBeanInfo)|#]
[#|2013-07-18T16:06:37.273+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(javax.faces.component.UIInputBeanInfo)|#]

[#|2013-07-18T16:06:37.277+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(javax.faces.component.UIOutputBeanInfo)|#]
[#|2013-07-18T16:06:37.326+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(org.richfaces.component.html.HtmlInputSecretBeanInfo)|#]

[#|2013-07-18T16:06:37.328+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(org.richfaces.component.html.HtmlInputSecretBeanInfo)|#]

[#|2013-07-18T16:06:37.341+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(javax.faces.component.html.HtmlCommandButtonBeanInfo)|#]
[#|2013-07-18T16:06:37.344+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(javax.faces.component.UICommandBeanInfo)|#]
[#|2013-07-18T16:06:37.392+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(javax.faces.component.html.HtmlSelectBooleanCheckboxBeanInfo)|#]

[#|2013-07-18T16:06:37.195+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=76;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(login_fr)|#]

[#|2013-07-18T16:06:35.582+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=loadClass;|loadClass(com.transat.ga2010.service.BanqueServiceImpl$$EnhancerByCGLIB$$fedb0661)|#]

[#|2013-07-18T16:06:35.582+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=loadClass;| Delegating to classloader1 org.glassfish.internal.api.DelegatingClassLoader@7a8f9805|#]

[#|2013-07-18T16:06:35.584+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=loadClass;| Searching local repositories|#]

[#|2013-07-18T16:06:35.584+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClass(com.transat.ga2010.service.BanqueServiceImpl$$EnhancerByCGLIB$$fedb0661)|#]

[#|2013-07-18T16:06:35.584+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(com.transat.ga2010.service.BanqueServiceImpl$$EnhancerByCGLIB$$fedb0661)|#]

[#|2013-07-18T16:06:35.584+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| --> Passing on ClassNotFoundException|#]

[#|2013-07-18T16:06:35.582+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=loadClass;|loadClass(com.transat.ga2010.service.BanqueServiceImpl$$EnhancerByCGLIB$$fedb0661)|#]

[#|2013-07-18T16:06:35.582+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=loadClass;| Delegating to classloader1 org.glassfish.internal.api.DelegatingClassLoader@7a8f9805|#]

[#|2013-07-18T16:06:35.584+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=loadClass;| Searching local repositories|#]

[#|2013-07-18T16:06:35.584+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClass(com.transat.ga2010.service.BanqueServiceImpl$$EnhancerByCGLIB$$fedb0661)|#]

[#|2013-07-18T16:06:35.584+0200|FINER|glassfish3.1.2|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=75;_ThreadName=Thread-2;ClassName=org.glassfish.web.loader.WebappClassLoader;MethodName=findClass;| findClassInternal(com.transat.ga2010.service.BanqueServiceImpl$$EnhancerByCGLIB$$fedb0661)|#]



 Comments   
Comment by Ed Bratt [ 19/Jul/13 05:21 PM ]

Posting for Reporter. Clear virus scan.

Comment by Sanjeeb Sahoo [ 22/Jul/13 07:45 PM ]

The following exception happens because WebappLoader is reflectively calling getClasspath method in all class loaders in the class loader chain and APIClassLoader does not have such a method. From what I see WebappLoader does not consider this to be an issue, as it logs the exception in FINEST level. So, I am assigning the issue to web container folks to figure out why session replication does not happen.

"[#|2013-07-18T16:00:02.639+0200|FINEST|glassfish3.1.2|org.apache.catalina.loader.WebappLoader|_ThreadID=10;_ThreadName=Thread-2;ClassName=null;MethodName=null;|getClasspath
java.lang.NoSuchMethodException: com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.getClasspath()

Thanks,
Sahoo

Comment by Shing Wai Chan [ 06/Aug/13 07:16 PM ]

Can you attach a test case for this?

Comment by alev50 [ 12/Aug/13 08:47 PM ]

Not really, I deploy my production web app on a cluster, I stop the current instance and replication fails on a StreamCorruptedException. How could I write a simple test case for this ?

Thanks,

Anthony

Comment by Shing Wai Chan [ 12/Aug/13 10:17 PM ]

We have a unit test for session replication. It is working fine. So, we need more information to debug this. Can you try to construct a unit test case?

Comment by Shing Wai Chan [ 13/Aug/13 12:15 AM ]

Assign to Rajiv for session replication issue.





[GLASSFISH-20699] GlassFish returns 500 instead of 404 upon WebApplicationException Created: 14/Jul/13  Updated: 11/Dec/13

Status: Reopened
Project: glassfish
Component/s: jax-rs
Affects Version/s: 4.0_b89_RC5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: svanimpe Assignee: Jakub Podlesak
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OSX Mavericks Preview 3


File Attachments: Text File cdi-transaction-rollback.patch     Zip Archive GlassFish-20699.zip     Zip Archive GlassFish-20699_updated.zip    
Issue Links:
Related
is related to JAX_RS_SPEC-440 WebApplicationException contract coul... Open
Tags:
Participants: Jakub Podlesak, marina vatkina, Shing Wai Chan, svanimpe and TangYong

 Description   

The following method does not return a status of 404 Not Found, but instead returns a 500 Internal Server Error.

@Path("something")
public class Something {

@GET
public String getSomething() { throw new WebApplicationException(Status.NOT_FOUND); }
}

This used to work fine with GlassFish 3.1.
I do not have this problem when returning Status.BAD_REQUEST.



 Comments   
Comment by svanimpe [ 11/Sep/13 08:56 AM ]

Can someone please take a look at this ? Two months later and this issue is still exactly the same.

I can also add that the same thing happens with "throw new WebApplicationException(Status.FORBIDDEN)", as well as with "throw new NotFoundException()" and "throw new ForbiddenException()".

Comment by TangYong [ 11/Sep/13 09:45 AM ]

I made a sample the same as you said, however, my sample ran well, and 404 error can be displayed normally.

[Steps]
1. mvn clean install
2. asadmin deploy ...
3. accessing "http://localhost:8080/glassfish-20699/webapi/test/"

So, pl. seeing whether having any wrong config in your sample.

Then, I will close the jira.

Thanks
Tang

Comment by svanimpe [ 11/Sep/13 09:53 AM ]

Hi Tang,

The problem seems to be reproducible if you add @Transactional to the class in the sample.
In that case you no longer get a 404 but a 500 with a RollbackException.

Comment by TangYong [ 11/Sep/13 10:08 AM ]

Surly, if adding javax.transaction.Transactional into TestService class(GlassFish-20699_updated.zip), 500 error happened, and in the server.log,

[2013-09-11T19:01:03.780+0900] [glassfish 4.0] [INFO] [] [javax.enterprise.resource.jta.org.glassfish.cdi.transaction] [tid: _ThreadID=39 _ThreadName=http-listener-1(4)] [timeMillis: 1378893663780] [levelValue: 800] [[
In REQUIRED TransactionalInterceptor]]

[2013-09-11T19:01:03.952+0900] [glassfish 4.0] [INFO] [] [javax.enterprise.resource.jta.org.glassfish.cdi.transaction] [tid: _ThreadID=39 _ThreadName=http-listener-1(4)] [timeMillis: 1378893663952] [levelValue: 800] [[
Managed bean with Transactional annotation and TxType of REQUIRED called outside a transaction context. Beginning a transaction...]]

[2013-09-11T19:01:03.999+0900] [glassfish 4.0] [INFO] [] [javax.enterprise.resource.jta.org.glassfish.cdi.transaction] [tid: _ThreadID=39 _ThreadName=http-listener-1(4)] [timeMillis: 1378893663999] [levelValue: 800] [[
About to setRollbackOnly from @Transactional interceptor on transaction:JavaEETransactionImpl: txId=1 nonXAResource=null jtsTx=null localTxStatus=0 syncs=[]]]

[2013-09-11T19:01:04.015+0900] [glassfish 4.0] [INFO] [] [javax.enterprise.resource.jta.org.glassfish.cdi.transaction] [tid: _ThreadID=39 _ThreadName=http-listener-1(4)] [timeMillis: 1378893664015] [levelValue: 800] [[
Managed bean with Transactional annotation and TxType of REQUIRED encountered exception during commit javax.transaction.RollbackException: Transaction marked for rollback.]]

[2013-09-11T19:01:04.015+0900] [glassfish 4.0] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=39 _ThreadName=http-listener-1(4)] [timeMillis: 1378893664015] [levelValue: 900] [[
StandardWrapperValve[javax.ws.rs.core.Application]: Servlet.service() for servlet javax.ws.rs.core.Application threw exception
javax.transaction.RollbackException: Transaction marked for rollback.
at com.sun.enterprise.transaction.JavaEETransactionImpl.commit(JavaEETransactionImpl.java:445)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:854)
at com.sun.enterprise.transaction.TransactionManagerHelper.commit(TransactionManagerHelper.java:81)
at org.glassfish.cdi.transaction.TransactionalInterceptorRequired.transactional(TransactionalInterceptorRequired.java:99)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30)
at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:93)
at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:78)
at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:48)
at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:41)
at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:53)
at org.jboss.weld.proxies.TestService$Proxy$_$$_WeldSubclass.greet(Unknown Source)
at org.jboss.weld.proxies.TestService$Proxy$_$$_WeldClientProxy.greet(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:140)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:158)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$TypeOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:195)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:101)
at org.glassfish.jersey.server.model.Reso