Different approaches for Dependency Injection (DI)

 Objectives of dependency injection

1. To perform their functions, classes depend on other classes as units of reuse. These other classes need to be initialized and a lot of times need the caller to pass the initialization arguments. This need for initialization makes the two classes: caller and callee dependent on each other i.e. they are tightly coupled. Thus, any change in initialization process of callee warrants a change in the code of the caller. Dependency injection removes this need.

2. The above problem is also addressed using factories where the initialization is moved to a third class which when requested for a callee object, initializes and returns it. This separates the initialization from the logic of the callee but keeps the problem as is. Now the factory code needs to be changed if callee is changed.

3. Factories are also used to support strategy pattern where the logic is interface driven and implementations are driven by the environment, user choice or even discovery of new algorithms. In such cases, to provide different implementations to the user, not only these new implementations need to be provided but also Factories need to be made aware of the new implementations and hence, need to be recompiled

Dependency Injection approaches and their differences

XML based (Spring)	Annotation based (Guice and Spring annotation based configuration)
Understanding object graphs requires reading fully qualified class names which cannot be browsed by IDE features	Understanding object graphs is simpler as it is not dependent on Strings. The dependencies are declared in a Java file
No compile time help for mismatched dependency i.e. type safety is not enforced	Compile time help for mismatched dependency is available and the type safety is enforced
Dependencies becomes more like configuration http://www.theserverside.com/feature/Spring-vs-Guice-The-Clash-of-the-IOC-Containers	Dependencies are still code. Just as Factories need strings to match references to implementations, annotation based DI need ‘reference types’ (mostly their class objects) to be bound to their implementations http://code.google.com/p/google-guice/wiki/BindingAnnotations
Dependencies can be changed without compilation	Dependencies cannot be changed without compilation
Different instances can have different implementations	Different instances cannot have different implementations if class type is associated as described above. To achieve this, named configurations need to be used for different instances which do not allow compile time checks http://code.google.com/p/google-guice/wiki/BindingAnnotations
Third party libraries can both be injected into the project and the project can also inject dependencies in them http://stackoverflow.com/questions/1509757/injecting-log4j-loggers-with-spring	Third party libraries cannot be supported out of the box. http://code.google.com/p/google-guice/wiki/CustomInjections

Conclusion

It can be summed up from the discussion above that those software which require being highly configurable, or support multiple implementations of an interface, or support various environments, or support plug and play architecture would do better to stay away from annotation based DI.

Annotation based DI is good for projects which support compilations between various deployments e.g. IT projects servicing single client. Since Annotation based DI provide compile time type safety, it can substantially reduce the development effort.

References

1. Example of 3^rd party DI for Guice: http://code.google.com/p/google-guice/wiki/CustomInjections
2. A very succinct and to the point Guice tutorial: http://www.factorypattern.com/google-guice-tutorial/
3. High level Guice vs Spring comparison with a bias towards annotation based DI provider Guice: http://www.theserverside.com/feature/Spring-vs-Guice-The-Clash-of-the-IOC-Containers
4. Spring vs Guice comparison of each other’s annotation based DI  capabilities: http://www.theserverside.com/feature/Comparing-Spring-vs-Google-Guice-By-Example
5. Spring vs Guice with a bias towards XML based DI provider Spring http://www.javalobby.org/java/forums/t103070.html
6. Example of 3^rd party DI for spring: http://stackoverflow.com/questions/1509757/injecting-log4j-loggers-with-spring
7. Guice tutorial: http://code.google.com/p/google-guice/wiki/GettingStarted
8. Spring reference: http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/

Image shack API documentation and examples

 I have been trying to use imagechack's image hosting api for fewbs. Their documentation is good for reference but not really good enough for a beginner. Next obvious step was googling and I found a lot of interesting sites giving examples on various technologies e.g.

PHP -
http://elliottback.com/wp/using-the-imageshack-xml-api/
.NET C#
http://www.codeemporium.com/2009/06/14/dot-net-c-sharp-wrapper-for-the-imageshack-xml-api/
Ajax - HTML
http://www.blocsoft.com/blog/imageshack.asp
http://code.google.com/p/imageshackapi/wiki/RedirectAPI

Its a wonderful service for small site owners and needs to be emphasized and supported as much as possible.

Accessing session objects with GWT and Spring security

There are several tutorials on how GWT and spring can be integrated (e.g. and )and they have done a good enough job for me not to cover those topics in details.

I found details scarce on how to use sessions in GWT environment to store and retrieve values during the rpc calls.

Problem:
Spring security by its design runs, by default, using url rewriting i.e. it appends ';jsessionid:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' to the url of authenticated page. This jsessionid is sent to server again when another page is requested. In this way the request is assumed to be coming from the same user.

The problem with this approach is that there is no way you can append jsessionid field to the rpc call url due to which the call is not authenticated. In case you put rpc call's access as authenticated (using access="ROLE_XXX" or access="isAuthenticated()" etc.) none of the rpc call succeeds. In case, you did not put rpc call access as authenticated, principal received on these calls is "anonymousUser" and a new session id is assigned to each request and thus whatever you stored in a session last time is inaccessible

Solution:

Solution is strikingly simple. Use cookies to do this stuff. For this to work you need to the following
1) in spring security 3+ security configuration disable url-rewriting
....
2) Allow your server to use cookies for session management. For tomcat 6, I was using, this can be done by setting 'cookies' field to true in context.xml in conf folder. It can be found in more detail @ and other pages given in its "related questions"

Voila! everything works and session object on server side can be retrieved using the following code

HttpSession curRequest =
((ServletRequestAttributes) RequestContextHolder.currentRequestAttributes())
.getRequest().getSession(false);

UPDATE

I stumbled upon a way to access request object and hence the underlying session by a simpler method. GWT exposes the current request by method getThreadLocalRequest. From request object session can be obtained. More details can be found at javadoc.