JSF CRUD application data service architecture

The generated application data service compiles and works as a standalone module. There are two methods of deployment:
1. Compile the module separately and add it as a jar file to the server's "lib" directory
2. Pack the module within the application's war file

Using method 1, other applications may also use the functionality of the data service by simply creating a bean of its class in their Spring application context.

The generated application data service class has a @PostConstruct initialization method which has to be called in order to start the service. Before initializing the service, one can choose between a Mock implementation type or a Spring Data / JPA / Hibernate implementation type.

The application data service is a self-contained module which does not require any wiring or complex initialization.

The following code is an example of how to initialize the application data service inside an XmlApplicationContext:

<bean
    id="Worlddomination"
    class="com.evilcorp.blackops.worlddomination.services.WorlddominationService"
>
        <property name="implementationType" value="MOCK" />
</bean>

The application data service can then be @Autowired in any Spring-contained bean:

@Autowired
private transient Worlddomination worlddomination;

Note that the above source code references the "Worlddomination" service interface instead of the "WorlddominationService" implementation.

---

KNOWN ISSUE:
Version 1.0.0 has a hard-coded "MySQL5InnoDBDialect" within its inner application context.

---

The following picture is a high level representation of the structure of the generated application data service:

The application service class:
- implements the application service specification
- wraps all of the functionality
- references a DaoBundle interface to call the functionality of the selected repository implementations
- translates implementation-specific exceptions into application-specific exceptions so that they may be caught by the upper layers

The DAO bundle
- is an interface defining getter methods for the entity-specific repositories
- is implemented by both the Mock DAO bundle and the Spring JPA Hibernate DAO bundle
- the purpose of the DAO bundle is to group together repository classes related to a given implementation

The repository specification
- interface implemented by both the Mock repositories and the Spring-enabled repositories
- used in conjunction with the DAO bundle interface in order to provide an abstraction of the data layer

The Mock DAO bundle
- groups together in-memory implementations of the repository specifications
- in-memory repositories are being populated at construction time
- in-memory repositories use collections and lambdas to emulate DAO functionality

The Spring-enabled DAO bundle
- groups together Spring-enabled implementations of the repository specifications
- contains and inner Spring XML application context which initializes at construction time
- the Spring-enabled implementations are being initialized automatically by the inner application context
- minimal wiring may be observed in the contained "applicationContext.xml" file
- the contained "applicationContext.xml" file also provides the name of the data source which is expected to be found via the JNDI

The exception tree
The generated data service has a rich exception tree, distinguishing between initialization exceptions and three different kinds of runtime exceptions (pushing, pulling and expunging). The following picture explains: