Context.xml

Some of you guys already know that I love to develop on Tomcat and release into a bigger App Server, and for those who have noticed, I use a lot this file on my apps, well there you have some interesting info about this file :)

The context.xml file is an optional file which contains a <Context> tag (Context Fragment) for a single Tomcat web application. This can be used to define certain behaviours for your application, JNDI resources and other settings.
The context.xml file was introduced in Tomcat 5, to remove Context settings from the server.xml file.
The Context Fragment can be embedded in server.xml, placed in the <CATALINA>/conf folder, or placed inside each application in the META-INF folder in a file called context.xml. The META-INF method is preferred as this means changes to the context don't require Tomcat to be restarted. You can restart your application by modifying web.xml when automatic reloading is active, or reloading manually with the Tomcat Manager.
Your context.xml file should be installed in the META-INF folder of your application, as META-INF/context.xml. The META-INF folder belongs at the same level as WEB-INF (not inside it).

index.jsp
/WEB-INF
    web.xml
    /lib
        myjar.jar
    /classes
        myclass.class
/META-INF
    context.xml

Surprisingly, not many developers use this file within their applications yet, although it is very useful. Switching to the use of a context.xml file removes all dependencies from server.xml, making the application much more portable and easier to deploy.

Example context.xml file

This file provides a JNDI resource representing a MySQL datasource, and a security realm. <?xml version="1.0" encoding="UTF-8"?> <Context> <!-- Specify a JDBC datasource --> <Resource name="jdbc/mydatabase" auth="Container" type="javax.sql.DataSource" username="YOUR_USERNAME" password="YOUR_PASSWORD" driverClassName="com.mysql.jdbc.Driver" url="jdbc:mysql://mysql.metawerx.net:3306/YOUR_DATABASE_NAME?autoReconnect=true" validationQuery="select 1" maxActive="10" maxIdle="4"/> <!-- Specify the security realm and location of the users file <Realm className="org.apache.catalina.realm.MemoryRealm" pathname="/tomcat/webapps/ROOT/WEB-INF/users.xml" /> --> </Context>

Notes

• Some examples show path and docBase attributes in the <Context> tag. These are required if the context tag is in server.xml, but in context.xml they are optional, and often just cause deployment problems (eg: if the application is deployed with a different name). It is easier (and better) to leave them out, making the context name automatic. In this case, just use <Context> with no attributes, as in the above example.
• Default settings for all Contexts are defined in the context.xml.default file in the <CATALINA>/conf folder

Gotchas / Troubleshooting / Debugging JNDI DataSource issues

• JNDI issues are difficult to debug, as there is no debug output, so if you have problems, check this list
• With a JNDI datasource, make sure to include the JDBC driver in <CATALINA/common/lib or it will not load
• If a JNDI datasource does not work, ensure the connection details are correct by connecting a different way (eg: telnet or the mysql command client using the same details)
• deployXML must be set to false (the default) in the <Host> entry in server.xml, or the context.xml file will be ignored
• Tomcat 5.5 and Tomcat 6 copy the context.xml file to <CATALINA>/conf/Standalone after the first the successful deployment, and do not remove or update the file unless the application is undeployed. If you change your context.xml file and find it still doesn't work, or your changes are ignored, delete any files in the <CATALINA>/conf/Standalone folder to ensure they are redeployed correctly. Tomcat 7 does not have this problem, unless copyXML is set false (default is true).

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

Cross-site Scripting (XSS)

Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites. Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by your browser and used with that site. These scripts can even rewrite the content of the HTML page.

The normal practice is to HTML-escape any user-controlled data during redisplaying in JSP, not during processing the submitted data in servlet nor during storing in DB. In JSP you can use the JSTL (to install it, just drop jstl-1.2.jar in /WEB-INF/lib) <c:out> tag or fn:escapeXml function for this. E.g.

<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %> ... <p>Welcome <c:out value="${user.name}" /></p> OR <%@ taglib uri="http://java.sun.com/jsp/jstl/functions" prefix="fn" %> ... <input name="username" value="${fn:escapeXml(param.username)}">
This is the classic example: http://127.0.0.1:8088/sitexfer-testing/index.jsp?ERROR_MSG=INVALID_TARGET_DOMAIN&authtype=AUTH_T3%20style=width:expression(alert(1))&appname=DEFAULT_TIER3&TARGET=%24SM%24http%3A%2F%2Fwww.google.com Look carefully to the param authtype, did you see the alert(1)??? If you don't write safe code, you might get an infinite loop in your screen :)

For more details please go to: https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)

Upload Files with Spring MVC

Have you ever tried to upload a file as part of a form to be submited?
In my case I have a form to add or update products, and each product must have an image (JPG file), besides the regular information related to each product: Name, Description, etc.
Then, we need a form with some inputs and a method on one of my controllers to handle this request and we're set.

This topic is really simple to cover, despite of the fact is poorly covered by the official documentation.
Steps
Add entries on your POM <dependency> <groupId>commons-io</groupId> <artifactId>commons-io</artifactId> <version>1.4</version> </dependency> <dependency> <groupId>commons-fileupload</groupId> <artifactId>commons-fileupload</artifactId> <version>1.2.1</version> </dependency>
Add a MultipartResolver in your Web Application Context <property name="maxUploadSize" value="50000"/><!-- in bytes --> <!-- There are more props, but I am not going to use them --> </bean>
On your form don't forget to include enctype attribute and make it POST

Add your input type file as regular HTML

In your controller add a method to handle with all params @RequestMapping(value="saveOrUpdateProduct.do", method=RequestMethod.POST) public String saveUpdateProduct(HttpServletRequest request, ModelMap modelMap, @ModelAttribute("ProductDTO") final ProductDTO productDTO, @RequestParam("productImage") final MultipartFile productImage, @RequestParam("brand") final Integer brand, @RequestParam("category") final Integer category){ if(!this.isLoggedIn(request)){//Verify if user is authenticated return "redirect:/authentication/notLoggedIn.do"; } Boolean result = false; File fileProductImage = new File(request.getSession().getServletContext().getRealPath("/img/products/")+File.separatorChar+productDTO.getCode()+".JPG"); //I'm going to upload all images into this directory and will assign them ext JPG log.debug("Save or Update products"); log.debug("fileProductImage="+fileProductImage); productDTO.getBrandDTO().setIdBrand(brand); productDTO.getCategoryDTO().setIdCategory(category); try { /*if(StringUtils.isEmpty(productDTO.getIdProduct()+"")){ result = this.catalogsService.addProduct(productDTO); }else{ result = this.catalogsService.modifyProduct(productDTO); } */ if(result){ log.debug("productDTO= "+productDTO+", idBrand= "+brand+", idCategory="+category); log.debug("FileUpload= "+productImage+", "+productImage.getContentType()+", "+productImage.getName()+", "+productImage.getOriginalFilename()+", "+productImage.getSize()); FileUtils.writeByteArrayToFile(fileProductImage, productImage.getBytes()); } } catch (Exception ex) { log.error(ex); modelMap.put(GenericConstants.KEY_ERROR, ex.getMessage()); } return getAllProducts(request, modelMap, null); }
I'm using FileUtils to save the uploaded file :D
Look carefully to this parameter @RequestParam("productImage") final org.springframework.web.multipart.MultipartFile productImage @RequestParam("productImage") matches to

And you're all set! Easy, Isn't it?

Pass parameters from one page to another

This is the issue, I have a JSP which helps me to generate a URL to change the Locale, to switch between Spanish and English, but I have a JSP (maybe more) which is displayed based on a Parameter, because shows the details for an Object based on idObject.
This is my original JSP (So each time I clicked the link, the page was refreshed, but missing the param, obviously the content was never displayed - duh!) <fmt:message key="button.locale"/>: <c:url var="englishLocaleUrl" value="${urlBase}"> <c:param name="locale" value="en" /> </c:url> <c:url var="spanishLocaleUrl" value="${urlBase}"> <c:param name="locale" value="es" /> </c:url> <c:out value="${englishLocaleUrl}"/><fmt:message key="locale.english"/> <c:out value="${spanishLocaleUrl}"/><fmt:message key="locale.spanish"/>

The fix is really simple, just add more params to each URL, by using JSTL :) Like this (creating dynamically my params) <c:forEach items="${param}" var="pageParam"> <c:param name="${pageParam.key}" value="${pageParam.value}" /> </c:forEach> <fmt:message key="button.locale"/>: <c:url var="englishLocaleUrl" value="${urlBase}"> <c:param name="locale" value="en" /> <c:forEach items="${param}" var="pageParam"> <c:param name="${pageParam.key}" value="${pageParam.value}" /> </c:forEach> </c:url> <c:url var="spanishLocaleUrl" value="${urlBase}"> <c:param name="locale" value="es" /> <c:forEach items="${param}" var="pageParam"> <c:param name="${pageParam.key}" value="${pageParam.value}" /> </c:forEach> </c:url> <c:out value="${englishLocaleUrl}"/><fmt:message key="locale.english"/> <c:out value="${spanishLocaleUrl}"/><fmt:message key="locale.spanish"/>

Applications Multilanguage - Issue with Ñ and Accents

It's been a while since I worked with an Application in Spanish.
Always English!

This time, testing that my messages properties were used properly (I was just testing that I didn't miss any message), I saw something really weird:

After thinking about what happened in Japan and reading the news, I came back to this issue.

Then, I realized I was using the wrong META TAG (Charset) meta http-equiv="Content-Type" content="texthtml; charset=UTF-8"
After updating my Charset to "ISO-8859-1", everything look as I expected, hopefully I won't have to face any issue like this one with another language (like Russian, Hindi or Japanese) because as I know all of them have a different CharSet different from English and Spanish :)

Spring MVC - Binding VO to a Form

Problema:
I have a VO and I wanted to populate it on my JSP and on my controller just process the VO already populated.

Solution:
@Controller @RequestMapping(value = "/loggers/*") public class LoggersConfigurationController extends BaseCustomController { private static final Logger log = Logger .getLogger(LoggersConfigurationController.class); @SuppressWarnings("unchecked") @RequestMapping(value = "configureLoggers.do", method = RequestMethod.GET) public String showScreen(HttpServletRequest request, HttpServletResponse response, ModelMap modelMap) { if (!this.isLoggedIn(request)) { return "redirect:/authentication/notLoggedIn.do"; } log.debug("Show Screen when RequestMethod.GET"); //By doing this I'm preparing my diabolic plan!!! LoggerVO loggerVO = new LoggerVO(); modelMap.put("LoggerVO", loggerVO); return "configuration/loggersConfiguration"; } @SuppressWarnings("unchecked") @RequestMapping(value = "configureLoggers.do", method = RequestMethod.POST) public String updateLogger( HttpServletRequest request, HttpServletResponse response, ModelMap modelMap, @ModelAttribute(value="LoggerVO") LoggerVO loggerVO) { if (!this.isLoggedIn(request)) { return "redirect:/authentication/notLoggedIn.do"; } log.debug("Update logger when RequestMethod.POST"); List<String> messages = new ArrayList<String>(); log.debug("@ModelAttribute="+loggerVO); LogUtils.getInstance().setLogger(loggerVO); messages.add(loggerVO.getName()+" updated successfully to "+loggerVO.getLevel()); modelMap.put("KEY_LIST_MESSAGES", messages); //return "configuration/loggersConfiguration"; return "index-tabbed"; } }
On my POST method I'll handle my VO already populated.
This entry will do 50% of the job @ModelAttribute(value="LoggerVO") LoggerVO loggerVO
On my JSP I'll map using spring's tag library <%@taglib prefix="spring" uri="http://www.springframework.org/tags" %> <%@taglib prefix="form" uri="http://www.springframework.org/tags/form" %> <%@taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %> <H2>Loggers Configuration</H2> <form:form id="loggersForm" name="loggersForm" modelAttribute="LoggerVO" commandName="LoggerVO" action="/${pageContext.servletContext.servletContextName}/loggers/configureLoggers.do" method="POST"> <table width="100%"> <tr> <td><label for="name">Logger Name</label></td> <td> <form:select path="name" items="${applicationScope.KEY_LIST_LOGGERS}" itemValue="name" itemLabel="name"/> </td> </tr> <tr> <td><label for="level">Level</label></td> <td> <form:select path="level" items="${applicationScope.KEY_LIST_LOG_LEVELS}"/> </td> </tr> </table> <p> <input type="submit" value="Update"> </p> <div style="visibility: hidden"> <form:select path="appenderVOs"/> </div> </form:form> <c:if test="${!empty requestScope.KEY_LIST_MESSAGES}"> <script>alert("${requestScope.KEY_LIST_MESSAGES}");</script> </c:if>
By doing this modelAttribute="LoggerVO" commandName="LoggerVO"
I'm matching what I have on my form and what I have on my Controller <form:form id="loggersForm" name="loggersForm" modelAttribute="LoggerVO" commandName="LoggerVO" action="/${pageContext.servletContext.servletContextName}/loggers/configureLoggers.do" method="POST">
I hope this will help you!
Salu2