Thursday, December 22, 2011
deltaspike repository
5th release of myfaces-extensions-validator
Friday, December 9, 2011
deltaspike mailing lists
thx matt!
Wednesday, December 7, 2011
deltaspike joins the asf incubator
Tuesday, December 6, 2011
9th release of myfaces-extensions-cdi
Wednesday, November 30, 2011
deltaspike - the future of myfaces codi (is bright)
that means: codi goes apache tlp (top level project) together with others (esp. the seam3 team and the cdi-source team). as mentioned in the announcement: we will continue with codi. several features will be promoted to deltaspike and codi v2 will be based on deltaspike and will provide all features which won't be available in deltaspike itself. codi v1 will continue (it will be improved and maintained as it is and won't migrate to deltaspike).
Sunday, August 28, 2011
[scopes] render-scope vs flash-scoped vs codi scopes
Saturday, August 27, 2011
[myfaces] setup of codi and extval
the simple answer: both don't required configuration by default.
zero config allows you to add the jar files you would like to use to your project and that's it.
(in case of codi you have to ensure that you have configured the cdi implementation of your choice correctly. in case of the bv module of extval, you have to ensure that you added the bv implementation of your choice.)
information about the libs is available in the corresponding wiki which is liked on the official website of each project. please check the wiki and/or send a mail to the mailing list.
Monday, August 22, 2011
8th release of myfaces-extensions-cdi
Monday, August 15, 2011
[scopes] view-scope vs view-access-scope
you can find the information in the wiki of codi.
however, the short answer is:
the view-scope of jsf2+ is bound to a concrete jsf page. that means: as soon as you navigate to a different page, the state gets lost. that's better than nothing, but not useful for a lot of use-cases. the main use-case which needs it are ajax-requests on a page and the data used by them aren't needed on other pages, but it's pretty easy to break it e.g. with a browser-refresh on a page which stores the data in a view-scoped bean and has no form with input components. (in a previous blog post i described how to use the infrastructure provided by codi to create a session based view-scope to overcome such disadvantages cause by storing view scoped beans as part of the tree-state.)
like with the view-scope view-access-scoped beans are available on a page, but they also exist for the next page. that means: they are forwarded to the next page and get destroyed autom. if they don't get used during the first request of the next page. that's e.g. useful for wizards. if you have a wizard page which doesn't use the bean or you have to support the possibility to interrupt a wizard, you can use the grouped-conversation scope (and even the window-scope) provided by codi. however, due to the powerful api of codi you can also destroy the scope manually at any time (if needed).
Tuesday, August 2, 2011
[benchmark] boost myfaces codi scopes with owb v1.1.1
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))
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!
Sunday, July 17, 2011
[benchmark] myfaces codi scopes - weld vs owb part 3
- 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.
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.
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.
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).
Friday, July 15, 2011
codi meets scala
Tuesday, July 12, 2011
[benchmark] myfaces codi scopes - owb vs weld part 2
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.
Friday, July 8, 2011
codi for all - all for codi
now codi is tested on:
- Tomcat
- TomEE
- Jetty
- JEE 6 Application-Servers (JBossAS, WebSphere, Glassfish)
- JEE 5 Application-Servers (WLS, WebSphere,...)
- dmServer
an up to date list and further details are available here.
Thursday, July 7, 2011
7th release of myfaces-extensions-cdi -> v1
Tuesday, June 21, 2011
codi meets jboss as 7
Monday, June 20, 2011
goodbye ubuntu - welcome mint (ubuntu.better)
since i like their vision, i hope that i can keep it as long as possible.
Wednesday, June 1, 2011
session based view-scope with codi
after several questions about it i decided to implement a codi-add-on which can be used with jsf1.2 as well as with jsf2+. due to the powerful spi of codi, the result is a simple implementation which offers additional features like grouped beans (you can manually destroy beans of the same group immediately even though you stay on the same page), optional bean events,... .
it's e.g. problematic for some use-cases that the jsf2+ implementation of the view-scope stores the beans in the component tree. so several users ask for a session based view-scope. that means the beans for a page will be stored in the session instead of the component tree. if you really need such a scope instead of the view-access-scope provided by codi, you can implement such a scope with the spi of codi + two simple classes.
approach #1
the first one is a marker annotation and the second one an observer for the PreViewConfigNavigateEvent. that's it! if you only use the type-safe navigation of codi, you are done and you annotate your bean with @View and the @ConversationScoped annotation provided by codi. as soon as a navigation to a new page is detected all conversation scoped beans annotated with @View will be destroyed.
@ApplicationScoped | |
public class SimulatedViewScopeObserver | |
{ | |
protected void observeNavigation( | |
@Observes PreViewConfigNavigateEvent preViewConfigNavigateEvent, | |
EditableWindowContext editableWindowContext) | |
{ | |
if (!preViewConfigNavigateEvent.getFromView() | |
.equals(preViewConfigNavigateEvent.getToView())) | |
{ | |
for(Map.Entry<ConversationKey, EditableConversation> conversation : | |
editableWindowContext.getConversations().entrySet()) | |
{ | |
if(ConversationScoped.class | |
.isAssignableFrom(conversation.getKey().getScope())) | |
{ | |
if(conversation.getKey().getConversationGroup() | |
.isAnnotationPresent(View.class)) | |
{ | |
conversation.getValue().close(); | |
} | |
} | |
} | |
} | |
} | |
} |
@Target({TYPE}) | |
@Retention(RUNTIME) | |
@Documented | |
public @interface View | |
{ | |
} |
if you don't use the type-safe navigation of codi, you can implement e.g. a custom jsf navigation handler which does the same for all navigations.
if you prefer a single annotation instead (let's call it @MyViewScoped), you can write a portable cdi extension which adds the @ConversationScoped dynamically to all beans which are annotated with @MyViewScoped.
it took longer to write this blog entry, than implementing this mechanism :)
or
approach #2
the result of this approach is the same like approach #1. the advantage is that you don't have to care about the navigation and the disadvantage is that you have to extend a default implementation.
if you are ok with extending the default implementation (with weld you have to #veto the default implementation instead of using @Specializes), you can override the default implementation of #createConversation (a method which is part of the spi of codi). if you just implement the interface, you would override everything and you would deactivate all codi scopes. ok - so let's add a new scope with the same marker annotation and a ConversationFactory instead of the observer:
class ViewConversationExpirationEvaluator | |
implements ConversationExpirationEvaluator | |
{ | |
private static final long serialVersionUID = -1298186767354202960L; | |
private String viewId; | |
private boolean expired; | |
ViewConversationExpirationEvaluator() | |
{ | |
if(FacesContext.getCurrentInstance().getViewRoot() != null) | |
{ | |
this.viewId = FacesContext.getCurrentInstance() | |
.getViewRoot().getViewId(); | |
} | |
} | |
public boolean isExpired() | |
{ | |
return this.viewId == null || | |
!this.viewId.equals(FacesContext.getCurrentInstance() | |
.getViewRoot().getViewId()); | |
} | |
public void touch() | |
{ | |
if(this.viewId == null && !this.expired) | |
{ | |
this.viewId = FacesContext.getCurrentInstance() | |
.getViewRoot().getViewId(); | |
} | |
} | |
public void expire() | |
{ | |
this.viewId = null; | |
this.expired = true; | |
} | |
} |
@Target({TYPE}) | |
@Retention(RUNTIME) | |
@Documented | |
public @interface ViewConversationScoped | |
{ | |
} |
@Specializes | |
public class ViewScopeAwareConversationFactory extends JsfAwareConversationFactory | |
{ | |
private static final long serialVersionUID = 8809629790207239230L; | |
@Inject | |
private BeanManager beanManager; | |
@Override | |
public EditableConversation createConversation( | |
ConversationKey conversationKey, ConversationConfig configuration) | |
{ | |
if(conversationKey.getConversationGroup() | |
.isAnnotationPresent(ViewConversationScoped.class)) | |
{ | |
return new DefaultConversation(conversationKey, | |
new ViewConversationExpirationEvaluator(), | |
configuration, | |
this.beanManager); | |
} | |
return super.createConversation(conversationKey, configuration); | |
} | |
} |
this implementation is compatible with all jsf concepts which are supported by codi!
approach #2.1
this approach is the same like #2 but instead of implementing it on our own, we can just use the @ViewConversationScoped provided by the enhanced-conversations add-on for codi:
import org.os890.codi.addon.conversation.api.ViewConversationScoped; | |
import javax.annotation.PostConstruct; | |
import javax.inject.Named; | |
import java.io.Serializable; | |
import java.util.Date; | |
@Named | |
@ViewConversationScoped | |
public class ViewConversationBean implements Serializable | |
{ | |
private static final long serialVersionUID = 609266293914288287L; | |
private Date createdAt; | |
@PostConstruct | |
protected void init() | |
{ | |
this.createdAt = new Date(); | |
} | |
public Date getCreatedAt() | |
{ | |
return createdAt; | |
} | |
} |
Thursday, May 19, 2011
Saturday, May 14, 2011
6th release of myfaces-extensions-cdi
Friday, April 15, 2011
Thursday, April 7, 2011
5th release of myfaces-extensions-cdi
Tuesday, March 29, 2011
[benchmark] request scope - owb vs weld vs spring
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
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.
Saturday, March 26, 2011
[benchmark] myfaces codi scopes - OWB vs Weld
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.
Thursday, March 17, 2011
apache myfaces pmc chair
i'll try to continue the great work of the previous chairs!
furthermore, i would like to thank matthias for being such a great chair!
i wish you all the best for your new job!
in my first blog-post as new pmc chair i would like to mention:
everybody is welcome to join our awesome community!
esp. those guys who congratulated me directly because they haven't subscribed one of our lists. ;)
you can also follow us (not only me) via:

Monday, March 14, 2011
[benchmark] myfaces codi scopes
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).
Sunday, March 6, 2011
4th release of myfaces-extensions-cdi
Saturday, February 26, 2011
codi examples with myfaces stylesheet
screenshot of the first example: