Spring Framework model naming

It's been 3 months since I'd encountered any quirks! And I've been working on something new!

If you just want the TL;DR, skip to the bottom.

This time round, I came across a weird situation whereby Spring is unable to provide me a model name I'd expect on my JSP. The object was created as "WTSoupModel" (names have been changed, but the pattern remains the same), and you can probably see the issue immediately if you're somewhat familiar with this situation.

The MVC I've been building up had been mostly running smoothly thus far, until this. The controllers, models, and services have been annotated similarly to my previous modules. What went wrong was when I tried accessing this model that was provided by my Controller via the JSP.

I was expecting the name of the model accessible by the JSP to be "wtSoupModel", but it would always return true whenever I test with ${wtSoupModel eq null} until I dug deep enough. Initially, for the sake of the experiment, I added in the model from the sub-module I'd just completed, ReportModel reportModel, and of course, ${reportModel eq null} gave me false, as expected. Then I made sure the WTSoupModel was Serializable. And then I tried renaming it to WanTonSoupModel in full. Aha! It turned out that ${wanTonSoupModel eq null} was false. This means the issue was with the naming, because there wasn't much else to rule out.

Next, I proceeded to find out if there's anyway I could custom the model naming that reaches the JSP. Upon further investigation, I found this that led to this. Experimenting with it in my Controller proved it true.

Final fix (names have been changed):

@RequestMapping(value = "/wantonsoup", method = RequestMethod.GET)
public String viewWTSoupList(Locale locale,
   @ModelAttribute("wtSoupModel") WTSoupModel wtSoupModel,
    ...
   Model model) throws MSBException {
...
}

I still haven't figured out what Spring resolved the original WTSoupModel into by default. Let me know if you do.

Using CascadeType with Hibernate Reverse Engineering Tool

As of Hibernate (version 4.3.11-Final) it seems, silly little me was trying to figure out how to annotate the entity beans with the cascade instruction. I didn't think it made sense to edit the PojoPropertyAccessor.ftl and the likes of those templates for this, much less manually edit the sources after they are generated. It was actually simpler than that, but maybe so straightforward nobody in recent years (up to 2013) bothered to describe how this works.

        <foreign-key constraint-name="fk_1_2" foreign-table="tbl_2">
            <column-ref local-column="id" foreign-column="id"/>
            <one-to-one property="a" cascade="merge" fetch="select"/>
        </foreign-key>

The Cascade will be annotated accordingly with your (all-lowercase) selection from either org.hibernate.annotations.CascadeType or javax.persistence.CascadeType; same difference.

Spring + Hibernate + Wildfly: Finding the right match

While setting up a new project, I had to do a bunch of trial-and-error, in order to get the WAR package deployable on the application server. These are my findings thus far:

• Application Server: Wildfly 9.0.1.Final (formerly known as JBoss AS7)
• Application Framework: Spring 4.2.1.RELEASE
• spring-context
• spring-webmvc
• spring-orm
• ORM Framework: Hibernate 4.3.11.Final
• hibernate-core
• hibernate-c3p0
• hibernate-ehcache

Here are some of the problems I'd encountered, that I had to tackle as they appeared:

1.  java.lang.IllegalStateException: Could not locate SessionFactory in JNDI
• sessionFactoryName
• Ensure your hibernate.cfg.xml has these properties
• <session-factory name="mySessionFactory">
• hibernate.jndi.url
• hibernate.jndi.sessionFactoryName
2. org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
• Wildfly Administration Console > Configuration
• Subsystems > EE > View
• EE Subsystem > Global Modules
• 
• Add
• Name: org.dom4j
• Slot: main (prepopulated by default)
• Save
• Restart Wildfly
• What is not needed to be done:
• Adding of "Dependencies: org.dom4j export" into MANIFEST
• Manual removal/auto exclusion of dom4j JAR during Maven build
• Adding META-INF/jboss-deployment-structure.xml
3. JNDI/JDBC configuration
• The naming conventions can get rather confusing at times, but here's what worked in Wildfly:
• JndiObjectFactoryBean > jndiName = java:/jdbc/myDataSource
• Wildfly Admin Console > Configuration
• Subsystems > Datasources > View
• Configure your datasource 
• Ensure the JNDI name matches "java:/jdbc/myDataSource"
• Note that Wildfly requires the "java:/" prefix
• Edit: I have concluded that this is in fact no required as long the datasource name matches across your servlet-context.xml and the server configuration. Include this snippet in your web.xml
• <resource-ref>
      <res-ref-name>jdbc/msbDataSource</res-ref-name>
      <res-type>javax.sql.DataSource</res-type>
      <res-auth>Container</res-auth>
  </resource-ref>
4. org.hibernate.service.UnknownUnwrapTypeException: Cannot unwrap to requested type [javax.sql.DataSource]
• This led me to this
• In short, I had to configure the hibernate.cfg.xml to factor in settings for c3p0 as indicated
• Meanwhile, I also noticed that my Hibernate versions were all over the place;
• Adventurously, I experimented with Hibernate 5, or more specifically org.springframework.orm.hibernate5.HibernateTransactionManager to which came the complain from Wildfly: NoSuchMethodError ConnectionProviderInitiator.extractIsolation
• This was when I decided to take a step back and 
• reverted from Hibernate 5 to Hibernate 4;
• and added dependency and configuration for c3p0;
• Edit: I have isolated the cause of this occurrence during the Eclipsed Embedded Jetty deployment to be due to the presence of the "hibernate.connection.datasource" property in my hibernate.cfg.xml that seemingly requires the c3p0 set of properties. In short, don't bother including hibernate.connection.datasource since you will either already have it configured in the application server (e.g. Wildfly) or the jetty-env.xml file.
5. Configuration for application context path 
• This one was fairly straightforward:
•  Create WEB-INF/jboss-web.xml with the following:
  <?xml version="1.0" encoding="UTF-8"?>
  <jboss-web>
     <context-root>/myapp</context-root>
  </jboss-web>

My exploration continues...