Consider a Few Issues with the Prototype

Team. There are a few issues in the servlet source which we should address.

Firstly, the directory.xml map of view model objects should only be created once and placed in the session object. So, the expensive method calls for building the document object model will only occur once. Also, the DOM eventually will be garbage collected since the references to it will stop existing after the directory.xml reading method.

Secondly, the exception message should be removed from the session object after it has been read in the exception handler method. There also might be some more issues. Any comments would be greatly appreciated.

Thirdly, the Hibernate transaction which we use is extremely simple. We should also create more complex examples that represent inner and outer joins with complex criterions plus Hibernate Query Language (HQL) functions such as count, sum, or avergage. This will likely occur after completing the prototype during the first iteration of development.

Fourthly, we should create other sample extensions for connecting with RESTful webservices and using SOAP messaging with the prototype.

Fifthly, we should also create some samples which do not use object-relational mapping for database transactions and rely soley on JDBC and ANSI SQL. These examples and with the Hibernate examples should use each of the Create, Read, Update, and Delete (CRUD) operations common in database application programming.

Sixthly, we also should consider using the redirect and forward features of the response object with JSP pages. Most likely, we will simply allow the rendering method writer the option of calling these methods from the response object. This only should discard any content which the servlet was building without causing a significant disruption in the application.

Seventhly and finally, we will review the source for an outstanding issues not mentioned above.

Plan. Plan. Plan. We had a tentative project plan for the prototype which we should follow. Let us review that over the next couple of days and see how we can incorporate some of these goals in the final few weeks of the plan.

The prototype must be complete in a few weeks and the source available on http://java.net/projects/caboose. A tentative presentation on CABOOSE is scheduled for a JAVA User's Group (JUG) in January or February. It should be fun and a source of valuable feedback.

This project, thus far, has been enjoyable. If not widely adopted, the author will at least have a base of reusable software for future development as a professional engineer. Servlet creation with CABOOSE might also benefit from the automatic code generation found in popular integrated development environments such as NetBeans. Given the directory.xml file, one has all the information needed for producing stencil handling classes with rendering method stubs.

These stubs all have the same signature:

String methodName( HttpServletRequestWrapper,HttpServletResponseWrapper ) throws Exception.
This would greatly speed up development and reduce the introduction of errors. However, this is a long term goal.

Also, recreating the Struts or Spring MVC is not our design goal. We seek a greater simplicity and further reading on each of these should be done. Feedback from anyone with extensive knowledge of both of these MVC would be appreciated. Also, we hopefully are not simply complicating a set of features already found in JAVA Server Pages and Faces. From my experience teaching servlet and JSP technology, CABOOSE will simplify and speed development. 

Certainly, you are still sorting through the source code posted from 12.29.2014. You will not be overburdened with a long message today. Happy Coding. La-La.