codi meets jboss as 7

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)

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

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

6th release of myfaces-extensions-cdi

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

[slides] codi conversations

MyFaces CODI Conversations

5th release of myfaces-extensions-cdi

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

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

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

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

[benchmark] myfaces codi scopes - codi vs orchestra

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

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

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

[benchmark] myfaces codi scopes - OWB vs Weld

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

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

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

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

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

apache myfaces pmc chair

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

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

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

codi examples with myfaces stylesheet

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

somehow different (click on):

codi meets the cloud

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

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

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

2nd release of myfaces-extensions-cdi

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

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

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

new myfaces-extval logo

myfaces-codi logo

myfaces-codi introduction slides

MyFaces CODI v0.9.0 News

1st release of myfaces-extensions-cdi

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

[infra] myfaces extensions meet dvcs

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

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

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

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

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

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

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

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

there is a new extval add-on (new location). 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

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

extval meets cwiki.apache.org

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

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

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

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

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

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

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

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

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

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

metadata based validation @ejug seminar (german)

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

Metadatenbasierte Validierung

happy birthday myfaces-extval

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

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

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

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

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

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

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

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

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

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

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

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

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

myfaces-extval and pattern based validation

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

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

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

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

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

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

enjoy the leading article:

myfaces extval snapshots

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

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

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

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

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

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

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