openwebbeans custom resources

cdi itself allows to add beans to integrate other frameworks and containers.
so it's possible to inject them via @Inject.
however, sometimes you need to use other annotations like @EJB or @Autowired.
in an ee-server ee-annotations like @EJB work out-of-the-box. however, in case of a manual setup e.g. in combination with a servlet-container like tomcat, you might not be able to inject references to remote-ejbs. in any case you can't use non-ee annotations like @Autowired in cdi-beans out-of-the-box.

as mentioned in previous posts apache openwebbeans is very flexible.

owb is based on a simple plugin architecture which allows to customize parts easily.

some years ago i published an add-on for owb which allows to inject remote-ejbs via @EJB into cdi-beans in non-ee environments.

the add-on injects references resolved by a custom ejb-resolver into injection-points annotated with @EJB.

with the same approach it's possible to use 3rd party annotations in cdi-beans.

today i prototyped a similar add-on for owb, which allows to use @Autowired in cdi-beans to inject spring-beans based on the (field-)name or type. compared to the cdi-spring bridge i described here, it allows a simpler implementation which delegates to a started spring-container (instead of bootstrapping it). the major downside is that it isn't a portable cdi-extension (per definition) and therefore you can only use it with owb. furthermore, there is no validation of those injection-points during the startup you (might) know from cdi and injection of cdi-beans into spring-beans isn't supported as well.

openwebbeans on wls

some time ago, i described how to run openwebbeans on glassfish and wls.
the described approach works pretty well. however, once deltaspike added an optional ee7-support (esp. for jsf 2.2+), wls fails during the startup, because v12.1.2 doesn't support optional classes which contain imports of unknown classes (ee7 classes unknown to an ee6-server) like the other ee6 servers do.
therefore i created a new branch for ds-owb-bundle which filters those optional ee7 classes.
with that deltaspike works on wls without issues.

openwebbeans on glassfish

some time ago, i described how to run openwebbeans on glassfish3 and wls12.
in my previous post i described how to run openwebbeans on wildfly8 (and as7).
with the latest commit for ds-owb-bundle and the trunk of owb add-on,
the demo-application also works on glassfish4.

openwebbeans on wildfly8

recently i showed how to run owb on as7. the same owb add-on works with wildfly8 as well. however, wildfly8 ships a version of weld which implements cdi 1.1. therefore, i had to update the repackaged version of deltaspike. with the latest commit for ds-owb-bundle, the demo-application also works on wildfly8.

openwebbeans on as7

some time ago, i described how to run openwebbeans on a weld based ee6 server.
i mentioned that the used classpath-scanner doesn't support the virtual-file-system.
however, today i rewrote the scanner-service.
now it uses the "Corn Classpath Scanner" lib, which supports the vfs.
therefore, i tested the result with as7 (v7.2.0) and owb works fine as expected.
you can have a look at the result at the as7-branch of the same repository.

[slides] flexibility with cdi and deltaspike

openwebbeans to the rescue

there are several application-servers which use weld as cdi implementation. however, several of them work at least slightly different in the integration layer. e.g. some issues lead to a broken cross-module handling. one of many examples is CDI-18. some parts are fixed in cdi 1.1, but that doesn't help you with servers which use cdi 1.0. furthermore, weld2 based servers have to prove that they fixed the integration layer correctly.

the effect is that such servers have issues with supporting more complex use-cases and some even with well tested cdi extensions like apache deltaspike. e.g. wls12 (at least until 12.1.2) has issues with the bda-rules which leads to a failed deployment of applications using apache deltaspike. the only way it can be done is to use some build-tricks (to copy the classes to WEB-INF/classes instead of including the jar-files and to merge the config-files to provide the content via WEB-INF/beans.xml and META-INF/services/javax.enterprise.inject.spi.Extension).

openwebbeans to the rescue:
per default owb doesn't follow the broken bda rules. that saves you from a lot of headache.
as described here it's possible to use openwebbeans instead of weld. if you just have custom cdi extensions, it's easy to use those hints. however, using pre-packaged extensions like apache deltaspike is a bit tricky, because you can't add filters to the affected parts within deltaspike (without patching ds).
anyway, with two small helper libraries it's easy to bypass weld at all.
i wrote the first one some months ago. it's called custom-cdi-owb-addon and uses the plugin infrastructure of owb to provide a custom classpath-scanner and service-loader. the only purpose of the add-on is to change the name of the marker/config files (owb_beans.xml instead of beans.xml and OwbExtension instead of javax.enterprise.inject.spi.Extension). with those two changes only owb will see your custom-cdi configs and beans.
since libraries like apache deltaspike use the standard configs, it's required to repackage them. that's the purpose of the second library called ds-owb-bundle. as you can see in the example, you just have to change the group-id in your maven build and the rest is the same. also your application has to use the new names (owb_beans.xml and OwbExtension).

(the demo-application was tested on wls12 and glassfish3. with as7 it won't work, because the classpath-scanner doesn't support the virtual-file-system.)

for sure it doesn't provide a full integration, but for a jsf application it's good enough (and the same you will get with other 3rd party dependency-injection containers). since owb is very flexible, it's even possible to inject ejbs (a plugin can be found here).

async cdi

today i implemented a small lib (~100 lines of code) which allows to use asynchronous cdi beans (including asynchronous observer methods).

if you don't use ejbs (for whatever reason), you can't use javax.ejb.Asynchronous.

however, sometimes you might need some asynchronous calls. as i illustrated in 'akka-and-cdi-are-good-friends', you can use actor-frameworks for doing it. however, sometimes that's just not needed and a simple asynchronous call is enough (which in addition doesn't have to follow the rules introduced by actor-frameworks).

in such cases you can use @Async.



a working example (with owb as well as tomee with owb 1.2.x) can be found here. currently it doesn't work with weld.

akka and cdi are good friends

today i implemented a small lib (less than 100 lines of code) which integrates akka and cdi.

it supports injection of akka artifacts (ActorRef and ActorSystem) in cdi-beans as well injection of cdi-beans in actors.

examples:




this lib doesn't intend to provide a full integration. it should just illustrate how easy it is to use akka in combination with cdi (and to integrate both).

(parts of it are done with deltaspike, however, it's easy to replace (copy) the needed parts to avoid a dependency.)

you just need to be aware of some basic rules given by actor-frameworks (some details are mentioned here).

[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

speedup the tomee startup

apache tomee is based on apache tomcat and adds the java-ee web-profile on top of it (based on apache projects like myfaces, openwebbeans, bval,...). the runtime performance is great and also the startup time is nice. esp. during the development phase every second hurts (at least a bit). with a simple change it's easy to remove some overhead! the following part shows the difference.

tomee just adds some libs to tomcat. that means you can also use a different version of tomcat easily - so it's easy to get tweaks and bugfixes of the latest version of tomcat also for tomee and you can use the std. tomcat plugin for your ide. however, that also means you (can) get some overhead - currently the demo apps shipped with tomcat cause such an overhead during the server startup. just by removing the demo web-apps you can reduce the startup time of tomcat itself by about 50 percent (here from ~1.4 seconds to ~0.7 seconds). for tomee you can do the same, but you have to keep a webapp called "tomee" (it's needed to use remote-ejbs - so it isn't a demo). if you don't need remote-ejbs, you can remove all webapps shipped by tomee to improve the startup performance even further.

the following chart shows the differences of the mentioned constellations. the value for jboss as7 is just a reference value.

the following chart shows the overhead introduced by tomee (compared to a standalone tomcat).

please note:
1)
all those values depend on the machine, operating-system,... - in addition the values are rounded and should just give a basic impression about the differences (please don't see it e.g. as a tomee vs as7 comparison).

2)
there are 2 values printed during the tomcat/tomee startup. the first one is listed as "Initialization processed in ..." and  the second one as "Server startup in ...". the values in the charts always show the sum of both ( "Server startup in ..." sounds like the sum but it is not the sum of the full startup process).

3)
as7 is also based on tomcat but the integration is way deeper and therefore it isn't given that the startup of tomcat itself takes the same time as with tomcat standalone or tomee (that's the reason why there is no separation for as7 in the second chart).