[slides] apache deltaspike

8th release of deltaspike -> v1

The Apache DeltaSpike team is pleased to announce the 8th release of DeltaSpike. It's v1.0.0!

[add-on] fast event processing with disruptor + deltaspike

cdi offers synchronous events. they are more like a decoupled method call. that's fine for a lot of use-cases.

in some cases the processing can take some time (in the observer method). a common trick is to use an ejb + @Asynchronous for the observer-method. with that the event-source can continue and the observer operates in a new thread.

however, that isn't enough if there is a huge amount of such events. for use-cases like that i've prototyped an add-on for apache deltaspike which allows to use disruptor for firing and observing events. it includes a simple qualifier support, however, it doesn't provide an 1:1 implementation of the cdi event rules. it can be used the same way as cdi events:

  and

the add-on creates a disruptor-processor for every observer methods. the method gets invoked on the cdi-bean itself. the cdictrl-module provided by deltaspike is used for starting the cdi request- and session-scope before an observer method gets called (and to stop it afterwards). with that the application-, session- and request-scope (as well as all scopes based on them which start autom.) can be used for such beans.
since the observer methods are invoked on the contextual-instance, cdi features like dependency-injection can be used as expected. the result is really nice. there is a huge difference in view of the pure event-processing performance of the events:

the result might look strange at the first view. however, the effects are quite clear. since the observer-logic in the demo is fast, the benefit of using @Asynchronous is lost. here the pure invocation of observers in ejbs is slower (than observers in a cdi-bean), because the container has to handle additional ejb features like transactions. the cdi bean as well as the stateful ejb is application-scoped and therefore only one (cached) instance is needed.

in the charts above it's hard to see, but the numbers show that tomee is faster in case of the deltaspike/disruptor add-on (due to the highly optimized proxies of openwebbeans 1.2.x) and as7 is a bit faster with dispatching standard cdi events.

currently the add-on works with tomee and as7 (tested with v7.2) and is available here. the repository also contains several tests, which illustrate the supported use-cases.

[add-on] mock cdi-beans with deltaspike

i've prototyped an add-on for apache deltaspike which allows to mock cdi-beans manually or with a mocking-framework.

an example for a simple cdi-bean:
an example for a simple manual-mock for the cdi-bean: an example for a simple mockito-mock for the cdi-bean: the same is possible in combination with qualifiers as well as with producers and @Typed beans.

the add-on is available here. the repository also contains several tests, which illustrate the supported use-cases. the tests use manual-mocks as well as mockito-mocks. however, you can provide any object as mock which is a subclass of the original implementation.

[add-on] monitoring lite with deltaspike

there are quite a lot of different use-cases for monitoring and auditing. for more advanced use-cases projects like apache sirona are reasonable. however, in several cases it's enough to have a simple interceptor which collects information (which can get processed at the end of a request). since a lot of projects implemented it on their own and end up with similar solutions, i've created an add-on for apache deltaspike which supports several common use-cases like exception monitoring, performance monitoring (via execution time) and auditing (with or without method-parameter values).

after adding the add-on to a project based on deltaspike the usage is simple, just annotate a method or the whole class with @InvocationMonitored and create a cdi-observer for MonitoredMethodInvocationsEvent. the add-on will collect information about the monitored method-invocations during a request and you can process the entries based on your requirements. the following example illustrates a sample usage. it's up to you which information you use and how you process it (e.g. logging it, storing it in a persistent store,...).


asynchronous processing is also supported via an @Asynchronous observer in an ejb.

the optional jsf module allows to record the current view-id per entry and the processing after the rendering-phase.

the add-on is available here.

simple cdi and ejb tests with deltaspike

apache deltaspike v0.6+ provides an easy to use, but quite powerful junit test-runner. it's based on the container-control api of deltaspike. deltaspike itself currently provides implementations for openwebeans, weld and openejb (tomee).

the last one is important, if you need to test a cdi+ejb based application. just by using a different container-control implementation (deltaspike-cdictrl-openejb) in your build config and adding openejb (/tomee) via org.apache.openejb:openejb-core, you can test cdi-beans as well as ejbs. just inject them as usual via @Inject (also @EJB works as expected).

an example can be found here.

[slides] flexibility with cdi and deltaspike

welcome cdiatwork.irian.at

today we announced a german book about cdi and apache deltaspike.
it's available at http://cdiatwork.irian.at

instead of publishing it at once, we do it step by step.
readers have the chance to provide feedback of any kind. therefore a github issue-tracker is linked in the menu. if you don't like to do it there, you can also contact me directly. every feedback is very welcome.

migrate codi 1.x to deltaspike 0.6

the myfaces-stack demo at https://github.com/os890/tomee_mf_stack_001 (later added to the tomee examples) is a codi-feature-demo which includes the most important features of codi compacted in few jsf pages and classes. a second branch (https://github.com/os890/tomee_mf_stack_001/tree/codi2ds) in the same repository shows the needed changes to migrate such a codi application to deltaspike (currently v0.6).

update: for upgrading to v0.7, just upgrade the version number of deltaspike (the demo was upgraded already)

deltaspike in 2013

here a short overview about the progress of deltaspike in 2013:

first of all the project graduated (apache incubator -> apache top-level-project).

multiple modules have been added:

• bean-validation
• data
• partial-bean
• scheduler
• servlet
• test-control

existing modules have been improved (e.g. optional support for jsf 2.2 specific parts).

the documentation has been improved (but there is still room for further improvements).

almost all myfaces-codi features have been ported to deltaspike and most of them have been improved.

two versions have been released and the next one will follow soon.

cdi and spring-mvc

based on http://os890.blogspot.co.at/2013/12/add-on-spring-bridge-with-deltaspike.html it's possible to write e.g. a cdi bridge for spring-mvc. with that it's possible to use cdi-beans as spring-mvc controllers. please notice that it is just a feasibility study.

https://github.com/os890/cdi-spring-mvc-showcase/tree/cdi-managed is the current state of the official demo with cdi-beans as controllers (instead of spring-beans).

[add-on] spring-bridge with deltaspike

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.

[deltaspike] validate view-config

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:

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.

[add-on] simple quartz integration with deltaspike 0.5

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:

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.:

With 'false' for @Scheduled#onStartup it's even possible to schedule/install jobs dynamically - e.g.:

Update:
This add-on is part of all versions of DeltaSpike after v0.5

[add-on] cdi tests with deltaspike 0.5

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:

Update:
This add-on is part of all versions of DeltaSpike after v0.5

migrate codi 1.x to deltaspike 0.5

the myfaces-stack demo at https://github.com/os890/tomee_mf_stack_001 (later added to the tomee examples) is a codi-feature-demo which includes the most important features of codi compacted in few jsf pages and classes. a second branch (https://github.com/os890/tomee_mf_stack_001/tree/codi2ds) in the same repository shows the needed changes to migrate such a codi application to deltaspike (currently v0.5).

boost myfaces codi scopes with owb v1.2

as described in a previous post, it's possible to boost the performance of custom cdi-scopes with apache openwebbeans. owb 1.2 provides a lot of improvements which makes it even more solid and faster.
therefore a new version of the boost-addon is needed.

[add-on] codi scopes for deltaspike

a lot of users use the cdi/jsf scopes provided by myfaces codi (apache myfaces extcdi). 2011/2012 codi merged with some other projects and the result is apache deltaspike.

apache deltaspike is not just a merged code-base. it's nearly a full re-implementation with a similar api, but it contains a lot of cleanups and improvements based on the some lessons learned. that's on of the reasons why the progress slowed down (esp. compared to the development speed of codi). codi was driven and tested by real and large applications (in some cases of early adopters). it didn't contain a huge amount of tests, but it was very well tested (by those applications). apache deltaspike faces a slower adoption rate, because not everybody gets time for a migration (from an already solid stack) and some just wait for v1+ which will provide the final/stable api. however, deltaspike is also very well tested, since there are way more automated tests (compared to codi) and they get executed on a regular basis with different versions of cdi.

one effect of the current development speed is that scopes like grouped-conversations (@ConversationScoped from codi), window-scope (@WindowScoped) and view-access-scope (@ViewAccessScoped) as well as the powerful spi for managing them are still not available and/or not that well tested (in real applications).

since most other parts of codi are already part of deltaspike, it's easy to create a lib based on deltaspike which provides the missing parts. the source-code can be found at os890-cdi-ext and for using it as a dependency (in a maven based build), it's deployed to os890-m2-repository.

for using it just drop the dependencies for codi, add deltaspike (at least core and the jsf-module as well as their dependencies), add os890-cdi-ext (org.os890.cdi.ext.scope.modules:os890-cdi-ext-jsf2-module-api and org.os890.cdi.ext.scope.modules:os890-cdi-ext-jsf2-module-impl) and change the imported packages in your application (from org.apache.myfaces.extensions.cdi.[...] to org.apache.deltaspike.[...] and org.os890.cdi.ext.[...]).

[add-on] owb and actors

actor-frameworks for the jvm gain more popularity every day. even with actor-frameworks you have to be careful with shared state. however, if you have a java-ee application, you can (re-)use stateless services in your actors easily. one use-case is to resolve transactional beans (ejbs, cdi-beans which are annotated e.g. with @Transactional, ...) in an actor and invoke methods on them to access a database.

with an ee-application-server like tomee that works out-of-the-box. you just have to bootstrap an actor-framework (like akka, jetlang,...) and use the std. java-ee api to lookup the bean/s.

if you are interested in using transactional cdi beans, you can use the jpa-module provided by apache deltaspike v0.4+ (note: those transactions don't span across actors). for using @Transactional, you just have to follow the documentation and you are done. that's usually a short story. but...

if you would like to use @Singleton or @ApplicationScoped beans and you are using the openwebbeans-web module of owb v1.1.x, you need an additional plugin (due to OWB-785). in such cases just get https://github.com/os890/owb-contexts_service-addon.git, build it and add it as runtime dependency to your project.
-> you are done (there is no additional api you have to use).

additional hint:
apache deltaspike provides some nice helpers (like BeanProvider#getContextualReference to resolve cdi-beans), interceptors (like @Transactional), scopes (like @TransactionScoped) and much more...

[slides] cdi @ apache

CDI @ Apache