cdi and deltaspike are very powerful and in several cases all you need. some might argue that other containers like spring have a richer ecosystem. integrating 3rd party frameworks is usually not a big deal and several even provide a nice api (which doesn't require an additional wrapper or api-layer). however, if there is a good reason why one of the additional spring-projects would be nice to use, it's usually also possible to integrate/use it in a cdi-based application via a cdi-spring bridge. in combination with deltaspike it's easy to implement it.
ds-spring-bridge-addon is one of such two-way bridges. it allows to inject spring-beans into cdi-beans as well as cdi-beans into spring-beans as long as the used concepts (like qualifiers,... are compatible).
per default the bridge will bootstrap the spring-container as soon as it is needed. in case of web-applications, it's possible to use WebappAwareSpringContainerManager (which also delegates to the context-loader of spring). as shown in the tests and examples, it's possible to use it with plain java-se, servlet-containers like tomcat as well as ee-containers like tomee.
apache deltaspike provides an improved version of the view-config known from apache myfaces codi. one of many big advantages is the type-safety (even for navigation).
the only missing part is the validation against real files and folders. however, if your view-ids correspond with the real file-names (which is good practice anyway), it's easy to do it manually:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
in an ee6+ application-server it's possible to annotate this class with @WebListener (-> no further config is needed). in case of a manual cdi-setup (e.g. with tomcat), it's needed to configure the listener after the listener of the cdi-implementation (because cdi needs to be bootstrapped before this listener gets called).
with all versions after v0.5, deltaspike will do this check out-of-the-box.
the container-control module provided by deltaspike is very powerful. recently i created a simple cdi integration for junit based on this module. integrating a scheduler like quartz is even easer. therefore i prototyped a very simple (= only cron-expressions are supported) deltaspike scheduler add-on. the default-implementation delegates to quartz, however, it's possible to integrate it with any scheduler (if cron-expressions are supported).
the major use-case is simple. just annotate your job-implementations (in case of quartz: org.quartz.Job) with @Scheduled(cronExpression = "[your expression]") and it will be scheduled/installed automatically at the end of the bootstrapping process.
it's possible to use cdi based injection:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
furthermore, the request- and session-scope get started (and stopped) per job-execution. however, it can be controlled via @Scheduled#startScopes and it's possible to provide a description as well as a type-safe job-group.
beyond that it's also possible to inject the scheduler and control (scheduleJob, interruptJob, startJobManually,...) it manually - e.g.:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
With 'false' for @Scheduled#onStartup it's even possible to schedule/install jobs dynamically - e.g.:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
arquillian is nice, however, several projects don't need/use it.
several of them implemented a custom approach to control the cdi-container, start/stop scopes and check invalid state (esp. after a failed test). usually the basic tasks are the same or very similar. therefore i prototyped a deltaspike test-ctrl add-on based on some use-cases:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters