mvc:view-controller

This tag is a shortcut for defining a ParameterizableViewController that immediately forwards to a view when invoked. Use it in static cases when there is no Java Controller logic to execute before the view generates the response.

An example of view-controller that forwards to a home page is shown below: <mvc:view-controller path="/" view-name="home"/>
Source: http://static.springsource.org/spring/docs/3.0.x/reference/mvc.html

Spring 3.1 M2: Spring MVC Enhancements

Programming Model Improvements

This is the list of programming model improvements introduced in the new @MVC support classes.

1. Declared @PathVariable arguments are now automatically added to the model. For example this:
@RequestMapping("/develop/apps/edit/{slug}") public String editForm(@PathVariable String slug, Model model) { model.addAttribute("slug", slug); // ... }
is replaced by:
@RequestMapping("/develop/apps/edit/{slug}") public String editForm(@PathVariable String slug, Model model) { // model contains "slug" variable }


2. Redirect strings support URI templates expanded with variables from the model (including declared @PathVariables). For example this:
@RequestMapping( value="/groups/{group}/events/{year}/{month}/{slug}/rooms", method=RequestMethod.POST) public String createRoom( @PathVariable String group, @PathVariable Integer year, @PathVariable Integer month, @PathVariable String slug) { // ... return "redirect:/groups/" + group + "/events/" + year + "/" + month + "/" + slug; }
is replaced by:
@RequestMapping( value="/groups/{group}/events/{year}/{month}/{slug}/rooms", method=RequestMethod.POST) public String createRoom( @PathVariable String group, @PathVariable Integer year, @PathVariable Integer month, @PathVariable String slug) { // ... return "redirect:/groups/{group}/events/{year}/{month}/{slug}"; }


3. URI template variables are supported in data binding. For example this:
@RequestMapping("/people/{firstName}/{lastName}/SSN") public String find(Person person, @PathVariable String firstName, @PathVariable String lastName) { person.setFirstName(firstName); person.setLastName(lastName); // ... }
is replaced by:
@RequestMapping("/people/{firstName}/{lastName}/SSN") public String search(Person person) { // person.getFirstName() and person.getLastName() are populated // ... }


4. Consumable and producible media types can be specified via @RequestMapping. For example this:
@RequestMapping(value="/pets", headers="Content-Type=application/json") public void addPet(@RequestBody Pet pet, Model model) { // ... }
is replaced by:
@RequestMapping(value="/pets", consumes="application/json") public void addPet(@RequestBody Pet pet, Model model) { // ... }
Besides being shorter the above returns NOT_ACCEPTABLE (406) if the URL matches but the input media type doesn't.


5. For producible media types this:
@Controller @RequestMapping(value = "/pets/{petId}", headers="Accept=application/json") @ResponseBody public Pet getPet(@PathVariable String petId, Model model) { // ... }
is replaced by:
@Controller @RequestMapping(value = "/pets/{petId}", produces="application/json") @ResponseBody public Pet getPet(@PathVariable String petId, Model model) { // ... }
The above returns a NOT_SUPPORTED_MEDIA_TYPE (415) if the URL matches but the acceptable media type doesn't.

Removing taglib from web.xml

JSP 1.2 required the <taglib> directive to be used in web.xml for every JSP Custom Tag Library used by the application. In JSP 2.0 this is no longer required. This guide shows how to get rid of your <taglib> directives and how JSP 2.0 finds TLD files.
The <taglib> directive looks like this. You will find one in web.xml for older versions of Struts, and any other software which uses tag libraries in JSP 1.2.
 <taglib> <taglib-uri>mytags</taglib-uri> <taglib-location>/WEB-INF/jsp/mytaglib.tld</taglib-location> </taglib>
Since JSP 2.0, this is now optional.
The TLD is discovered automatically when the taglib is first referenced in a JSP file.
The actual JSP 1.2 TLD files themselves are upwardly compatible with JSP 2.0, so do not need to be modified.

Where does JSP look for the TLD files?

JSP 2.0 containers such as Tomcat 5.5 search for TLD files in the following places:
The following locations are searched:

• <appName>/WEB-INF folder
• All subfolders of <appName>/WEB-INF
• Inside each JAR file in <appName>/WEB-INF/lib, in the META-INF folder of the JAR. This method is prefered for easy deployment of a JAR containing a taglib.  

How should I package my JAR file?

Place TLD files in a folder named META-INF, at the root level of the JAR file. eg:

Why is this better?

For library developers, distribution is now simpler as packaging is as simple as including the TLD file in the JAR file.
For end-users, deployment and re-use is simpler, as a tag library JAR file can simply be dropped into the WEB-INF/lib folder with no web.xml configuration required.

TLD Tips in JSP 2.0

• The TLD file does not need to have the same name as the library. For example, your mytags library definition can be in a file called mytaglist.tld. However, for easier identification later, it is good practise to use the same name as you intend to use in the JSP files. For example, if you plan to reference your library as mytags, with <mytags:testtag> in JSP, call the file mytags.tld.
• The <short-name> element in the TLD file does not need the same name as the library. Once again, for easier maintenance and to avoid potential clashes, it is good practise to use the same name. For example <short-name>mytags</short-name>.
• The <uri> in the TLD file is the main reference for matching JSP declarations with the correct TLD. When automatically finding TLD files, the container matches the uri attribute in your JSP taglib declaration with the <uri> tag in the TLD file. Ensure this is always unique to avoid clashes. For example:

This declaration in your JSP ... <%@ taglib prefix="mytags" uri="http://java.sun.com/jsp/jstl/core" %> Will match this element in your TLD ... <uri>http://java.sun.com/jsp/jstl/core</uri>

Upgrading your application

• Many older applications still include the <taglib> directive in web.xml. If your application falls into this category, try removing it and check if everything still works. Don't forget to move your TLD file into WEB-INF, or preferably into your JAR file. Your web.xml will be simpler, and the Tag Library will be more modular (easier to remove from the app, replace, or reuse).
• In older applications, the TLD file is sometimes in a separate folder, such as in the example above (/WEB-INF/jsp/mytaglib.tld). In this case, move the file into the JAR file if possible. TLD files will still work from subfolders of WEB-INF, but since the location of the TLD files is no longer recorded in web.xml, it can make them harder to find when debugging your system later - especially after a few months of not looking at it, or if someone else is trying to debug your code. It therefore makes sense to either include them in the JAR file which contains the classes for the tag, or at least place them in an easy to notice location such as a subfolder called WEB-INF/tld or WEB-INF/taglibs.

Reference: http://wiki.metawerx.net/wiki/Web.xml

Using @PathVariable

Let's say that you are creating an user account-based web application in Spring 3.0. You would like to create a controller that would allow users to see each other's profile by using a URL such as
http://myapp/profile/username.

For example:
http://myapp/profile/Juan would show user Juan's profile.
http://myapp/profile/Gaby would show user Gaby's profile.


Spring 3.0's annotated controllers make this kind of mapping easy with the new @PathVariable mapping. @Controller public class ShowProfileController { @RequestMapping("/profile/{username}") public String showProfile(Model model, @PathVariable("username") final String username) { ... return "showProfile"; // show my jsp } } As you can see, the RequestMapping for the showProfile method has something a bit unusual: {username}
This is a PathVariable, and it means that this method will serve any request of the format "/profile/someUserName"

We capture the actual username in the next line using the @PathVariable annotation @PathVariable("username") and store it in the variable

final String username

Now we can use it however we want!
Viva Spring framework!!!

Log4J: Properties and XML

Personally I prefer the XML instead of the properties file, but...
On this case I was having some trouble with my App server (WebLogic) - it wasn't loading my log4.xml, so I had to come up with a workaround: by using a propeties file.

This is more a look and learn than look and follow this steps. Because by looking to my XML file you'll see the equivalent in properties file, maybe this will help you when you have to write one or another. <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"> <log4j:configuration xmlns:log4j = "http://jakarta.apache.org/log4j/"> <!-- ===console Appender=== --> <appender name = "console" class = "org.apache.log4j.ConsoleAppender"> <layout class = "org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="[%d{dd-MM-yy HH:mm:ss,SSS}] [%t] %-5p (%50c{10}-%30M:%4L) -> %m%n"/> </layout> </appender> <!-- ===spring Appender=== --> <appender name = "spring" class = "org.apache.log4j.RollingFileAppender"> <param name = "File" value = "${sitexfer-testing}/log/spring.log"/> <param name = "MaxFileSize" value = "100KB"/> <param name = "MaxBackupIndex" value = "1"/> <layout class = "org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="[%d{dd-MM-yy HH:mm:ss,SSS}] [%t] %-5p (%50c{10}-%30M:%4L) -> %m%n"/> </layout> </appender> <!-- ===app Appender=== --> <appender name = "app" class = "org.apache.log4j.RollingFileAppender"> <param name = "File" value = "${sitexfer-testing}/log/app.log"/> <param name = "MaxFileSize" value = "100KB"/> <param name = "MaxBackupIndex" value = "1"/> <layout class = "org.apache.log4j.PatternLayout"> <param name = "ConversionPattern" value = "[%d{dd-MM-yy HH:mm:ss,SSS}] [%t] %-5p (%50c{10}-%30M:%4L) -> %m%n"/> </layout> </appender> <!--LOGGERS: App--> <logger name = "com.bofa.sitexfer.web" additivity = "false"> <level value = "DEBUG"/> <appender-ref ref = "console"/> </logger> <!--LOGGERS: Framework--> <logger name = "org.springframework" additivity = "false"> <level value = "INFO"/> <appender-ref ref = "spring"/> <appender-ref ref = "console"/> </logger> <logger name = "org.springframework.web" additivity = "false"> <level value = "INFO"/> <appender-ref ref = "spring"/> <appender-ref ref = "console"/> </logger> <!--ROOT--> <root> <level value = "INFO"/> <appender-ref ref = "console"/> </root> </log4j:configuration> #Default logging level and Appenders to be used log4j.rootLogger=DEBUG, console, app, spring #Console log4j.appender.console=org.apache.log4j.ConsoleAppender log4j.appender.console.layout=org.apache.log4j.PatternLayout log4j.appender.console.layout.ConversionPattern=[%d{dd-MM-yy HH:mm:ss,SSS}] [%t] %-5p (%50c{10}-%30M:%4L) -> %m%n #Level of DEBUG log4j.logger.com.bofa.sitexfer.web=DEBUG log4j.logger.org.springframework=INFO #app Appender log4j.appender.app.layout=org.apache.log4j.PatternLayout log4j.appender.app.layout.ConversionPattern=[%d{dd-MM-yy HH:mm:ss,SSS}] [%t] %-5p (%50c{10}-%30M:%4L) -> %m%n log4j.appender.app=org.apache.log4j.RollingFileAppender log4j.appender.app.File=/logs/app.log log4j.appender.app.MaxFileSize=100KB log4j.appender.app.MaxBackupIndex=1 #spring Appender log4j.appender.spring.layout=org.apache.log4j.PatternLayout log4j.appender.spring.layout.ConversionPattern=[%d{dd-MM-yy HH:mm:ss,SSS}] [%t] %-5p (%50c{10}-%30M:%4L) -> %m%n log4j.appender.spring=org.apache.log4j.RollingFileAppender log4j.appender.spring.File=/logs/spring.log log4j.appender.spring.MaxFileSize=100KB log4j.appender.spring.MaxBackupIndex=1