Servlet Collections
I have been collecting these notes from various Web Sites, Discussion Forums and my own experience. To be more precise most of these Questions and Answers are taken from Java ranch forum and I like to personally thank every individual for coming up with such interesting thoughts and solutions. You will the rest of the stuff in the archives section which are not listed in this page.
Tuesday, December 27, 2005
Thursday, December 22, 2005
Tuesday, December 20, 2005
Monday, December 19, 2005
How to set response code in the response.
For example when you redirect from a servlet to a jsp page, default redirect response code will be (302 - Moved Temporarily). How to set this to 301 programatically.
response.setStatus(response.SC_MOVED_PERMANENTLY);
Thursday, December 15, 2005
Wednesday, December 07, 2005
Tuesday, December 06, 2005
How far will Attributes that are shared in a session object without synchronizing on the session object affect a multi-user web-site.
Using session objects without synchronization is technically not thread safe, as we all know... Well written code will synchronize on the HttpSession when working with session objects. However, not doing this will really only cause problems when the same client opens up two browser windows at the same time... so it doesn't matter how many people are using the site concurrently. The client may corrupt his session data by having multiple windows open
Servlet Declarative Security Notes
web-resource-collention> has NO http-method> sub-element
Scenario-I
WithOut auth-constraint> sub-element of security-constraint> element:
Everyone are allowed; Anyone in any role has access to the resource specified by the url-pattern> sub-element. The browser will NOT demand UserName/Password.
Scenario-II
With auth-constraint> sub-element of security-constraint> element:
All request to the specified resouce(all Http methods since there is no http-method> sub-element available) identified by the url-pattern> sub-element will be Constrained. The browser will request UserName/Password. Any request without correct UserName/Password will fail to get access to the resource.
web-resource-collention> has http-method> sub-element
Scenario-I
WithOut auth-constraint> of security-constraint> element:
Everyone are allowed; Anyone in any role has access to the resource specified by the url-pattern> sub-element. The browser will NOT be asking for UserName/Password
Scenario-II
With auth-constraint> sub-element of security-constraint> element:
All request to the specified resouce identified by the url-pattern> will be Constrained. The browser will request UserName/Password. Any request without correct UserName/Password will fail to get access to the resource.
NOTE:
The auth-constraint> element does NOT define which roles are allowed to access the resources defined in url-pattern>. Instead, it defines which roles are allowed to make the constraint request. Don't think Bob is a member, so Bob can access the AddRecipe servlet. Instead, say "Bob is a Member, so Bob can make a GET o POST request on the AddRecipe servlet.
If you specify an http-method> element, all the HTTP methods which you didn't specify are UNConstrained.
web-resource-collention> has NO http-method> sub-element
Scenario-I
WithOut
Everyone are allowed; Anyone in any role has access to the resource specified
Scenario-II
With auth-constraint> sub-element of security-constraint> element:
Scenario-I
WithOut auth-constraint> of security-constraint> element:
Everyone are allowed; Anyone in any role has access to the resource specified by the url-pattern> sub-element. The browser will NOT be asking for UserName/Password
Scenario-II
With auth-constraint> sub-element of security-constraint> element:
All request to the specified resouce identified by the url-pattern> will be Constrained. The browser will request UserName/Password. Any request without correct UserName/Password will fail to get access to the resource.
NOTE:
The auth-constraint> element does NOT define which roles are allowed to access the resources defined in url-pattern>. Instead, it defines which roles are allowed to make the constraint request. Don't think Bob is a member, so Bob can access the AddRecipe servlet. Instead, say "Bob is a Member, so Bob can make a GET o POST request on the AddRecipe servlet.
If you specify an http-method> element, all the HTTP methods which you didn't specify are UNConstrained.
Check this Thread