Himai Minh wrote:Hi, Marco, I see the "view Serlvet". I right click the jsp in NetBean instead of on the browser. Now, I see the generated servlet code.
Thanks.
But according to Head First or EPractice Lab, <jsp:useBean .../> first looks for a bean called myAccount.
If myAccount variable does not exist, <jsp:useBean> will create a bean and store it in a variable called myAccount.
If myAccount exists in line 1, jsp:useBean in line 2 should be able to find it and store it in myAccount variable, instead of creating a new variable.
If myAccount exists in line 1, jsp:useBean in line 2 should be able to find it and store it in myAccount variable, instead of creating a new instance.
1. The order for listeners, servlets, filters if relevant must be specified in either the
web-fragment.xml or the web.xml. ...
... As described above, when using
annotations to define the listeners, servlets and filters, the order in which they are
invoked is unspecified. ...
1. The order for listeners, servlets, filters if relevant must be specified in either the
web-fragment.xml or the web.xml. ...
Tim Holloway wrote:The web.xml file is necessary when:
1. Annotations have not been provided for one or more resources that must be defined in a web.xml context to be usable.
AND/OR
2. You wish to override an annotation value for one or more resources that must be defined in a web.xml context to be usable.
Functionally "web.xml" always exists, it's just that in olden days, you had to define it all manually and explicitly. Now it's possible for a "virtual" web.xml to be produced. This virtual web.xml is constructed by scanning the classes for web.xml-context annotations and building up equivalents. Then, if a physical web.xml exists, any entries not supplied from the annotation scan will be added and any entries that overlap annotations will override the annotation values. This is in accordance with the general practice regarding annotation specifications - class annotations are used unless overridden by an explicit outside source (usually an XML file). That reduces or eliminates the need for separate out-of-line definitions, since the XML file needs only to contain exceptions to the defaults (and any missing entries).
Incidentally, every J(2)EE web application has 2 "deployment descriptors" which define how the webapp is to be deployed and wired into the server (URL routing, resource definitions, etc.) There's a server-dependent deployment descriptor which defines server-specific characteristics. For example, a Tomcat webapp's server-dependent is its Context xml definition (which can be supplied externally, as part of a WAR, or automatically constructed from defaults). Other servers have other server-dependent deployment descriptor files and formats.
For characteristics that are not specific to a particular brand of server, there's the server-independent deployment descriptor. Which is the WEB-INF/web.xml file or an automatically constructed equivalent.
Himai Minh wrote:On p.510 of Head First,
...you can't do scripting inside the body of the tag used to invoke the tag file.
I think we can do scripting inside classic tag, not simple tag.