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.

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.

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

the migration to tomee is easy

recently i created an example for tomee.

its origin is an example which used the same java-ee parts you find in tomee out-of-the-box, but configured manually for a servlet container like tomcat. the biggest change i had to do was to drop most dependencies. i just had to keep myfaces codi and extval. besides adding org.apache.openejb:javaee-api as provided dependency, i also added org.apache.openejb.maven:tomee-maven-plugin to start tomee and deploy the example with:

mvn tomee:run.

in the code i could keep everything as it was (the cleanup i did wasn't a required step to get it up and running with tomee). in case of the config i just had to drop some parts in web.xml and persistence.xml.

the rest worked immediately!

one container everywhere

based on the title you might think that this post is about spring. but it's about cdi with some references to spring/guice/... . however, it is not about spring vs cdi. it's just about wrong myths about cdi (compared to other containers like spring-core/guice/...)

esp. spring and cdi are so close that you can do almost everything with cdi what you can do with spring and the other way round. your project won't fail because you used one of it instead of the other one. if you have spring(-core) know-how already, it will take you about 2-3 days to know the same about cdi and the other way round. however, if you are in favour of the spring-framework, a lot of config options, one vendor,... , you should go with it. once you have the right dependency- and config-setup, the productivity with spring will be similar as long as you are aware of some topics like explicit proxy-configs in case of injection of beans with a narrow scope into beans with a wider scope. (that shouldn't be an offence - for sure also cdi has its pitfalls.)

let's have a look at some myths:

myth #1

statement:
with spring/guice/... everything is more flexible, since you just need to replace some jar-files for using a new version.

reality:
the same integration points to run spring/guice/... in your application-server are also available for a custom version of cdi (added in WEB-INF/lib).

myth #2

statement:
you can't upgrade the cdi container in your ee6 server.

reality:

technically you can do it. i did it already with tomee, glassfish3 and as7. the main question here is, if you are allowed to do it and/or you have the needed access to do it.

myth #3

statement:
once you picked an ee6 server, you have to use what you have in there.

reality:

a lot of specifications and/or the server itself allow/s to use other implementations. however, in case of cdi the container is integrated very deeply. using an other cdi implementation has the same restrictions as you will face with spring/guice/... . so you can do it, but not with keeping the full (cross-)integration like injecting cdi beans in ejbs. however, you can still use the cdi container to do a (bean-)lookup manually (as you would do with spring/guice/...). (preview: cdi 1.1 offers new SPIs which enable servers to provide even more out-of-the-box.)

myth #4

statement:
you can't use owb in an ee6 server which ships weld per default.

reality:

as mentioned in myth #3 you can do it with the same restrictions you would face with spring/guice/... concerning (cross-)integration. the following part is tested with glassfish (for as7 you would need a custom WebScannerService which supports the jboss vfs). there are different approaches:

approach 1:
in some cases it's enough just to add owb in WEB-INF/lib. e.g. in combination with jsf the el-resolver of owb will be called before the internal el-resolvers (like it is with spring/guice/...). however, you might face issues with some more restrictive checks done by weld (e.g. bda-rules). -> continue with:

approach 2:
2.1
exclude all packages via the scan-tag of the http://jboss.org/schema/weld/beans namespace (in beans.xml) -> only owb will find your beans.
2.2
owb is very pluggable. with a custom WebScannerService you can just use a different file-name for the marker file (e.g. owb_beans.xml instead of beans.xml). you just have to copy the default implementation, replace some strings and enable it in openwebbeans.properties. that means weld won't find your beans, but owb will find them (or the other way round for servers which ship owb per default). however, you might have implementations of javax.enterprise.inject.spi.Extension. -> continue with:

approach 3:
this approach can be combined with approach 2. you can veto beans for weld. just inject the bean-manager in your ProcessAnnotatedType observer and veto the bean if the bean-manager class is from weld: https://gist.github.com/os890/5427764

however, you might use a cdi-extension like codi or deltaspike and there it isn't enough to rename the marker-files or filter beans, because e.g. BeanManagerProvider will find the BeanManager of weld or of owb. since there is no rule (if both are in the classpath), the behaviour would be random. so you have to patch such cdi-extensions. e.g.: https://gist.github.com/os890/5427831

myth #5

statement:
cdi is hard(er) to use, because you don't get a reference to the container.

reality:
that's an easy task with owb as well as with weld. you can do it on your own or just use the CDI-Ctrl module provided by DeltaSpike. (with cdi 1.1 it will be possible out-of-the-box.)

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

openwebbeans on glassfish3 for jsf-applications

several users would like to use owb on glassfish3. if a full integration isn't needed and the only problem is an exception in jersey during the bootstrapping process, it's quite easy to work around it.



you need the following owb modules:

- openwebbeans-impl
- openwebbeans-spi
- openwebbeans-web
- openwebbeans-jsf

attention: that isn't a full integration. as you see e.g. jersey can't be used with this workaround.

[benchmark] boost myfaces codi scopes with owb v1.1.1

this is my last blog-entry about the performance of cdi implementations and codi scopes which is planned for the next months. why? you will see it in a minute.

within the last weeks we gave the weld team some hints how they can tweak the performance of their scopes. as you can see in the following benchmark, they improved the performance of std. scopes in weld a lot. the performance of the std. scopes is now pretty much the same as with owb. all differences are within the tolerance. however, the owb team (special thx to mark) is again one step ahead. the next release of owb (v1.1.1) will allow to use a very fast instance cache for custom scopes. based on this feature, i implemented the scope-boost add-on for codi. the result/s you can see in the chart: codi scopes are as fast as the request scope of owb. a nice detail about that: since owb v1.1.1 is faster than v1.1.0, codi scopes (+ add-on) in combination with owb v1.1.1 are faster than the (already very fast) request scope of owb v1.1.0 (you might remember the awesome results of the previous benchmarks).

as you know the results depend on a lot of parameters. anyway, the following charts should give you a basic impression about the difference. on my system i can reproduce the overall results (tolerance: <0,25ms). all application servers were started without changes in the configuration. for producing the other results i used again tomcat v7.0.19. in this benchmark the servers aren't that important, because there is no class of those servers between the method call and the final method of the bean (just the proxies used by the cdi implementation). that means jboss as7 as well as glassfish v3 are just slower because they don't ship the latest version of weld. for sure - if you upgrade your server, you will get a better performance with those servers.

the result:
as mentioned before std. scopes in weld (the currently latest release) and owb have about the same performance. in case of custom scopes owb can be way faster in combination with special add-ons for the corresponding custom scopes. the add-ons are needed to reset the cached instances, if the scope ends before the request ends. in case of codi you still have all advantages of codi-scopes as well as the performance of the request scope. that's possible due to the awesome concepts in owb as well as the UnscopeBeanEvent of codi. (please notice that weld v1.1.2 which is called "standalone" in this chart is a newer version compared to weld v1.1.2 shipped with jboss as7 out-of-the-box. the newer version already has the performance improvements mentioned before. that's the reason for the difference (and it isn't related to jboss as7))

(the lower - the better)

for this benchmark i used the simple benchmark which i used for my first post (as well as the same steps to measure the performance). in the previous benchmark i switched to jmeter because users were interested in the overall impact. this time i (again) used the simpler version because of some fluctuations with jmeter tests. besides the typical parameters which can influence the results, load tests are less reproducible e.g. because of several features of modern cpus. however, the previous posts are still valid. after publishing them i re-tested the benchmarks with different systems as well as different jdk implementations, operating systems,... . for sure the results differed a bit, but the overall result was more or less the same (esp. the ranking). however, as mentioned in the previous posts as well as in this post, these benchmarks should give you a basic impression. you might see a bit different results on your system, but the overall result is usually the same - esp. the basic messages illustrated by this benchmark:

- owb is innovative, pluggable and fast
- owb + codi == just awesome
- weld got a lot faster in the latest release
- servers which bundle old versions of weld are slower because they depend on the performance of those versions -> update the versions as soon as you can and you will increase the performance of your applications deployed to those servers for free!

[benchmark] myfaces codi scopes - weld vs owb part 3

in the previous benchmark i basically compared the scope performance of owb and weld with direct calls. this time i'm using jmeter to measure the performance under heavy load of a whole page. in the previous benchmarks the results were pretty stable. that's different this time. the results fluctuate way more and with some servers i (sometimes) got an OutOfMemoryError (depending on the settings). however, the conditions for the benchmark were the same for all servers:
- starting the server
- opening the page (which will be used for the jmeter tests)
- specifying how many el-expressions should be tested
- starting the jmeter benchmark

pages with 100, 1.000, 5.000 and 10.000 el-expressions were used for the benchmark.

all application servers were started without changes in the configuration. in tomcat mojarra 2.1.3 was used instead of myfaces-core to avoid an impact on the result e.g. due to a differing performance of renderers.

every value-binding in the page queried the value of a conversation scoped bean (codi conversations). this bean delegates the call to an injected request scoped bean. and the request scoped bean delegates to an application scoped bean which caches the list of objects which should be displayed.

as you know the results depend on a lot of parameters. anyway, the following charts should give you a basic impression about the difference. on my system i can reproduce the overall results.

the result:
esp. tests of pages with few el-expressions didn't show a huge difference between the servers, but the results fluctuated more compared to pages with a lot of el-expressions. as you see, tomcat 7 with owb is a bit better than tomcat 7 with weld and jboss as 7. in the end the difference is not big compared to glassfish v3.1.1. the following chart should give you a basic idea about a page which uses 100 value-bindings. that might sound a lot, but a page which contains a table with 4 columns and 15 rows already leads to 60 el-calls during the rendering phase only to display the values (in case of one displayed value per cell). and if you think about the rendered attribute or expressions to switch the formatting within cells dynamically,... you will get over 100 el-calls in the rendering phase very easily.

(the higher - the better)

as mentioned before i benchmarked the page with different amounts of el-expressions. the following chart shows the average of the throughput in percent. the fastest setup (in this case tomcat 7 + owb 1.1.0) is used as measuring staff.

(the higher - the better)

it might be interesting to see the results of the benchmarks above in a different context. the following charts shows the overhead in percentage. a static html page with the same content served by jsf on tomcat 7 is the basis for the comparison and would have 0% (that means: no overhead).

(the lower - the better)

measurements beyond hello word:
there are applications with even larger pages. the following chart shows the numbers for 30.000 value bindings per page. compared to the value-bindings of the benchmark above, it uses more complex bindings like
#{bean1.bean2.bean3.property} instead of directly delegating to a property of the first bean which resolves the final property. as you see owb gets even better with more complex scenarios.

(the higher - the better)

as mentioned before i used the settings which are shipped by the vendors out-of-the-box. since they are different i run the same constellation described above with 1.000 (instead of 30.000) value bindings per page. the following chart shows the result with -Xms128m -Xmx1500m -XX:MaxPermSize=256m (these values are the highest values used at least by one of the servers).

(the higher - the better)

[benchmark] myfaces codi scopes - owb vs weld part 2

the last few days we heard a lot about how great jboss as 7 (jboss application server v7) should be. i already tested the pre-release version concerning the compatibility with codi. it worked pretty well. that was awesome. in this test i'm using the final version which starts in a bit more than 2 sec. (on my machine). but now it's time to measure the runtime performance. therefore i used the latest releases of all containers. (just in case of glassfish i used the nightly of glassfish v3.2 to be able to use the latest version.) in case of jboss as 7 and glassfish v3 i took the weld versions they provide out of the box and on tomcat 7 and jetty 7 i used the current openwebbeans (= owb) release.

the result - jboss as 7 starts quite fast but the runtime performance is still better with a servlet container like tomcat or jetty + owb. however, i'm glad to see that there is a step forward from weld v1.1.1 to v1.1.2 but there is still a lot of room for improvements.

the tested scopes are the scopes provided by myfaces codi (with the exception of the request scope - it's just included as an orientation). the most significant result in the first chart is that the slowest scope (which is still very fast) is faster with owb than the fastest scope with weld. (if you keep the tolerance in mind we could say it's maybe not faster but as least equivalent.)

as you know the results depend on a lot of parameters. anyway, the following charts should give you a basic impression about the difference. on my system i can reproduce the results (tolerance: <0,25ms). the benchmark invokes a method of an injected bean 1000 times. the benchmark was started 3 times and the chart shows the rounded average.

as you see there are more or less the same results in tomcat and jetty. the results depend on the cdi version and not the container. the differences are within the tolerance. the difference between glassfish and jboss as 7 is caused by the newer version of weld in jboss as 7. so independent of how fast jboss as 7 is (e.g. during startup), the runtime-performance depends on parts like the used cdi implementation. this benchmark shows what you get out-of-the-box. for sure with servlet containers like tomcat, jetty,... you have the choice. if performance is important for your project, go with owb (it's already used by several big real world projects, it's fast, very solid and provides a powerful spi to customize the behaviour if you need to).


so it might be interesting to compare the currently released versions directly:

note:
owb has a special proxy for request scoped beans - that's the reason why there is such a huge difference.

new openwebbeans logo

[benchmark] request scope - owb vs weld vs spring

after some performance improvements (see OWB-557) i did a simple benchmark in order to compare the request-scope of owb, weld and spring3 (with ScopedProxyMode.TARGET_CLASS). as you know the results depend on a lot of parameters. anyway, the following chart should give you a basic impression about the difference. on my system i can reproduce the results (tolerance: ~0,25ms). the benchmark invokes a method of an injected bean 1000 times. the benchmark was started 3 times and the chart shows the rounded average.

the benchmarks with the direct method calls use the injected beans directly. that means those benchmarks show the raw performance. the benchmarks with the el-resolver calls use the jsf-api for resolving the beans and therefore they show the performance of the el-resolver implementations.

note:
owb has a special proxy for request scoped beans - that's the reason why there is such a huge difference.

[benchmark] myfaces codi scopes - codi vs orchestra

i did a simple benchmark in order to compare codi (+ owb 1.1) and the scopes of orchestra (without persistence interceptor). as you know the results depend on a lot of parameters. anyway, the following chart should give you a basic impression about the difference. on my system i can reproduce the results (tolerance: ~0,25ms). the benchmark invokes a method of an injected bean 1000 times. the benchmark was started 3 times and the chart shows the rounded average.

the benchmarks with the direct method calls use the injected beans directly. that means those benchmarks show the raw performance. the benchmarks with the el-resolver calls use the jsf-api for resolving the beans and therefore they show the performance of the el-resolver implementations.

note:
owb has a special proxy for request scoped beans - that's the reason why there is such a huge difference.

[benchmark] myfaces codi scopes - OWB vs Weld

i did a simple benchmark in order to check if we have to optimize owb even more. therefore, i also compared it with the performance of weld. as you know the results depend on a lot of parameters. anyway, the following chart should give you a basic impression about the difference. on my system i can reproduce the results (tolerance: ~0,25ms). the benchmark invokes a method of an injected bean 1000 times. the benchmark was started 3 times and the chart shows the rounded average. due to the quite slow initialization in weld (the result would be ~3,8 ms in case of the request scope), so i had to execute the benchmark ~3 times before the result got stable (to keep it fair i did the same with owb even though the differences are not that high). the 3 runs are those runs after the numbers had been stabilized.

the benchmarks with the direct method calls use the injected beans directly. that means those benchmarks show the raw performance. the benchmarks with the el-resolver calls use the jsf-api for resolving the beans and therefore they show the performance of the el-resolver implementations of both cdi implementations.

this benchmark uses the weld version which is bundled with glassfish 3.1:

this benchmark uses the (currently) latest snapshot of weld (downloaded from the snapshot repository):

note:
owb has a special proxy for request scoped beans - that's the reason why there is such a huge difference.