Struts 2 issue

A dire emergency drove me to work on some substantial changes in in session handling and implementation of some security mechanisms.  While working on this, it became apparent that struts was not calling the execute method on some actions.  There was a good amount of logging added and not a single line was getting output.

For a brief moment, I thought I would have to immediately upgrade - it must have been a struts 2 bug. This may be the case but it was worked around.  Unfortunately, I did not have time to fully debug into struts to determine the true root cause.  The items that in some combination got things working again included:

1. Implement Action interface - we had implementations of the execute method with the correct signature but not as part of the Action interface.
2. Replace use of the old/deprecated filter with the use of the newer filter org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter
3. Wrap some code in try/catch and do some defensive coding to prevent null reference access
4. Use some API calls in a more consistent fashion so that sessions are created under more controlled circumstances.

I would love to go back and debug into the roof issue here but there is never time - part of the organizational culture.  As much as I am annoyed by the person/people responsible for instigating our issue, it has put security back into the light again (for now).  Security is not a static item and the cost of treating it otherwise is high in many ways ($, time, respect, etc). 

JSF 2 integrated with Struts 2 research

I have been trying to move application development out of the JSP ages for some time.  JSP is well known and numerous developers are capable of supporting it but in many cases the results are underwhelming.  Given more time, fewer projects and more senior developers maybe we could do a better job of making sure consistent JSP designs/implementations are always used.  The primary goals being improving quality, reducing errors and easing maintenance/enhancements.  The project work-load is only expected to increase over the next two years due to various grants and large projects already in planning/progress. The solution I decided on is the use of a component model (JSF 2) and related component suites.  This reduces the need for lots of custom JavaScript (and expert JavaScript knowledge) and gains a lot of cross-browser testing by communities supporting many of the JSF libraries.  The existing and upcoming applications/tools/utilities are using Struts 2 and JSP as the base technology but a "Struts 2 JSF plugin" allows integration into the Struts 2 environment.  There are some posts/comments indicating that Struts 2 with JSF might have some benefits over a purely JSF implementation (authors preferring the Struts 2 navigation from what I can tell).

I previously toyed with JSF 1 for some time and was put off a bit by it and poor tool support in older versions of Eclipse.  I had been toying with IceFaces 1.8 while trying to work with Mojarra or Apache MyFaces.  I like aspects of IceFaces but fear getting sucked into needing paid support or the commercial components.  There were also problems just getting it all working.  So I let this research stagnate for a long time.

Upcoming projects inspired me to look into JSF again.  I am pleased with the JSF 2 support in Eclipse (3.7.2) now.  I made a somewhat informed decision to switch over to PrimeFaces 3.2 from IceFaces.  I also switched over to Mojarra.  I am a fan of Glassfish (but use Tomcat more) so having this consistency (by using Mojarra) makes sense for now.  I had performed some research into RichFaces, IceFaces 2/3, Apache Trinidad and some others before settling on PrimeFaces.  It appears to have a good selection of components, reasonable performance and a helpful community.  There isn't anything fundamentally wrong with the others but this seemed like a better fit and initial prototyping was successful earlier than with other options. 

Even though integrating new functionality using JSF into a moderate sized Struts 2/JSP application isn't trivial, it is going reasonably well.  I hope to also replace some limited functionality with JSF over the next few weeks.  This will provide an opportunity to target internal-only users with the result of the much more refined functionality and help justify future updates which are public facing.

My only major disappointment is a lack of comprehensive examples which show small scale but somewhat realistic implementations specifically for JSF 2.  There is lots of JSF 1 information which doesn't reflect current best practice for JSF 2.  I expect to be working in the debugger and reviewing generated HTML for a while until I figure out good ways to promote efficient results.

As a side note, I also took a stab at integrating JBoss Seam but that wasn't going as well as hoped.  Again, there are some good things there but I prefer something which is an improvement and easy to get functional quickly.  I was spending way too much time trying to figure out Seam issues rather than generating useful work results.  If we ever have to convert to JBoss then this would likely be an easier move but in the foreseeable future Tomcat 7 is the best fit with JSF 2/Struts 2/PrimeFaces 3 with some Glassfish 3 thrown in here and there.  I dumped WebLogic - Swiss army knife which is bloated, expensive and hard to integrate into our overall infrastructure.