Thoughts on programming

Difference between / and /* in servlet mapping

Tue, 27 Dec 2011 14:19:00 -0600

/ means the servlet is the default servlet for the app

/* is used for path mapping and captures all requests to the app. In essence, every request goes through this servlet even requests for JSPs. JSP cannot be used with a servlet mapping of /*

Never use /* in the servlet mapping.

This thread by far has the best explanation http://www.coderanch.com/t/366340/Servlets/java/servlet-mapping-url-pattern-vs

Scalate is good but not usable

Fri, 16 Dec 2011 14:48:00 -0600

Scalate is an awesome template engine and i really mean that. Its written in Scala and just fabulous in the way that it supports multiple template languages like HAML(Scaml),Jade and Mustache over a common interface.

Its simple enough to understand and is really easy to write HTML templates using Jade/Scaml without using an IDE. The documentation is decent enough to convince you to use it on your project. Some of the Scala web frameworks like Scalatra use it as the default TE.

But if you are going to use it on a Java web project, be warned. You will end up writing Scala code to support simple operations like iterating a collection. I like the idea that the template gets translated to Scala code but to write Scala foreach or for loops for iterating collections every time is ridiculous. Writing templates should be easy and common tasks should already be provided.

Sure, Scalate lets you call Scala functions and it looks like custom tags in JSP, but the fact that YOU have to write that function makes it look less sexier. I don’t like JSP, i live with it because it has JSTL. Scalate should come up standard set of functions for mundane tasks.

If you are using Spring MVC / Struts 2, both provide tag libraries for JSP. Using Scalate, you have to create your own set of functions to mirror the tag-lib functionality, which is certainly not what you want to do.

Thinking about Scalate for Java web projects, my advice is stay away.

"Test post from Android"

Wed, 14 Sep 2011 22:12:58 -0500

“Test post from Android”

Escaping ID selector in jQuery

Wed, 14 Sep 2011 11:34:00 -0500

If you are using a framework like JSF/Struts which generates ids like

id=”form:myButton” or id=”form.myIput[1]” and want to use these ids in jQuery, it would complain “unrecognized expression :myButton”.

Escape it with double backslashes like this

$(“#form\\:myButton”) or $(“#form\\.myInput\\[1\\]”)

Deft - Tornodo like app server on the JVM

Mon, 12 Sep 2011 20:18:00 -0500

Deft - Tornodo like app server on the JVM

REST Services in Scala using Akka

Mon, 12 Sep 2011 20:13:37 -0500

REST Services in Scala using Akka:

I searched for quite a while to find this framework. Its built on top of Akka and its really straightforward to write services.

Custom Username Password Parameter Names in Spring Security 3

Mon, 12 Sep 2011 17:07:00 -0500

Spring Security 3 does not allow custom parameter names for username & password, if you are using using form based login. You have to use the default j_username and j_password. This may not be a problem for many use cases, but sometimes you would want to change that.

A feature request is in process by Spring Security community. If you dont want to wait till that’s done, here’s a quick fix.

It can be loaded into your config file like this,

Facebook style input box using YUI2

Sun, 02 May 2010 00:00:00 -0500

A facebook style input box using YUI 2 Autocomplete. Demo here.

Download the code here.

CSS Selector for HTTPBuilder

Sun, 02 May 2010 00:00:00 -0500

If you use HTTPBuilder to crawl web pages and extract information, you would have noticed that it uses the Groovy’s XML Support for parsing HTML. Groovy’s GPath is powerful, but HTML has something more powerful (not to mention simple, easy and intuitive) for selection, CSS Selectors. jQuery has proved css selectors are indeed, the best way for DOM manipulation.

CSS Selectors are available for Java using this library

http://github.com/chrsan/css-selectors

I wrote a small facade class CSSSelector to expose css selectors, the Groovy way.

http://code.google.com/p/css-selector-httpbuilder/

Here’s an example,

The CSSSelector class has no dependencies on HTTPBuilder. It can be used with any library in Groovy. If you want to use it with a Java library, you can use css-selectors in github

window.open behavior in Google Chrome

Thu, 15 Apr 2010 00:00:00 -0500

In Chrome,if window.open is called with same window name by pages which are managed by the same process, then the first call creates a new window and subsequent calls return reference to the existing window.If the pages are managed by different processes, then each call to window.open creates a new window.So far, i have been thinking

that if window.open is called with name of window which is already open, then a reference to that window is returned, instead of creating a new one. At least thats what MDC and MSDNsay.

From MDC,

If a window with the name strWindowName already exists, then, instead of opening a new window, strUrl is loaded into the existing window. In this case the return value of the method is the existing window.

Before diving into the details, lets have a quick Chrome process architecture primer. You are probably aware that Chrome has a multi process architecture. But contrary what you might think, not every tab has its own process. Some tabs reuse the existing process. So, how does Chrome decide to create a new process for a tab or use an existing one?

From Chrome webmaster FAQ

New tabs spawned from a web page, however, are usually opened in the same process, so that the original page can access the new tab using JavaScript.

The above statement holds good even if the tab spawned from a web page is of a different domain. So, watch your external links.The corollary of this statement is that if a user opens the same page from the same domain,in fresh tabs (using Ctrl-T or the ‘plus’ button), then those two pages reside in a separate process. Try these steps to see it in action.

Search ”cnn” in Yahoo.com and open the first link using Ctrl - left click. It should open in a new tab.
Now, open another tab and type in cnn.com.
Open Chrome task manager, you can see 3 items, yahoo search results page and 2 CNN pages. Click on the yahoo search results item, it will also select one CNN.com tab. This means those 2 tabs are managed by the same process. The other cnn.com opened in a fresh tab is managed by a different process.

Back to our original discussion. This is going to sound like a math theorem, but i cant find a simpler way to explain it. Lets assume page P from domain D is loaded in tabs T1 and T2 and both are managed by different processes. On a button click, P opens a new window using window.open. First button click from P in T1 will open a new window and the first button click from P in T2 will open another window. Subsequent clicks in T1 and T2 will reuse their existing window(s) respectively. But the window created by T1 cannot be used by T2 and vice versa, even though they are from the same domain D.

In IE6, 7, 8 & Firefox, T2 can access the window opened by T1 and all clicks in T1,T2 reuse the same window. The bottom line is Chrome creates 2 windows for a scenario where every other browser does only one. You can probably argue, Chrome does it right and 2 pages from same domain in separate processes shouldn’t be allowed to talk to each other.

Well, in IE6 every window is a new process, but that allowed 2 pages from same domain use the same popup window. Ok, I cannot win any argument these days by quoting IE6. But IE8 has a multi process architecture too. It does it right.

How does this affect you? It may not, but its good to know. Does this make me hate Chrome? Not at all.

Is this a bug or its intentional behavior? Any thoughts?

Fixed Header Table using jQuery

Tue, 28 Jul 2009 00:00:00 -0500

This is yet another jQuery plugin to provide fixed headers for tables. It differs in the way that it does not require any odd html table semantics. It just needs a TABLE tag with THEAD and TBODY to work its magic.

How it works?

Simple. It takes a TABLE, pulls the THEAD and TBODY out of it and puts them into two separate DIVs. Now, the DIV which THEAD (header-div) goes is overflow restricted. The DIV the TBODY (content-div) goes to allows vertical overflow. That’s it. Since the content-div can have a vertical scroll bar, the header-div cant. We have our table with fixed header. Thats it. The plugin takes care of aligning the columns. So, as a plugin user, you dont have to worry about the alignment.

Now, the gotchas. For extremely large tables (thousands of rows and tens of columns), you will see a delay in the page load, because the plugin rearranges the DOM. This doesnt mean that this plugin cant be used for large tables. There is no strict definition of “large”. So, dont hesitate to try it on a large table.

jQuery Plugin Site

Fixed Header Sample

Fixed Header Multiple Tables

Auditing using Interceptors in Hibernate

Fri, 26 Jun 2009 00:00:00 -0500

This would probably work only in Hibernate 3. Its loosely based on https://www.hibernate.org/48.html. I am showing a very basic example which sets the created time in a property when an entity is inserted and the updated time in another property when its updated.

Hibernate allows interceptors to be registered and calls it when an entity’s state changes during its lifecycle. Refer the Interceptor documentation for information on its methods. The method names give you an idea of when it gets called.

In order for the Interceptor to identify the entities to be audited, the entities implement an interface. Like this

AuditStamp contains the audit information that is set or updated by the interceptor. It can range from simple datetime to user information. The AuditStamp class shown below just has dates, but more can be added as needed. The advantage of having it as a separate class is that when more audit information needs to be added, the entity implementing Auditable remains unaffected.

This AuditStamp class is mapped in Hibernate using a custom type

Refer the CompositeUserType documentation to see how this type is implemented. Now the Interceptor is also a minimal implementation, it can be enriched as needed.

Interceptors are little if you need to change the state of an entity. Even though the first parameter in onSave and onFlushDirty is the entity itself, changing the state of it does not seem to work. Instead the third parameter contains the values of all the properties in the entity in the same order as property names are specified in the fourth parameter.

The setValue does the magic of finding the index of the property and setting the value.

Interceptors come in two flavors: Session-scoped and SessionFactory-scoped.

A Session-scoped interceptor is specified when a session is opened using one of the overloaded SessionFactory.openSession() methods accepting an Interceptor.

Session session = sf.openSession( new AuditInterceptor() );

A SessionFactory-scoped interceptor is registered with the Configuration object prior to building the SessionFactory. In this case, the supplied interceptor will be applied to all sessions opened from that SessionFactory; this is true unless a session is opened explicitly specifying the interceptor to use. SessionFactory-scoped interceptors must be thread safe, taking care to not store session-specific state since multiple sessions will use this interceptor (potentially) concurrently.

new Configuration().setInterceptor( new AuditInterceptor() );

That’s it.

The AuditStamp is specified in the hibernate mapping as a custom type. A typedef can be used as well.

Authoring Custom Namespaces in Spring 2.0

Thu, 05 Apr 2007 00:00:00 -0500

This post is a republish of the article I wrote for TheServerSide.com. You can find it here.

Starting from version 2.0, Spring supports XML Namespaces. The purpose of this article is to discuss the new XML schema based configuration available in Spring 2.0. Familiarity with previous versions of Spring and basic AOP terms is assumed. Spring now supports and recommends usage of XML Schema rather than DTD. As users of previous versions, you might remember using the <bean> tag and its structure being declared in a DTD. Instead, this is now declared in a XML schema (spring-beans-2.0.xsd). Rest assured, the DTD configuration is 100% legal and is fully supported in Spring 2.0. DTD has its limitations and modern IDEs encourage using XML schema to fully utilize features like auto-complete that comes handy during XML authoring. In the old-fashioned bean style configuration the developer has to know the name of the appropriate factory or proxy beans. Everything is a bean with a proxy or factory class and a different set of attributes. Transaction, caching, security etc are implemented using appropriate proxy classes and configured using the properties in XML. This makes the XML verbose and it also exposes the internal classes of Spring. These factory or proxy classes are never called in the code directly. It makes perfect sense to hide them from the developer – one of the reasons for the shift. Schema based configuration greatly reduces XML plumbing and eases authoring.

An example would make this clear,

This is how transaction management is done in earlier versions,

Now,

tx is the namespace of the tags that declare the transaction manager ‘txManager’ as an advice. The aop tags define the pointcut and the advisor which complete the aspect declaration. The execution expression used in the expression attribute of pointcut tag is explained in detail in the Spring documentation. Namespaces hide the internal classes from the developer. For the Spring IoC, everything is a bean and the namespaces are linked to beans using configuration, explained in a later section. The namespaces are fully customizable and extensible. Customizable – Additional attributes can be added to existing tags. Extensible – New set of tags can be developed and used in the configuration. Spring comes bundled with namespaces for common purposes like,

The util tags deal with common, utility configuration issues, such as configuring collections, referencing constants, and suchlike.

The jee tags deal with JEE (Java Enterprise Edition)-related configuration issues, such as looking up a JNDI object and defining EJB references.

The lang tags deal with exposing objects that have been written in a dynamic language such as JRuby or Groovy as beans in the Spring container.

The aop tags deal with configuring all things AOP in Spring: this includes Spring’s own proxy-based AOP framework and Spring’s integration with the AspectJ AOP framework.

The tool tags are for use when you want to add tooling-specific metadata to your custom configuration elements.

The beans tags that is present since the inception of the framework.

A more detailed explanation of these tags is available in the Spring documentation (see Resources).

Custom Namespace

Having said about the existing tags lets move on to the creation of custom ones. The creation is a four step process,

Author an XML schema for the namespace.
Code a NamespaceHandler linking the namespace to JavaBean.
Code a BeanDefinitionParser that parses the XML and builds the JavaBean.
Link the namespace to Spring i.e. make Spring aware of your namespace.

The four step process is illustrated here with an example. Our custom namespace is called as log and it exposes logging as an aspect. Spring AOP only supports method pointcuts, so our log tags provide logging of method arguments, return values and thrown exceptions. All these are done by the tag and can be enabled for an application through configuration. Logging comes to the methods for free and not even a single line of code is necessary. This is quite similar to how transaction works as an aspect. Methods in the service won’t be aware that they are inside a transaction. Logging is also one of the many cross cutting concerns (aspects) that an enterprise application has to deal with.

Authoring XML Schema

For creating the schema, you need to have an idea of how the actual tags would look like. Our log tags look like,

The advice tag declares logging as an advice and assigns an id to it. This id is later used in the configuration while defining an aspect. The args tag enables logging of method arguments with the level, if specified, returns and throws tag for return values and exceptions respectively. The level attribute is optional and defaults to INFO for args, return and ERROR for throws.

The schema looks like this,

The schema is self explanatory. Enumeration is used to restrict the values for the ‘level’ attribute. It only allows the standard logging levels INFO, TRACE, ERROR, FATAL, DEBUG and WARN.

Coding the NamespaceHandler

The namespace handler links the tags under the namespace to an XML parser (BeanDefinitionParser). Whenever a tag is encountered in configuration, the Spring IoC calls the associated parser registered through the namespace handler. All namespace handlers need to implement the NamespaceHandler interface. As you might expect, much of the mundane code required for implementing the interface is already done by the abstract class NamespaceHandlerSupport. LogNamespaceHandler is the handler for the log namespace. The method which we are concerned about is the init.

Coding the BeanDefinitionParser

As I already mentioned, everything is a bean to the Spring IoC. In any XML backed by a bean, the attributes in the XML map to the properties in the bean. The function of the parser is to get the values of attribute and populate them in the appropriate properties of the bean. The BeanDefinitionParser does this indirectly; it doesn’t get direct access to the beans associated with the tag. Instead it builds a map of Javabean property names and values retrieved from the XML attributes called as a BeanDefinition. After calling the parser, the Spring container populates the JavaBean using the BeanDefinition(s). A significant advantage of this approach is that the XML attribute names and JavaBean property names need not match.

Now the question arises, how the container knows which JavaBean to populate. The answer is it doesn’t know we have to tell it using the getBeanClass method in BeanDefinitionParser interface. LogBeanDefinitionParser is the parser for our advice tag,

The registered JavaBean for the advice tag is SimpleLogger. Note that the doParse method gets a reference to the BeanDefinitionBuilder which is responsible for building the BeanDefinition(s). The SimpleLogger is defined as follows,

Please see the highlighted code to get a glimpse of how BeanDefinitions are built. If the args tag is present then argsLogEnabled is set to true. It’s the same for the return and throws tags. Similarly, if the ‘level’ attribute is present, its set accordingly based on the tag it’s present in. For example, if it’s present for args tag, value will be set in the argLevel property.

Linking to Spring

Here comes the configuration part. Don’t panic, there is no XML.We need to deal with two properties files, spring.schemas and spring.handlers.

spring.schema specifies the location of the XML schema definition,

http\://www.theserverside.com/spring/log=SimpleLogger.xsd

spring.handlers links the namespace to the NamespaceHandler,

http\://www.theserverside.com/spring/log=com.spring.aop.test.LogNamespaceHandler

Using the handlers file, Spring knows which NamespaceHandler to call when log is encountered in the configuration.

Please note that these two files should be present in the META-INF directory of your JAR. In fact, if you open the spring.jar under the META-INF directory, you can see the details of all the schema and handlers for the namespaces that comes with Spring.

That’s all! You can now package your classes, schema and properties files in a JAR. If this JAR is available in your CLASSPATH, you (or anyone) can use it as if its part of Spring.

SimpleLogger – The Interceptor

I can imagine you wondering where is the code for logging. The steps above are what Spring expects us to do for every custom namespace. As I mentioned earlier, the log exposes logging as an aspect. For logging method arguments, our interceptor needs to implement MethodBeforeAdvice, for return values AfterReturningAdvice and for exceptions ThrowsAdvice. I am using the SimpleLogger for implementing the interfaces.

In AOP terms, an aspect consists of an advice and a pointcut. Our log namespace tags define the advice. We use the Spring aop tags to define the pointcut and henceforth the aspect.

Note that the tx example shown earlier resembles the above configuration. The pointcut is defined as all classes within the class com.spring.aop.test.ServiceImpl. Note that the id ‘logAdvice’ is referred in the advice-ref of advisor tag. The above configuration

Defines a fooService which is an instance of com.spring.aop.test.ServiceImpl
Enables logging of arguments, return values and exceptions for all the methods of ‘fooService’.

SimpleLogger component follows the Spring principle of eliminating cross cutting concerns from business objects. The fooService is a POJO and its methods are not aware that they are being logged. Using the execution expression, the pointcut can be customized and hence it’s possible to apply this logging advice to an entire application. This is how tx tags work, methods in the DAO (or any service) wont be aware that they are inside a transaction.

Running the code

The code requires the following libraries,

Spring 2.0
Commons Logging
Log4J

Run the TestSimpleLogger for a demonstration. You can also add the JAR file to your CLASSPATH and use the SimpleLogger in your own applications. Please refer the spring.xml for a usage example.

Conclusion

Spring’s shift to XML schema configuration is a step in the right direction. It revolutionizes the way developers work with Spring and bootstraps a budding component market too.

Resources