1.The Default value for body-content element of tag library descriptor is:JSP Is this right?Because I know that HFSJ mentioned scriptless being the default...
Cant remember where this question is from:
2.No xml elements should appear before <web-app> in a JSP document
What about the <?xml....> and <jsp:root> elements??
3.Could someone explain the basics(that I should remember) of forward referencing to me?
4.From HFSJ pg 356:
Assuming no bean is found,will this just make a scripting variable of type foo.Person available??
5.From David Bridgewater mock on javablackbelt.com:
All objects placed in a session must invariably implement java.io.Serializable Sessions for a web application can be distributed across several JVMs, but any one session must remain attached to a single JVM.
My observation:Aren't sessions migrated across VM's??
Also : Doesn't HFSJ state that session attributes don't need to be Serializable,but if they are,then the container is required to migrate them(although it is a good idea to have all your session attributes be serializable)
6.From David Bridgewater mock on javablackbelt.com:
Filter mappings must be defined within the web.xml deployment descriptor, before listener definitions which in turn come before servlet definitions.
Observation:I didn't come across anything like this in HFSJ,is it maybe behaviour from earlier versions of the DD or something?
7.From David Bridgewater mock on javablackbelt.com:
A browser sends a request containing no headers to a servlet. What is the result of executing the following method within the servlet?
Never mind the method..how is it possible to senda request with no headers??
Also,I do know about the whole "One thread one question" thing,but do you really want seven different threads??
for question 4
if you are using <jsp:useBean> with a type and without any class, then you must ensure these 2 things:
1 - the bean should already exist in the scope defined. (page is the default)
2 - if the person attribute doesnot exist in the page scope, it will throw a java.lang.InstantiationException.
answer to question 5
sessions are migrated across VMs. to successfully migrate your session attributes across VMs you need to make sure either of the two things:
1 - make sure your attribute class types are Serializable.
2- if they are not Serializable for some reason, have your attribute object class implement HttpSessionActivationListener and use the activation/passivation callbacks to work around it.
HFSJ states in clear terms that:
A container is required to migrate Serializable attributes. But a container is not required to use Serialization as the means for migrating the HttpSession objects.
This means the above 2 points i mentioned.