Back then, none of projects required groups or users to inheriting permissions. I simply gave permissions to the roles and individuals that needed them. So, I used an AffirmativeBased AccessDecisionManager, and placed a RoleVoter before any other AbstractAclVoter. Simple, and it worked. One of my newer projects, however, does require the inheriting permissions.

What else…

Since I always use GUIDs, I still don’t need Spring Security to know the the domain class. But I’d like to utilize the new auditing feature. I’d also like to turn on and off auditing at the permission entry level. All in all, the upgrade wasn’t too bad at all. I had move some code from the SimpleAclEntry (deprecated) to the BasePermission. I actually extended the BasePermission, as the javadocs suggest.

Spring-Security’s distributed example code uses JDBC. Which is fairly straight-forward. It keeps a good amount of the information on the acl entry table. Thus no real need for a parent acl table. Well, since I’m using Hibernate, a few things automatically change:

• Built-in 2nd level caching (ehache for me)
• Ability to define granular joins and fetches based on the context

Based on those two (three?) items, I was able to normalize a good amount of information back to a new parent table permission (acl?). Now permission entries can focus on one purpose, facilitating a relationship between their parent permission and the target SID (Secure ID). See my pared-down ERD for this:

I’m not big on defining AOP behavior via the newer namespaced expressions. So, in that context, I stayed with what I had before. Some other things have been deprecated, such as BasicAclEntryAfterInvocationProvider, in favor of AclEntryAfterInvocationProvider. Overall, it was pretty painless.

One more thing…

When it comes to ACLs, the was one thing that drives me crazy is having to define the default relationships in SQL scripts. I freaking hate it. Well, I was able to resolve that this time around: Added a task and some delegation to my existing ServletContextListener. At application start, it goes about finding existing objects that need securing, that aren’t already secured. Yeah, that’s great…

Recently I decided to leave the 2.0.x series, and upgrade to the 2.1.x path. After a little work, you can piece together the major changes you need to adhere. For me, the biggest change was the built-in Dojo support. As of 2.1, it’s an optional, external module, which is fine. I went about making the changes. Things like changing my theme from Ajax to XHtml. Importing the Dojo taglibs into the necessary pages. Nothing too complicated. More time-consuming than anything.

OK, so I ran into a problem. I worked at it for a good weekend. After banging my head against this one, with no resolution, I sought help on the user-list. No response. None of this really bothered me. What really bothered me was my naiveté.

The affected projects are all on svn. For some reason, I did the upgrade on HEAD. So, after no resolution, I had to revert. Since the upgrade included some other libs (Hibernate-3.3, some Commons modules, etc), I actually had to revert and then reapply some other upgrades.

Regardless of your personal feelings for a framework/library, don’t ever assume it’s going to be that easy! If you have a source control tool, use it. A branch for these upgrades would have made things a bit easier. I used to think branches were for teams larger than 2-3. Yeah, not so much. It’s not a problem to adopt a release/technology early, it’s all in how you do it. Ugh, lesson learned.

Well, now Greg Luck’s taking it to the next level. By moving to a minimum JDK of 1.5, he’ll be able to remove all dependencies. Also, ehcache-1.5 was a performant module. Now, if his figures are right, ehcache-1.6 will truly obliterate its peers. It’s still in beta, 1.6 that is, but check it out.

I knew the item being placed in the http session held a reference to a spring-wrapped DAO (the item’s a data view helper). So, after some cups of coffee it finally came to me: have my custom listener defined in the web.xml, which currently only implements ServletContextListener, also implement HttpSessionListener. With that, I was able clear out the culprit on sessionDestroyed(…). I wish all my technical problems were this straight forward.

Update: Anjan, in response to your question, I’m embedding the web.xml declaration and the actual Listener code. Hope this helps.

web.xml listener declaration

   <!--    Our custom system initializing listener     -->
   <listener>
      <listener-class>com.some.company.SomeInitListener</listener-class>
   </listener>

Listener Implementations

public class SomeInitListener extends BosenInitListener {

	private static final Logger LOG = Logger.getLogger(SomeInitListener.class);

	@Override
	protected void customInitForServlet(ServletContextEvent event) {
		super.customInitForServlet(event);

		ServletContext servletContext = event.getServletContext();
		SomeResourceInitializer resourceInitializer = (SomeResourceInitializer) getBean(servletContext, "resourceInitializer");

		// Make default menus
		String menuConfig = servletContext.getInitParameter(AppConstants.MENU_CONFIG);
		if (null != menuConfig) {
                    ...
		} else {
			LOG.warn("Could not find a menu configuration.");
		}

		resourceInitializer.init();
	}
}

public abstract class BosenInitListener implements ServletContextListener, HttpSessionListener {

	private static final Logger LOG = Logger.getLogger(BosenInitListener.class);

	public final void contextInitialized(final ServletContextEvent event) {
		String servletContextName = event.getServletContext().getServletContextName();
		if (LOG.isInfoEnabled()) {
			LOG.info("Initializing [ " + servletContextName + " ]");
		}

		customInitForServlet(event);

		if (LOG.isInfoEnabled()) {
			LOG.info("Initialized [ " + servletContextName + " ]nn");
		}
	}

	public final void contextDestroyed(final ServletContextEvent event) {
		String servletContextName = event.getServletContext().getServletContextName();
		if (LOG.isInfoEnabled()) {
			LOG.info("Destroying [ " + servletContextName + "]");
		}

		customDestroyForServlet(event);

		if (LOG.isInfoEnabled()) {
			LOG.info("Destroyed [ " + servletContextName + "]nn");
		}
	}

	protected void customInitForServlet(final ServletContextEvent event) {
		ServletContext servletContext = event.getServletContext();
		String appContextName = WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE;
		Object webCtxAttribute = servletContext.getAttribute(appContextName);
		if (null != webCtxAttribute) {
			if (webCtxAttribute instanceof Exception) {
				LOG.error(webCtxAttribute);
			}

		} else {
			throw new IllegalStateException("Could not read applicationContext.xml.");
		}
	}

	protected void customDestroyForServlet(final ServletContextEvent event) {
		//no-op
	}

	public final void sessionCreated(final HttpSessionEvent event) {
		String sessionId = event.getSession().getId();
		if (LOG.isDebugEnabled()) {
			LOG.debug("Initializing a new Session [" + sessionId + "]");
		}

		customInitForSession(event);

		if (LOG.isDebugEnabled()) {
			LOG.debug("Initialized a new Session [" + sessionId + "]");
		}
	}

	public final void sessionDestroyed(final HttpSessionEvent event) {
		String sessionId = event.getSession().getId();
		if (LOG.isDebugEnabled()) {
			LOG.debug("Destroying an existing Session [" + sessionId + "]");
		}

		customDestroyForSession(event);

		if (LOG.isDebugEnabled()) {
			LOG.debug("Destroyed an existing Session [" + sessionId + "]nn");
		}
	}

	protected void customInitForSession(final HttpSessionEvent event) {
		//no-op
	}

	protected void customDestroyForSession(final HttpSessionEvent event) {
		HttpSession session = event.getSession();
		session.removeValue(BosenConstants.SESSION_PAGINATED_SEARCH_RESULTS);
		session.removeAttribute(BosenConstants.SESSION_PAGINATED_SEARCH_RESULTS);
	}

	protected static ApplicationContext getApplicationContext(ServletContext servletContext) {
		String appContextName = WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE;
		return (ApplicationContext) servletContext.getAttribute(appContextName);
	}

	protected static Object getBean(ServletContext servletContext, String name) {
		return getApplicationContext(servletContext).getBean(name);
	}

One to watch: Leonardo Goncalves’ Goods Donation System great idea that also made it to the finals. This could be a great help to many non-profits in the near future. Congrats to everyone who had the creativity and drive to submit anything to the challenge. I’ll be watching to see who gets 1st…

See here for more info.

So, I’m going with Spring-2.5.3 for my AOP and DI needs; easy choice. Hibernate-3.2.6 for ORM (I’m staving off JPA, for as long as I can!). MySql-5.0 for database. The UI… Well, I haven’t decided. I know I have to start moving away from WebWork-2. This isn’t up for debate. But I’m torn between moving to Struts-2 (familiarity) or JSF (component-based). I read this FAQ entry for the differences between Struts-2 and JSF.

Ehh… here’s to new things: I’m going with JSF. I’ll take a serious look at Seam and MyFaces.

*****

Update: After some discussion, and further research, I’ve decided to hold off on using JSF. Since it’s a fairly mature, event-based API, I definitely see myself using it in the near future. However, since scalability is the currently highest priority, I’m compelled to go with Struts-2. This also allows me to upgrade all my existing WebWork-2 projects…