In a perfect world, all of my Java-based projects would be using JSF 1.2 and Spring 2.0. The managed beans in my JSF FacesContext would blend nicely with my Spring-managed beans, and the scopes of all would interact smoothly. Unfortunately, this is not a perfect world, and while I strive to keep my projects in the proper technology stack, I do not always have control over the initial state of a client’s project. One of my current projects is a fantastic example of this. We are using JSF and Spring, but the JSF implementation is Apache MyFaces 1.0.9, and the Spring version is 1.2. The managed beans in the two technologies do not blend together nicely, and although there is a project that would seem to provide a solution (JSF-Spring), documentation is sparse and the required version numbers do not match up. The big obstacle here is that Spring (even version 1.2) provides some very nice annotational transaction management that the current codebase is using to great advantage. Unfortunately, in order for Spring to manage the transactions, the beans must be declared within the Spring Application Context. This leaves my JSF-managed web controllers out in the cold, and me looking for an elegent solution. My first attempt lead me to Spring’s DelegatingVariableResolver class, which provides the ability to refer to beans defined in the Spring Application Context through JSF value-binding expressions. I begin by creating a single GatewayController class that has a property for each of the web controllers that have already been created. I then move the web controllers from the JSF faces-config.xml file into my Spring applicationContext.xml file. After adding a <managed-bean> definition in faces-config.xml for the GatewayController class and binding the managed properties to the Spring beans, everything seems to be reachable from the JSF code. Unfortunately, Spring 1.2 provides only two bean scopes: singleton and prototype. These correspond to the JSF application and none scopes, respectively. But what about the session and request scopes that are available in JSF? It seems that there could be some trouble mixing certain scopes together. For example, what happens if I create a session-scoped JSF bean that references a singleton-scoped Spring bean? Logically it seems like I would get a new copy of the JSF bean for every session, but each would refer to the same singleton copy of the Spring bean. Given that a session-scoped bean would typically be declared only if the bean held session-specific data, this does not seem like a good solution. The idealist in my immediately yells out that I should upgrade the entire web application to Spring 2.0 (which supports the additional scopes that I want for JSF), but the pragmatist reminds me that I am dealing with an extremely large web application, and the ramifications of such an upgrade could be staggering in other parts of the system. I do not yet have a complete solution for this problem, but I will post more as things progress. If there are any suggestions out there, let’s have them…

Jivian Dynamics is a term that some friends of mine came up with to describe the unusual way that I approach my occupation. And what is that occupation? The short answer is DESIGN. In particular, the design of web sites and related marketing materials such as brochures, catalogs, business logos, etc. I approach these designs in the same way that I approach the rest of my life, with enthusiasm and methodical creativity. The word ‘Jivian’ is a strange programmer’s twist on my own name, James Monroe Adams IV. As anyone who has ever developed software for a large company will know, programmers often have to come up with short tags to represent themselves on things like comments in a code versioning system. The abbreviation that I have used for years is jiv. Since I have always had my own unique approaches to various problems in the programming world, fellow programmers on my team started referring to code with my tag on it as the ‘Jivian way of doing things.’ A good friend of mine once made a joke that I had my own theory on the way the world works, which he called Jivian Dynamics. I liked the name, so I thought it would work well as the title for a blog about my theories on web design. Which brings us succinctly to the purpose of this blog. This is a space where I can get some of my methodology oraganized and make it available to other people. I have a great deal of knowledge and opinions on just about everything relating to the world of software and web sites, and if there is anybody in the world that cares, this is the place to find it. Keep an eye out for future posts that might contain actual information…