[deltaspike] restricting the amount of windows

with codi it was possible to restrict the number of windows and old windows are dropped if the maximum was reached and a new window should get created.
deltaspike doesn't allow that before v1.1.0, however, it's very easy to implement it manually:

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

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

[benchmark] myfaces codi scopes

after some performance improvements in owb (thx to mark!) and codi i created a benchmark for the upcoming versions (owb 1.1 and codi 0.9.4). as you know the results depend on a lot of parameters. anyway, the following chart should give you a basic impression about the performance of the myfaces scopes. on my system i can reproduce the results (tolerance: ~0,5 ms in the benchmark with security-manager). the benchmark invokes a method of a scoped bean via an el-expression 1000 times (i've used the el-ri). the benchmark was started 3 times and the chart shows the rounded average.

with a security-manager:

without a security-manager:

hint: this benchmark isn't comparable with the result(s) of the first benchmark back in 2010 because the test-system has more resources now.


furthermore, i compared the result with spring 3 and orchestra (tolerance: ~0,5 ms).

[benchmark] myfaces codi scopes

after some performance improvements in owb (see #966927 and esp. OWB-425) i created a benchmark for the new (pre alpha-1) myfaces codi scopes (@ConversationScoped != std. CDI conversations, @ViewAccessScoped and @WindowScoped). as you know the results depend on a lot of parameters. anyway, the following chart should give you a first impression about the performance of the myfaces scopes. furthermore, it's a preview concerning the improved performance of the el-resolver of owb. on my system i can reproduce the results (tolerance: ~2 ms). the benchmark invokes a method of a scoped bean via an el-expression 1000 times (i've used the el-ri). the benchmark was started 3 times and the chart shows the rounded average.

(maybe you are wondering why std. cdi conversations provide a better performance than the codi conversations. the simple answer is: std. cdi conversations just don't provide that much features... they are more like a per window session with some annoying drawbacks.)