os890

codi meets tomee

2012-01-25T20:40:00.001+01:00

recently the open-ejb team released beta2 of tomee v1.

tomee is already optimized a lot. today we saw an issue during the deployment of a codi demo to tomee. thx to romain manni-bucau we found the issue pretty quickly. due to an optimization tomee filters myfaces-* jar files to improve the scanning performance. so you just have to rename the jar file(s) of codi until the issue gets fixed.
(or manually patch org\apache\openejb\config\NewLoaderLogic.class in webapps\openejb\lib\openejb-core-4.0.0-beta-2.jar)

furthermore, we will add an integration test to tomee to avoid that it happens again.

so have fun with myfaces codi on tomee!

deltaspike repository

2011-12-22T13:35:00.004+01:00

today we got our git repository for deltaspike: https://git-wip-us.apache.org/repos/asf/incubator-deltaspike.git

5th release of myfaces-extensions-validator

2011-12-22T13:18:00.001+01:00

The Apache MyFaces team is pleased to announce the 5th release of Apache MyFaces Extensions Validator (aka ExtVal).

deltaspike mailing lists

2011-12-09T00:14:00.002+01:00

today matt benson created our mailing lists and the first tests were successful: http://goo.gl/oRFtU and http://goo.gl/DZix0

thx matt!

deltaspike joins the asf incubator

2011-12-07T23:37:00.009+01:00

the vote to join the incubator was closed. there were 8 binding +1 votes, 3 non-binding +1 votes and no -1 votes. in parallel several other folks showed up and told us that they are interested to join the effort.

deltaspike - the future of myfaces codi (is bright)

2011-11-30T02:00:00.002+01:00

today we announced the future of myfaces codi.

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

[scopes] render-scope vs flash-scoped vs codi scopes

2011-08-28T16:52:00.003+02:00

frameworks like seam provide a so called render-scope e.g. to use beans after a redirect for rendering the next page. that's very often not enough because beans are usually also needed on a subsequent request to the same page. the flash scope is also not the best solution because it's usually also used to overcome the redirect issue of request scoped beans. therefore, myfaces codi introduced the view-access-scope which keeps beans as long as they are accessed by a view (also supports any kind of ajax scenarios). however, if you really need the behaviour of @RenderScoped, you can use e.g. the @PostRenderView callback to terminate beans (which have one of the codi scopes) manually or you can provide a custom marker and you terminate all beans with this marker automatically in a phase-listener. the needed information is available in the wiki (or just contact the myfaces mailing list, if you need further information about it).

[myfaces] setup of codi and extval

2011-08-27T00:54:00.000+02:00

in the last weeks i saw a lot of users looking for information about setting up and/or configuring extval and/or codi.

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.

8th release of myfaces-extensions-cdi

2011-08-22T01:03:00.001+02:00

The Apache MyFaces team is pleased to announce the 8th release of Apache MyFaces Extensions CDI (aka CODI). It's v1.0.1!

[scopes] view-scope vs view-access-scope

2011-08-15T15:40:00.004+02:00

a lot of people were looking for this information.
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).

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

2011-08-02T02:18:00.012+02:00

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

2011-07-17T00:25:00.012+02:00

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)

codi meets scala

2011-07-15T15:39:00.000+02:00

werner wrote nice blog entries about using scala in combination with jsf. in the second part he shows the basic approach how to implement the type-safe view-config the scala way. let's hope we will see a follow-up about nice view-config features like multiple inheritance of configs (like a SecuredPages interface).

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

2011-07-12T20:18:00.007+02:00

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.

codi for all - all for codi

2011-07-08T13:08:00.000+02:00

it's really great. people notify us about successful tests on different environments.

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.

7th release of myfaces-extensions-cdi -> v1

2011-07-07T10:00:00.000+02:00

The Apache MyFaces team is pleased to announce the 7th release of Apache MyFaces Extensions CDI (aka CODI). It's v1.0.0!

codi meets jboss as 7

2011-06-21T14:26:00.000+02:00

since jboss application server v7 (jboss as 7) is short before the beta 4 and rc1 release, i tested the latest head with the latest version of codi. as tweeted, everything worked well. all workarounds for mojarra and weld we had to use for glassfish v3 also work on as7.

goodbye ubuntu - welcome mint (ubuntu.better)

2011-06-20T23:57:00.000+02:00

since years i'm using ubuntu. most of the time it worked pretty well. since some weeks i'm testing mint linux (it's based on ubuntu) as well as the current snapshots of other more famous dists like fedora. now i completely switched to mint. the original reason was gnome 2 but it turned out that they do a lot of things way better and i can use it as it is (i even like the design).

since i like their vision, i hope that i can keep it as long as possible.

session based view-scope with codi

2011-06-01T21:57:00.017+02:00

codi itself offers an adapter for the view-scope of jsf2+ as well as a view-access scope which sounds similar but is something completely different (there is a 2nd blog entry about the difference). this entry is not about the view-access scope. it's about the view-scope which was introduced by jsf2. the adapter provided by codi allows you to bind cdi beans to the view-scope of jsf2+ directly. that's the reason why it's only available for jsf2+ whereas the other scopes of codi can be used with jsf1.2 as well as jsf2+. however, besides the basic concept of the view-scope, the default implementation has also some disadvantages (like losing the state in case of a browser-refresh, if there is no form with input components). if you haven't faced such issues, you might skip this blog entry. as mentioned before there is no standard way for jsf1.2 users to use the view-scope of jsf2+.

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.

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:

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:

new openwebbeans logo

2011-05-19T01:19:00.000+02:00

6th release of myfaces-extensions-cdi

2011-05-14T16:16:00.000+02:00

The Apache MyFaces team is pleased to announce the 6th release of Apache MyFaces Extensions CDI (aka CODI).

[slides] codi conversations

2011-04-15T17:02:00.001+02:00

MyFaces CODI Conversations

5th release of myfaces-extensions-cdi

2011-04-07T18:19:00.002+02:00

The Apache MyFaces team is pleased to announce the 5th release of Apache MyFaces Extensions CDI (aka CODI).

[benchmark] request scope - owb vs weld vs spring

2011-03-29T12:32:00.008+02:00

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

2011-03-29T12:16:00.004+02:00

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

2011-03-26T13:03:00.003+01:00

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.

apache myfaces pmc chair

2011-03-17T08:55:00.010+01:00

now it's official - i'm the new pmc chair of myfaces.
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:

[benchmark] myfaces codi scopes

2011-03-14T23:27:00.013+01:00

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

4th release of myfaces-extensions-cdi

2011-03-06T00:16:00.000+01:00

The Apache MyFaces team is pleased to announce the 4th release of Apache MyFaces Extensions CDI (aka CODI).

codi examples with myfaces stylesheet

2011-02-26T00:11:00.000+01:00

there are several examples for myfaces codi in the myfaces-repository. most of them are just dev examples esp. for an easier communication between members of the dev team. users might be confused because they don't know the intention of the details. therefore, i started with the first hello-world example which will be shipped with the next release. currently the example shows some simple use-cases. you will see further examples in the near future. all examples (which are available in the myfaces-repository) with the official myfaces-stylesheet might be interesting for users.

screenshot of the first example:

myfaces extensions @ spaaze

2011-02-20T08:10:00.004+01:00

somehow different (click on):

codi meets the cloud

2011-02-03T16:30:00.001+01:00

thx to matthias we have a first demo based on apache technologies which is deployed to a cloud infrastructure. as you can see the demo also includes myfaces codi!

apache member

2011-01-24T21:35:00.000+01:00

last week i received an awesome invitation from matthias to become an asf member. i'm honored and accepted with pleasure! thx to all members!

3rd release of myfaces-extensions-cdi

2011-01-16T21:18:00.001+01:00

The Apache MyFaces team is pleased to announce the 3rd release of Apache MyFaces Extensions CDI (aka CODI).

2nd release of myfaces-extensions-cdi

2010-12-10T21:14:00.002+01:00

2nd release of myfaces-extensions-cdi

The Apache MyFaces team is pleased to announce the 2nd release of Apache MyFaces Extensions CDI (aka CODI).

myfaces extval release news r3 -> r4

2010-11-28T14:39:00.002+01:00

these slides give a short overview of the most important new features of the 4th release of myfaces extval.

MyFaces Extensions Validator r4 News

4th release of myfaces-extensions-validator

2010-11-27T21:20:00.005+01:00

The Apache MyFaces team is pleased to announce the 4th release of Apache MyFaces Extensions Validator (aka ExtVal).

new myfaces-extval logo

2010-11-15T15:19:00.001+01:00

myfaces-codi logo

2010-11-14T15:17:00.000+01:00

myfaces-codi introduction slides

2010-11-14T15:08:00.002+01:00

MyFaces CODI v0.9.0 News

1st release of myfaces-extensions-cdi

2010-11-14T14:14:00.001+01:00

The Apache MyFaces team is pleased to announce the 1st release of Apache MyFaces Extensions CDI (aka CODI).

[infra] myfaces extensions meet dvcs

2010-11-11T10:48:00.000+01:00

it's getting easier for the community to contribute to myfaces-extensions *!

now we have official git mirrors:

https://github.com/apache/myfaces-extval

and

https://github.com/apache/myfaces-extcdi

as well as inofficial mercurial mirrors (hg isn't supported by the asf):

https://bitbucket.org/os890/extval-milestones/

and

https://bitbucket.org/os890/codi-milestones/

in case of myfaces-extensions * the mercurial repositories provide an additional feature. early adaptors can request an inofficial (external) milestone at any time. it's easier to handle issues compared to nightly builds.

dvcs like mercurial and git allow easy forking of repositories and experimenting with new features. with features like squash it's very easy to donate the result of your feature-branch!

so let's get started: fork -> experiment -> donate (your patch)!

ubuntu 10.10

2010-10-23T11:06:00.001+02:00

usually i don't blog about operating systems.
however, have you thought linux or esp. ubuntu doesn't look awesome?

if you invest about 2 hours to adjust the default theme, ui animations (of compiz), a custom dock (avant window navigator) and some other fine-tunings, you get a really nice user-experience!

one picture doesn't show the whole story, but here is a basic impression:

[javaone] myfaces extval and myfaces codi meet j1 2010

2010-09-24T00:18:00.003+02:00

that's nice! matthias and ali presented myfaces at j1 2010. one part of the presentation was myfaces extval (e.g. [1] [2]) and a second part was about myfaces codi (e.g. [1] [2]). it was the first preview of myfaces codi at a java conference.

[preview] codi meets cwiki.apache.org

2010-09-23T23:46:00.003+02:00

it's really nice. myfaces codi as well as the documentation for it is still in progress and i see a lot of positive response out there.

some days ago i started with the documentation (it's still in progress) and google analytics shows that people are already reading it!

os890 meets bitbucket

2010-09-23T23:23:00.004+02:00

it's planned to continue with the repository at https://bitbucket.org/os890. it's easier for users to fork it. well - mercurial might be a barrier for some of you, however, it's really easy and nice (a nice mercurial intro). you can easily fork an existing repository and it's easier to merge in your enhancements. so we hopefully get rid of all the hidden forks and the pain of manual merges.

[benchmark] myfaces extval

2010-08-02T05:41:00.012+02:00

after some performance improvements (see EXTVAL-80) i created a benchmark for the bean-validation (jsr-303) integration module for extval r3 and r4m3. as you know the results depend on a lot of parameters. anyway, the following chart should give you a first impression about the performance improvements. on my system i can reproduce the results (tolerance: ~2 ms). the benchmark invokes the validation for a component 1000 times. the value-binding points to a property which hosts one bv-constraint. the benchmark was started 3 times and the chart shows the rounded average of 10 validations (just because it's more interesting than the validation of 1000 ui components).

furthermore, the chart shows the impact of 2 optimizations described in a first draft for advanced extval/bv topics. optimization #1 just deregisters the validation interceptor which allows to create any kind of custom annotations for jsf validation (it's the base implementation of the property-validation module). optimization #2 deregisters the implementation of EXTVAL-83 - one of the new features available in r4+.

[benchmark] myfaces codi scopes

2010-07-26T18:48:00.014+02:00

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

[preview] early preview of the 4th release

2010-07-03T19:45:00.003+02:00

the current milestone already offers a lot of the features which will be available in the 4th release. the 4th release will introduce new features for the validation modules as well as some performance improvements and an improved jsf 2 support. until the next release, we will also improve the documentation. so it will take some time to get out the next version of extval. anyway, the current milestone is already quite stable and used in several applications out there.

once again extval (1.x and 2.x) offers features which aren't available in other validation frameworks for jsf. e.g. extval allows to use @Valid in combination with jsf. beyond the features of bean-validation (jsr 303) itself extval provides the possibility to use an annotation called @ConstraintSource. it allows e.g. to annotate dto's with this new annotation(s) in order to specify the source which hosts the constraints. so you don't have to repeat all the constraints in classes like dto's.

multi-field form validation with jsr 303

2010-06-01T22:15:00.009+02:00

there is a new extval add-on. this first draft of the add-on allows so called multi-field (or cross-field) validation based on jsr 303.

within the page you just use normal input components - e.g.:

furthermore, you annotate e.g. your page bean with @FormValidator. the annotation also allows to specify a specific view-id, conditions as well as validation groups. to implement a more fine-grained multi-validation it's possible to provide multiple form-bean classes. to implement more complex combinations it's possible to use @FormValidator.List(...). (as alternative you can also us the provided java api to map your bean(s) to a form-validator. so if you don't like to use the annotation you can provide a separated mapping.)

usage of @FormValidator:

in the page you see the id's of the different components. we have to use these id's as field-names (or setter-methods) in the form-validator.

the following figure shows a possible form-validator for this example:

as soon as the form-validator-bean is annotated with @Form, the validator is called by the bean-validation engine. so the violation message gets processed by the bean-validation engine and the final message is added as global faces-message.

(if you would like to use the current ConstraintValidatorContext of bean-validation, you can directly implement the FormBean interface instead of extending ViolationMessageAwareFormBean.)

if you use e.g. input components within a data-table, you can use 'add'-methods instead of the setter-method. in the form-validator you can use a data-structure like a list per column. as soon as the validation process starts (at the end of the validation phase) the form-validator contains all values (in case of input components in tables the validator is aware of all table values). so it's possible to implement any multi-field validation you can imagine (in case of input components in tables also validations per row as well as across rows).

additional features:
it's possible to map the form-bean-class to specific view-id's, to provide conditions as well as validation groups.

[review] apache myfaces 1.2 web-application development

2010-05-31T23:55:00.002+02:00

i reviewed a book about myfaces.
here you can read it.

extval meets cwiki.apache.org

2010-04-09T00:37:00.002+02:00

today i created a new cwiki-space for extval.

within the next weeks i'll move and improve the documentation of extval.
you are welcome to ask questions in order to improve the content!

creating feeds with jsf is easy now

2010-03-27T00:03:00.004+01:00

about one month ago i proposed a simple annotation based approach for creating feeds easily (e.g. based on jpa entities). now a first draft is available here. it's great that it's available quite fast after the initial brainstorming!

extval meets paper

2010-03-26T10:10:00.003+01:00

bart kummel wrote a book about the myfaces project.
i'll publish a review about the book quite soon.

it also contains an intro of myfaces extval!
it's really great that the extval chapter is the free sample chapter.
so enjoy reading it!

extval r3 in action - fullstack 2010

2010-03-25T01:11:00.000+01:00

this fullstack demo illustrates some use-cases of using jsf 1.2, spring 3, myfaces extval r3, bean-validation,... in case of myfaces extval the demo also shows how to keep all layers outside the view-layer independent of extval classes. so you see how to re-use existing (extval independent) constraints for ui validation in a typesafe way.
furthermore, the demo shows how to integrate bean-validation (jsr 303) in jsf 1.x applications.

further details are available in the (short) readme file.

here is the list of the used technologies:
- jsf 1.2 (+ facelets)
- myfaces orchestra
- myfaces extval r3 (+ some add-ons)
- bean-validation (jsr 303)
- spring 3
- jpa 1.0
- primefaces

myfaces extval release news r2 -> r3

2010-03-24T16:22:00.004+01:00

these slides give a short overview of the most important features of the 3rd release of myfaces extval.

MyFaces Extensions Validator r3 News

3rd release of myfaces-extensions-validator

2010-03-24T06:22:00.001+01:00

the apache myfaces team is pleased to announce a new release of myfaces-extensions-validator!

the release contains several improvements and new features as well as a new validation module for using bean-validation (jsr 303) with jsf 1.x and 2.0.
(compared to the standard integration of bv in jsf 2.0 extval 2.0.3 offers more advanced and typesafe features.)

released versions:
extval 1.1.3 (for jsf 1.1.x)
extval 1.2.3 (for jsf 1.2.x)
extval 2.0.3 (for jsf 2.0.x)

[add-on] spring 3 managed constraint validation for extval

2010-03-05T00:16:00.004+01:00

there is a new add-on which allows using typesafe spring 3 dependency injection for constraint validators. so it's possible to inject other beans (e.g. a validation service, a repository,...) into a constraint validator.

it's similar to the native extval di support. the main difference is that the add-on offers a typesafe alternative. you just have to extend the default-implementation (listed at @Constraint(validatedBy = {...})) and provide the custom implementation as spring bean.

welcome myfaces-codi

2010-02-20T12:18:00.008+01:00

it's official - myfaces is going to host a new extensions module.
besides myfaces-extval and myfaces-extscript we now start myfaces-extcdi which is also known as myfaces-codi (context and dependency injection)
(pronounced like the name).

myfaces-codi will provide portable CDI (Contexts and Dependency Injection) extensions which are useful for JSF applications.

we have already collected some nice ideas.
however, everyone is welcome to donate further ideas, implementations,...

so let's welcome codi!

myfaces-extval @ jsfdays 2010

2010-02-09T10:34:00.005+01:00

last year i presented extval at my trinidad workshop (esp. the integration and special features in combination with trinidad).

this year i'll give a jsf fullstack workshop. one part of the workshop will show how to integrate bean-validation in a jsf 1.x application via myfaces extval as well as the migration path for upgrading to jsf 2.0.

the rest of the workshop will be interesting as well (for sure)!

if you are interested - just register here!

myfaces extval @ jsfcentral

2009-12-17T12:18:00.001+01:00

the next part of the article series is available at jsfcentral.
thx to the jsfcentral team!

metadata based validation @ejug seminar (german)

2009-12-17T11:02:00.001+01:00

the slides of the metadata based validation presentation at the ejug seminar in linz.

Metadatenbasierte Validierung

happy birthday myfaces-extval

2009-12-12T12:12:00.001+01:00

one year ago we saw the first release of myfaces extensions validator.

the second release was a small but powerful update.
the third release will be available soon. it is a major update and will provide a lot new great features as well as a new validation module which allows to use bean-validation (jsr 303) with all jsf versions as well as some other additional features compared to the standard integration of bv in jsf 2. the latest milestone is available at the snapshot repository. it's already very stable and you can start using it right now! (currently we are in the review phase - so you can already use the current milestone until the version gets released.)

so extval and its add-ons will continue to help you to solve your daily validation tasks with powerful and easy to use mechanisms.

within the last year i received a lot of great feedback as well as a lot ideas for great add-ons. over 17 000 page-hits (in ~100 different countries) within the first year is really great for such an extension! these numbers are just for os890. if you also count the articles, wikis,... it's much higher!

so all of you are welcome to use the current milestone and don't stop to provide feedback as well as ideas for great new features and improvements...

primefaces and jsr 303 via extval

2009-11-26T23:00:00.007+01:00

the previous post shows how easy it is to set-up extval to be used with primefaces.

in the meantime i created a small example [1] which shows that it is very easy to use jsr 303 constraints in a primefaces application via extval.

furthermore, the demo shows ajax validation based on jpa annotations as well as cross-validation via ajax and the none-blocking warn mode.

moreover, the example shows the optional component support module for primefaces. for example it allows component initialization of the password-component based on meta-data. that's equivalent to the functionally available for the standard components. if a property bound to this special primefaces component hosts meta-data about min and max length (e.g. the jsr 303 constraint @Size(min = 7, max = 14), these information get transferred to the component automatically.

a sample screen of the demo:

[1] http://code.google.com/p/sandbox890/source/browse/#svn/trunk/examples/primefaces_extval/example_01

os890 maven repository

2009-11-23T23:55:00.002+01:00

it was a frequent user request that the myfaces-extval add-ons should be available via a maven 2 repository. so i created a repository for os890 as well as for sandbox890.

so you just have to add e.g. the following part to the repositories section of your pom.xml


<repository>
  <id>os890.googlecode.com</id>
  <url>http://os890-m2-repository.googlecode.com/svn/tags/os890</url>
</repository>

snapshots are available via


<repository>
  <id>os890.googlecode.com</id>
  <url>http://os890-m2-repository.googlecode.com/svn/trunk/os890</url>
</repository>

further information are available in the usage-wiki as well as the repository overview!

myfaces extval 2 and icefaces 2

2009-11-15T10:14:00.006+01:00

today i had a quick look at the first version of icefaces 2. it looks really nice. so i added extval to the component demo project.

i tested simple constraints as well as cross-validation (cross-component-validation/inter component validation). both worked quite nice also with ajax enabled input components.

also new extval features like severity aware validation (e.g. non-blocking warn mode) work quite well.

i'm looking forward to seeing the final version!

the upgrade of the demo (with extval) was done quite fast:

just adding the jar files and using the constraints!

in this case i used the following maven dependencies for extval:

groupId: org.apache.myfaces.extensions.validator

artifactId: myfaces-extval-core

version: 2.0.3-SNAPSHOT

groupId: org.apache.myfaces.extensions.validator.validation-modules

artifactId: myfaces-extval-property-validation

version: 2.0.3-SNAPSHOT

currently we also need (we will see if we need it with the final version as well)

groupId: org.apache.myfaces.extensions.validator.component-support-modules

artifactId: myfaces-extval-generic-support

version: 2.0.3-SNAPSHOT

for sure also the myfaces extval support for jsr 303 works out-of-the-box after adding the needed jar files...

bean-validation constraint validators and dependency injection support in jsf

2009-11-13T23:27:00.005+01:00

myfaces extval allows to use beans as validators. so it's possible to inject services into validators. bean-validation (jsr 303) specifies that the class of a validator has to be defined hardcoded. anyway, via the ConstraintValidatorFactory it's possible to change the default behavior.

in jsf you can query beans by name (not by type which is possible e.g. in spring). extval allows to provide a custom implementation of the ValidatorFactory. so you can optimize the lookup for your dependency management container (e.g. to make it typesafe).

anyway, out of the box the bv-integration module of extval (the next milestone of it) allows to provide/override constraint-validators via bean(s).

a detailed description is available at EXTVAL-70.

a spring bean for the example mentioned in EXTVAL-70 would be:

<bean id="customConstraintValidator">      class="at.gp.demo.CustomConstraintValidator"
      scope="prototype">
    <property name="customService" ref="...">
</bean>

bean-validation support for richfaces via extval

2009-11-12T13:14:00.005+01:00

today i upgraded an internal richfaces 3.3.x demo to use extval to integrate jsr 303 validation.

the upgrade was done quite fast:

just adding the jar files and using the bv constraints!

in this case i used the following maven dependencies:

for richfaces:

groupId: org.richfaces.ui

artifactId: richfaces-ui

version: 3.3.2.GA

for extval:

groupId: org.apache.myfaces.extensions.validator

artifactId: myfaces-extval-core

version: 1.2.3-SNAPSHOT

required to use a4j with extval:

groupId: org.apache.myfaces.extensions.validator.component-support-modules

artifactId: myfaces-extval-generic-support

version: 1.2.3-SNAPSHOT

to use jsr 303 validation:

groupId: org.apache.myfaces.extensions.validator.validation-modules

artifactId: myfaces-extval-bean-validation

version: 1.2.3-SNAPSHOT

groupId: org.hibernate

artifactId: hibernate-validator

version: 4.0.0.GA

groupId: org.slf4j

artifactId: slf4j-api

version: 1.4.2

groupId:org.slf4j

artifactId: slf4j-log4j12

version: 1.4.2

to support org.richfaces.component.html.HtmlCalendar

groupId: sandbox890.extensions.validator.component-support-modules

artifactId: myfaces-extval-richfaces-support

from http://code.google.com/p/sandbox890/

[add-on] customizable severity feature and the continue with warnings add-on

2009-10-23T16:11:00.001+02:00

the next version of extval will offer violation severities for constraints via extval-validation parameters as well as via jsr303 payload parameters. that means it's possible to define the severity for every constraint.

sometimes it is needed that you can save the form-data and continue in the application even though there are still warnings. so version x.x.3 (for jsf 1.x and jsf 2.x) of extval will allow that you can change the behavior (depending on the severity) via a custom add-on.

that means:
the user tries to submit invalid data. there are just warnings and no errors. so the page gets refreshed and the warnings are displayed. so far we have the expected jsf behavior. if the user clicks again on the (same) button the add-on recognizes that the user already saw the warnings and if there are no errors the warnings are ignored this time. the usage is quite simple:

the required steps:

add extval to the project
add the add-on to the project

use the constraints
from extval:

or from jsr 303

and within the form you just have to add the following hidden field:

that's it!

if you would like to have a button which is still strict and doesn't continue with warnings, you can use a special parameter. since the implementation of the add-on is quite simple it's also possible do implement it the other way round.

optional for the strict behavior:

the add-on is available at: http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/continue_with_warnings and requires the current trunk version of extval (or the next milestone v.1.2.3M2)

[preview] client-side validation with jsr 303

2009-10-12T22:56:00.009+02:00

after updating to the newest ri-version of bean-validation (jsr 303) i added some new functionality to the bean-validation (integration) module of myfaces-extval. the "new" functionality is already known from previous releases of the property-validation module. currently it works with jsf 1.x., however, there is also a branch for jsf 2.0 which will be updated before the next release.

so i started to refactor the featureset-01 example (which is already shipped with myfaces-extval) to bv-constraints. since myfaces-extval provides ui-optimized approaches not everything will be possible. anyway, the result of this first step is client-side validation of @NotNull and @Size via the client-side validation feature of myfaces trinidad.

the rendered result:

as you might already know extval also initializes the component based on constraints. that results in the correct values e.g. of the maxlength attribute - a section of the page above:

this example uses the same xhtml pages like featureset-01 - so the important part of the facelets-component is:

and the most important part - a section of the entity:

myfaces-extval MetaDataStorageFilter and @JoinValidation

2009-09-27T01:28:00.005+02:00

beside some other improvements a new concept will be available with the next milestone.

a generic storage concept is used to cache the basic meta-data.
all mechanisms which allow dynamic meta-data remain the same. instead of caching the final meta-data for a property just the basic meta-data gets cached. the meta-data which is extracted from the original property. as an addition to the existing dynamic meta-data mechanisms a new concept is available. in comparison to a MetaDataExtractionInterceptor the new MetaDataStorageFilter is just invoked before meta-data gets added to the storage.

it's an additional extension point which allows you e.g. to introduce new functionality which isn't available out of the box.
the property-validation module of extval uses such a filter to introduce a new syntax for @JoinValidation. so it's possible to use a static syntax instead of the dynamic possibilities.

some nice syntax examples are available at one of the example classes.

so maybe you ask - MetaDataStorageFilter are fine but all i need is already possible via a MetaDataExtractionInterceptor. why do i need such filters? yes that's right, however, the new filter concept in combination with the meta-data-storage allow a better performance.

MetaDataExtractionInterceptor ... use them if you have to decide to add/remove/change meta-data very dynamically - e.g. based on the current program-flow, app-state,...

MetaDataStorageFilter ... use them if you would like to introduce a custom but static concept and benefit from the better performance

myfaces-extval-add-on - app-prototyping - 3

2009-09-12T20:25:00.002+02:00

since the original functionality was promoted and will be part of the next version. i added a new functionality. it might be the case that you have issues while prototyping. if so, please report them to the mailing list. anyway, normally you would have to remove extval from the classpath so that you can continue your work. that's due to the zero config approach of extval. you can deactivate it via api's but now you have a further possibility.

the current trunk version (= the next milestone) allows to provide a custom implementation of the extval-context. that allows to introduce alternative approaches e.g. using a dependency injection framework like spring and google guice for internal tasks as well as registering artifacts via dependency injection.

it also allows to mock the extval context. so you can deactivate all/specific features easily. an example is available at [1]. since you have to configure a custom extval-context manually (the class provides the needed information to do it), you can add it to your project permanently. if you would like to check something without extval, just activate the config and afterwards you can remove it again. as mentioned before, it also allows to deactivate specific features easily without using web.xml context-parameters.

anyway, normally you shouldn't have problems. if you find issues, please report them as soon as possible.

[1] http://code.google.com/p/os890/source/browse/trunk/java/web/jsf/extval/prototyping/org/apache/myfaces/extensions/validator/custom/DevExtValContext.java

myfaces-extval java-config extension with gooogle guice style

2009-09-06T13:50:00.009+02:00

why you might need this add-on

there are many different approaches to configure myfaces-extval.
out-of-the-box it uses zero configuration (convention over configuration) as well as an optional java-api which is mainly for internal usages and add-on developers.

so os890 provides an annotation based config add-on. so you don't have to learn the name conventions and the result is typesafe.

the disadvantage is that classpath scanning is required. you can specify packages to be scanned. anyway, it uses an external lib which performs the classpath scanning.

that's the reason for creating an additional add-on which is typesafe and doesn't use an external lib. as mentioned before extval provides an api and a generic artifact mapping mechanism which is used mainly for internal purposes. you can see the usage in the source-code of some add-ons. anyway, app-developers who don't like conventions need a simple but powerful api which is available for the common artifacts.

google guice provides a nice api to bundle modules. so the api of the add-on is similar to the style of google guice. that means you build modules and register the modules you would like to use.

the usage
first you implement a module. in a module you register global artifacts or you bind together a validation strategy with one or more of the following artifacts: constraint, message resolver, meta data transformer.

the following example shows both:

you just have to add your global artifacts or bind together artifacts which have a relationship. so you see that the syntax is quite easy.

via an extval startup listener you can register one or more modules easily.

the result
it's typesafe, explicit, flexible without external dependency and easy to use.
it's available at http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/java_based_config

a working example is available at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/examples/basic/demo_010

myfaces-extval-add-on - app-prototyping - 2

2009-07-30T15:26:00.004+02:00

due to a valid user request (a possible combination with spring security) also the functionality of the extval app-prototyping add-on (and more) will be available in the next release. early adaptors can use the current svn version or the next milestone (m2) which will be available soon.

the add-on won't be obsolete. there will be new functionality!

myfaces extval @ jsfcentral

2009-07-29T08:46:00.002+02:00

the next part of the article series is available at jsfcentral.
thx to the jsfcentral team!

myfaces-extval and pattern based validation

2009-07-21T13:31:00.002+02:00

i saw that people search quite often for an example which shows pattern/regex based validation.
it's quite easy. just use @Pattern and use the regex as value (as expected).

a short example is:
@Pattern("[A-Z][a-z]+")

the examples shipped with every extval release shows the usage as well.
or you can check out the examples from the repository.

myfaces extval and richfaces - 2

2009-07-18T01:28:00.003+02:00

i started a special support module for richfaces.
currently it contains an addition to support labeled faces messages for the rich:calendar component.

myfaces-extval and icefaces - 2

2009-07-18T00:32:00.005+02:00

this is an update of the original post:

1)
extval and icefaces uses similar approaches to implement an internal mechanism. with mojarra there is no issue (by chance). in combination with myfaces-core there was an issue which is fixed with the following combination: icefaces 1.8.2 (see ) and an icefaces support module.

2)
internally icefaces components use some jsf 1.1 mechanisms. that's the reason why you have to use the described fallback. that will change with icefaces 2.0 (which will be compatible with jsf 1.2).
if you are using the support module + the current extval-snapshot + the upcoming version of icefaces (1.8.2 - or a pached version of 1.8.1), you don't have to follow the instructions of the original post. you just have to add the dependencies and everything will work as expected.

a very simple example is available here

myfaces extval - new snapshot available

2009-07-18T00:24:00.003+02:00

early adaptors can use the current snapshot!
it includes some minor internal changes as well as EXTVAL-49 - EXTVAL-53.
furthermore, it's the version used for component-support/icefaces-support

os890 thanks for the great interest

2009-07-15T02:45:00.006+02:00

it's amazing. today i had a look at the google analytics statistics.

since the first announcement of myfaces extval a lot people evaluated the framework, provided ideas for add-ons and new features, sent several e-mails about the great experience while using extval and much more.

half a year ago we saw the first release of extval.
now i can report some nice numbers of os890:
~4000 visitors
~12000 page views
and visitors of 88 countries

furthermore, within 5 months there were over 900 downloads of the introduction slides.
these numbers don't include the statistics of the wiki pages hosted at apache directly.

your custom cross-validation

2009-07-15T02:31:00.002+02:00

if you have a bunch of cross-validation strategies, please have a look at EXTVAL-53!
in case of objections, please send a veto to undo the change.
so far there wasn't a major change which affects custom implementations. this is the first one. we did it to stay consistent internally and because it is very easy to migrate with a simple search/replace action which is safe.

if you just used the annotations, you won't notice a change. you just notice it at custom cross-validation implementations. normally there aren't tones of it, so it isn't a big issue. nevertheless backward compatibility is basically important for us. since it's an important change for some of you, everybody is allowed to veto.

details are available the description of the issue.

german jsf 2.0 article

2009-07-10T08:44:00.002+02:00

enjoy the leading article:

myfaces extval snapshots

2009-07-08T23:32:00.003+02:00

several people asked for a new version via a public maven repository.
in fact the current snapshot contains some great new features. so extval for jsf 1.2.x is now available in the snapshot repository!

(the next release of extval depends e.g. on the final release of jsr303 - so i plan stable snapshots for important milestones. feel free to use the latest snapshot!)

myfaces extval and richfaces

2009-07-06T10:19:00.002+02:00

so far this combination worked when using myfaces-core.
extval-38 (as well as the wiki) shows the required dependencies.
the mentioned issue describes that there is an issue with mojarra.
the good news: the issue is fixed and you can use this combination.
i hope a lot of you (who signaled interest in this combination) will start to test the new version or a patched version of v1.2.2 you can find here.

some details about the original issue:
the generic support module is required, if a component lib does special things behind the scenes.
e.g.: casting renderers,...
so the module uses cglib to allow that. via an extval startup listener the module installs itself. the issue with mojarra is that it uses early configuration. so the extval startup listener of the module gets invoked too late and important configuration tasks are performed by an extval-core class instead of the lazily installed class of the generic support module.

myfaces extval and seam

2009-06-24T20:37:00.003+02:00

you might have looked at my first comparison of extval and the seam 2.x integration of hibernate validator [1]. some of you were interested in a seam support of extval to get the best of both frameworks.

i've tested extval with seam and it worked quite well. to use extval also with richfaces the generic-support module of extval is required. some weeks ago the test with myfaces core was successful. there is just an issue with the combination of (richfaces + extval + mojarra). if you would like to use this combination, feel free to look into the issue and provide some details and/or a patch to fix it.

furthermore, it's possible to use both solutions in parallel.

extend myfaces extval with your own concepts

2009-06-21T23:19:00.000+02:00

it's important to know that extval is able to help you with every possible validation requirement (in view of jsf). if there isn't an out-of-the-box functionality, extval provides a solid base to build your own custom concept. several add-ons already proved that. you can just use them. however, they should basically show that it's quite easy to extend extval. (furthermore, you can integrate a 3rd party validation engine. the first public integration is the integration module of jsr 303 (it will be released after the final release of jsr 303 itself).)

if you miss a feature, just ask if there is already an add-on which solves your requirement(s). some of you already told me nice ideas and i implemented add-ons as possible solutions. however, there are also other solutions to solve these and other requirements. feel free to impl. your own add-on and send me a short e-mail about it :)

the 3rd release will introduce further base concepts. i wrote about constraint aspects and much more. i also impl. some short examples to show that it is pretty easy to extend and re-use the solid base of extval.

let's have a look at a possible scenario:
you would like to use a partial validation concept similar to the mechanism available in jsf 2.0. but extval doesn't provide group validation out of the box. moreover, you don't like the typesafe validation-controller-annotation of some of the available add-ons. you prefer to use a tag-based solution instead? no problem. some lines of code and here we go :)

do you think it's too much effort to impl. your own concept based on out-of-the-box functionalities? see for yourself how easy it is! demo 112 illustrates a simple impl. of the mechanisms mentioned above.

so have fun with extval!

myfaces-extval-add-on - transactional model validation light

2009-06-20T17:30:00.016+02:00

this add-on is a prototype for lightweight transactional model validation.
it also offers basic support for class-level validation.

to mention it once again:
normally extval performs all (simple- as well as cross-) constraint-validations within the validation phase of jsf. however, sometimes it's required to validate after the model was updated. e.g. class-level validations, tree validations,...

to allow these validations this add-on triggers the validation process after the model was updated. furthermore, the original model values of the processed properties (before the model updated) are restored, if there is a violation during model aware and/or class level validation.

in comparison to the full transactional model validation prototype, this add-on doesn't require cglib or spring.

attention: other changes e.g. executed by value-change-listeners,... don't get reverted

1) class level constraints are validated automatically
this mechanism shouldn't be an alternative to jsr 303 - it's just a simple implementation to illustrate the possibility of such a validation. (you are free to implement your own solution based on this mechanism as custom-add-on). moreover, there will be also a similar add-on for jsr 303 class-level validation.

2) a constraint aspect allows a fine-grained definition of constraints which should get validated after the model was updated.

http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/examples/advanced/demo_111

shows a simple example.

some details:

that means:
#1 there are constraints which get validated in the validation phase (as usual)
#2 there are constraints (see ModelAwareValidation.class) which get validated after the model was updated
#3 there are class-level-constraints (see the custom @Vehicle constraint)

the pages don't contain validation logic as usual with extval.

so - let's test the application with invalid values:

this means: validation mentioned of #1 happened

this means: within the validation phase only a constraint of first-name was violated -> the other constraints aren't violated or they should be validated after the model update which isn't performed due to a violation in the validation phase.

this means: only constraints of the model-aware-validation are violated - so you see messages you haven't seen so far.

so far we haven't looked at the transactional validation behavior of the add-on.
the described invalid tries lead to the following behavior behind the scenes:

try #1 and #2:
no model update

try #3 leads to:
model update:
setFirstName: Gerhard
setLastName: P
setManufacturer: MyCar
setModelIdentification: MyCar

violation during model aware and (/or) class-level validation:
-> revert new model values
setFirstName: null
setLastName: null
setManufacturer: null
setModelIdentification: null

in this case null was the last valid model value of all properties (since we haven't had values in the model).

you can find the add-on at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/transactional_model_validation_light

myfaces-extval-add-on - advanced metadata

2009-06-12T19:20:00.005+02:00

this add-on is a collection of some metadata add-ons. you can still use the other add-ons independently. anyway, this collection allows some internal improvements and you don't have to care about possible side-effects. it just works.

currently the add-on combines:
- metadata provider
- virtual metadata
- conditional metadata exclusion
- metadata priority

the combined usage at your properties (of all included add-ons) looks like:

the separation is of course optional - since it's a feature of one of the add-ons, it's used in this example.

you can find the add-on at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/advanced_metadata

myfaces-extval-add-on - conditional metadata exclusion

2009-06-12T19:12:00.003+02:00

extval allows to include and exclude metadata dynamically. currently there are already a lot add-ons out there. this add-on allows to exclude metadata conditionally in a fine-grained manner. furthermore, it's possible to use it for 3rd party annotations as well.

the usage at your properties looks like:

if you have multiple target conditions the usage looks like:

you can find the add-on at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/conditional_metadata_exclusion

myfaces-extval-add-on - virtual metadata

2009-06-12T07:36:00.005+02:00

maybe you thought - extval supports 3rd party annotations (e.g. jpa based validation) and the new typesafe constraint aspects aren't available for 3rd party constraints.

the virtual metadata add-on solves this restriction.

the usage at your properties looks like:

you can find the add-on at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/virtual_metadata

myfaces-extval-add-on - metadata priority

2009-06-11T12:03:00.006+02:00

this add-on allows to force a validation priority (independent of the used order).
it's especially useful for the metadata-provider add-on. so you can prioritize the found constraints. anyway, it isn't bound to the other add-on - so you can use it independently.
(or impl. your own add-on - it's quite simple)

simple example:

you can find the add-on at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/metadata_priority

myfaces-extval-add-on - metadata provider

2009-06-09T23:40:00.021+02:00

this time don't look at the images before your have read the text. it's really important to understand the special use-cases!

basically this add-on shows how to add constraints from an alternative source to the current validation-process. it's possible since extval 1.x.2 via a custom MetaDataExtractionInterceptor. this add-on uses special java-classes as alternative source. however, you can use e.g. xml files,... as alternative source. it's up to you - the way you have to do it is more or less the same.

one idea of metadata based validation is that you have the constraints where they belong to. jsr 303 will allow to define cross-layer constraints (by definition). extval allows the same. anyway, if you have view-layer centric constraints e.g. the out-of-the-box available extval constraints (just the dependency itself is view-layer specific) and your architecture doesn't allow to use them in your entities, you have ~5 choices:

1) only use the jsr 303 support of extval x.x.3+
disadvantage: less features (due to jsr 303 itself)!!!

2) implement your own set of constraints:
advantage: they have no dependency to extval - but you can use extval to validate them in jsf applications. since they don't depend on extval, you can use your own validation engine in the other layers or ... (too much possibilities for this post)

disadvantage: you have to implement, test, maintain,... them

3) use the metadata-provider add-on (or impl. a similar one)
advantage: use existing constraints outside your entities and bind it to the entities in a typesafe manner...

disadvantage: depends on your opinion

4) change your architecture
normally that isn't a real option.

5) don't use extval
do you think that it is a nice option for your jsf-application? i don't think so ;)

you still read this entry - so you are interested in the approach of the add-on :)

just to mention it again - extval allows to validate any constraints. that's a base principle. extval introduces no requirement to your constraints. you can also provide validators for your existing constraints... so you can use constraints which have no (in-/)direct dependency to extval. that's a base principle! but maybe you have special constraints just for your view-layer or you have to bind your fields against existing implementations or you are using something like dto's or ... . this add-on solves possible architecture issues you might have had so far and demonstrates alternative constraint sources in general.

your entity:

the decoupled style via name convention:
the convention is: place it in the same package + the MetaData postfix.

possible issues after refactoring of your application:
- property names of the entity might change (-> use the extends * approach of the following style)
- the class name/location might change (-> you need the 2nd approach)

-> to solve both there is an alternative approach:

the typesafe version:
... you extend the target (entity) and override the properties which are the targets for the ui-specific constraints. the add-on uses scannotation to discover such classes. so you can use any package and class-name. if you refactor the person class e.g. lastName -> surName your ide should automatically rename the overridden properties as well (at least @Override helps you to detect errors). so it's a really typesafe approach. (you have to provide the target class as value of @MetaDataProvider - this might change in the final version)

optionally you can use:
ExtValContext.getContext().addGlobalProperty(
MetaDataProviderStorage.KEY, "your package");
within an extval startup-listener to define a custom package to scan.

in your application you add extval, the add-on and your metadata provider classes to your jsf application. if you have other modules for the other layers, they aren't affected!

so if the only argument against extval/constraint based validation was that you aren't allowed to use the out-of-the-box annotations or ..., you see how the solution could look like (or just use it). and be happy, if you don't have such requirements and you can just use extval as it is :)

you can find the add-on at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/metadata_provider

[preview] typesafe constraint aspects

2009-05-31T23:44:00.005+02:00

the problem

@Required(parameters = {
@Param(key= "severity", value = "warn"),
@Param(key= "display", value = "global")})

... this version allows you to add general information to a constraint. you can think about it as an extension point for constraints. anyway, a string-based approach has some disadvantages.

e.g.:
- not typesafe
- you have to know key/value combinations (no auto-complete offered by the ide)
- refactorings can break your implementation
- ...

so that's quite error prone...

the solution

@Required(parameters = {
ViolationSeverity.Warn.class, DisplayGlobal.class})

such constraint aspects offer a typesafe alternative e.g. for parameters. so you can provide an extval add-on without knowing the concrete constraint implementation.
only the central logic (e.g. of an add-on) has to know what information might be available as parameter at the constraint and how to use this information.

so you can have add-on-x which provides new features and constraints y (they don't know each other). but you can use the features of add-on-x with constraints y (if the constraints have an attribute of the type Class< ? extends ValidationParameter>[])

there are different supported styles. some information are available in the wiki. compared to using strings - it's a bit more effort to create such a parameter implementation. anyway, you don't frequently create new parameter implementations. but you will frequently use them. as you saw - the final usage is typesafe, short and the constraint isn't aware of the specific values behind.

so if you have existing constraints you just have to add an attribute of the type Class< ? extends ValidationParameter>[] and your constraint can automatically join any feature provided via a parameter implementation of extval, an extval add-on or your custom implementation.

[preview] early preview of the 3rd release

2009-05-31T01:39:00.004+02:00

within 2 releases myfaces extval grew up to a very powerful validation platform which is used in several real-world projects. due to that extval solves real-world problems. the pluggable architecture allows you to implement fancy add-ons to provide functionality which isn't available out-of-the-box and wouldn't be possible with the standard validation mechanism offered by jsf. so the question is: "what's next?"

here is a short preview of some new features of the next release. it's a quite early preview. so i might update this post, if there are some new information.

the "big" parts:

#1 jsr 303 (bean validation) validation module
that's a new validation module for extval which allows the unified usage of jsr 303 with jsf 1.x and jsf 2.x
(jsf 2.x has jsr 303 support out-of-the-box. anyway, this adapter will offer some additional typesafe features)

#2 jsr 314 (javaserver faces 2.0)
there will be a new core version which allows you to use extval with jsf 2.0
so you can continue to use your constraints, add-ons,... with the next version of jsf!
(you will just have to update the modules you are using right now. your implementations remain the same.)

some of the smaller but nice new features:

#3 typesafe constraint aspects (= generic parameters)
such aspects allow you to extend the functionality of existing constraints.
furthermore, they allow to introduce shared features. it's also used as base for the next feature.

#4 none-blocking warn mode
several users asked for a "warn mode". that means: a constraint violation is acceptable for the moment. so the severity of the faces message is switched e.g. to warn. furthermore, it doesn't result in a validator-exception. so the jsf lifecycle continues normally and your actions,... get executed.

the syntax isn't final now - the currently available implementation is e.g.:

@Required(parameters = ViolationSeverity.Warn.class)

the parameters-attribute comes from #3 and isn't aware of the severity aspect.
the parameter concept is key/value based and typesafe (any type is allowed!)
a constraint which supports such generic parameters automatically joins available mechanisms/implementations. that means e.g. add an attribute to your constraint with the type Class< ? extends ValidationParameter >[] -- that's it. without additional implementation you can join such features like the warn-mode.

#5 more out-of-the-box available points for intercepting the validation process

#6 solution for your requirements
extval was started to solve common requirements of users. all parts of the framework are inspired by common real-world requirements. so feel free to ask for new features, add-ons,...

as you see some of the features depend on other releases like the ri implementation of jsr 303. so it's hard to predict the release date.

myfaces-extval-add-on - app-prototyping

2009-05-13T23:45:00.003+02:00

today i received a request of a myfaces extval user.

the question was how to use myfaces extval in a prototype with input components without value bindings.

the solution is an add-on which is available at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/prototyping

myfaces extval release news 1.x.1 -> 1.x.2

2009-04-26T21:56:00.001+02:00

these slides give a short overview of the new myfaces extval v1.x.2 features.

MyFaces Extensions Validator 1.x.2 News

release of myfaces-extensions-validator

2009-04-20T16:53:00.001+02:00

the apache myfaces team is pleased to announce a new release of myfaces-extensions-validator!

released versions:

extval 1.1.2 (for jsf 1.1.x)

extval 1.2.2 (for jsf 1.2.x)

[updated] myfaces-extval config extension

2009-04-15T12:10:00.001+02:00

extval 1.x.2 provides some new mechanisms. therefore the annotation based config also provides some new annotations.

new annotations:
- MetaDataExtractionInterceptor
- NameMapper
- FacesMessageFactory

extval allows name mappers for different areas. @NameMapper makes it easy to provide a custom name mapping strategies. the following screenshot shows an example how to use @NameMapper

myfaces-extval-add-on - @SecuredAction

2009-04-15T00:54:00.002+02:00

you might already know that you can use myfaces extval for much more than validation. this new add-on shows how simple it is to provide add-ons for different problem domains. it's available at http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/secure_actions.

@SecuredAction is an annotation to secure the execution of action methods. it's independent of the concrete command component and offers several features. normally you can secure such actions via the rendered attribute. however, maybe you would like to restrict method execution based on new model values (which were updated at the same request). there are several other use-cases where you can use it instead of the required attribute of the command component. at least it is a feasibility study for further extval add-ons.

the base idea is similar to the @RolesAllowed of tobago. this extval-add-on offers a bit more than a role check. if you are just interested in the same functionality without using tobago, it's quite easy to add an "allowedRoles"-attribute as well. it isn't implemented out-of-the-box, because the existing approach of permittedIf-conditions is much more generic.

@SecuredAction offers several features - here are some short examples:

that means:
if one of the condition(s) returns false the "deny"-method is called instead of the annotated method. also the optional return-value is used as expected. so you can execute custom logic in case of denied access.

the following example shows a shorter syntax for the "deny"-method. it's possible to refer a local method directly:

it's also possible to overrule the outcome. the following example forces to redisplay the same page instead of displaying a different one:

furthermore, in case of denied access, you can automatically add a (global) error message via:

the add-on automatically looks at the same package of the class (which hosts the secured action method(s)). the name of the resource bundle is: securty_messages. it's just for demo cases. for real word usages you can register e.g. an existing bundle within an extval-startup listener. you can register a message-bundle base-name or for jsf 1.2+ also a message-bundle var-name.
sample:

//use an existing message bundle
ExtValContext.getContext().addGlobalProperty(
SecuredAction.MESSAGE_BUNDLE, "at.gp.demos.messages.my_messages");

//use an existing message bundle var-name
ExtValContext.getContext().addGlobalProperty(
SecuredAction.MESSAGE_BUNDLE, "#{myMessages}");

in the message bundle you have to add a summary and detail message - e.g.:
action_not_allowed = action not allowed
action_not_allowed_detail = action not allowed - please switch the role

the default case is that @SecuredAction doesn't change the lifecycle execution. via an additional attribute it's possible to change that. the following example always leads to an execution (of the secureAction) in the "apply requests values"-phase. if it's permitted to call the secured method, the original lifecycle execution also doesn't change in this case.

it's also possible to define specific pages which need a secured action method:

to define different scenarios, it's possible to use multiple annotations at one method. you can do that via:

myfaces-extval and prime faces

2009-04-07T22:11:00.003+02:00

today i tested extval in combination with primefaces. it worked without modifications. i just added:
- myfaces-extval-core
- myfaces-extval-property-validation