subclass.
If a CriterionType has in the resource column an enum matching the Resource super class, it has to be possible to
assign it to a subclass of Resource (Worker).
The source code has been refactorized to use @Repository in DAOs and @Service in services and models. This way, DAOs, services and models do not need to be defined in the Spring configuration file.
Conversational aspects have been commented in IWorkerModel. Conversational aspects include: (1) the state of the worker being edited/created and (2) the order of method invocation (protocol). Implementations of IWorkerModel can have additional state (such additional state is transparent for the clients of IWorkerModel).
Now the business layer uses org.springframework.jdbc.datasource.SingleConnectionDataSource as data source. Potentially, this data source is faster than the previous one (org.springframework.jdbc.datasource.DriverManagerDataSource). SingleConnectionDataSource only mantains one connection which is never closed. It cannot be used from more than one thread in parallel.
Now the "checkVersion" method also checks if the version of the entity passed as a parameter to "checkVersion" is null. If so, the check is considered to be sucsessfull (because an entity with version == null is considered a new object, that is, an object which does not exist in the database).
GenericDaoHibernateTemplate was an alternative implementation to GenericDaoHibernate. GenericDaoHibernateTemplate forces developer to use the Spring's Hibernate helper API, while GenericDaoHibernate forces developer to the use the Hibernate native API. Since Spring's Hibernate helper API does not provide much value over the Hibernate native API, we have prefered to use GenericDaoHibernate as default base class for DAOs.
The Maven Jetty plugin has been updated to version 6.1.18. Apart from being a more stable version that the previous one (6.1.12.rc2), it adds the <reload> configuracion option (available from version 6.1.18 onwards). In particular, the plugin has been configured with <reload>manual</reload>. This way Jetty does not scan for changes to project files. Instead, it is necessary to hit "ENTER" key on the Jetty console whenever we want Jetty to reload the application.
Manual reloading has a number of advantages over automatic reloading:
+ ZK can manage by itself the reloading of .zul pages (without intervertion of Jetty).
+ Whenever a developer creates/modifies "n" non ZK-managed files (e.g. .java files) to develop/fix a feature, she/he hits RETURN (after all modifications are done) to verify the changes, causing Jetty to reload the application only once (instead of "n" times when using automatic reloading).
Minimizing the number of times Jetty reloads the application is important, since class loaders do not release memory properly after reloading (in consequence, after a number of reloads, Jetty must be restarted; as usual, JVM memory options can also be used to increase available memory if desired).
* The structure for this entity has been created
* Basic implementation relays on Task and an empty TascContainerBean
* For visual presentation the same task div is used with background images for the corners and restyled classes.
