Sunday, September 8, 2013

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