type-safe message handling with bean-validation

nine years ago i implemented ExtValMessageInterpolatorAdapter. back then it allowed to combine the MessageInterpolator (bv) and the MessageResolver (extval). with that it was easy to load violation-messages from a custom message-source. it was needed because there was no agreement in the eg about it. from my first presentation about bv (in 2009) until now i always hear the same (valid) feedback (that there is a gap). the result (back then) was BVAL-217, but besides that nothing changed. four years ago there was the last (official) extval-release. the main reason was that most projects limited themselves to std. bv, because jsf as well as some component libs filled the most important gaps. years later there are still extval features which aren't part of the spec. (message-resolving is just one of them). as a "replacement" projects drop the corresponding requirement/s, use weird workarounds, "copy" parts of frameworks like extval or they moved away from bv and/or jsf anyway.

recently i was asked if it is possible to load bv-violation-messages from a database. furthermore, it would be beneficial to re-use custom concepts for type-safe messages. in such cases apache codi and later on deltaspike helped a lot to benefit from (or implement) such features easily. however, adding such frameworks isn't always an option (although they would help a lot) and in some cases there are still some limits.

so i extracted some parts from extval, codi and deltaspike and combined it with new ideas.

without type-safe messages available with deltaspike, i usually use something like the following pragmatic approach for type-safe messages:

that's easy to use, refactor and it's even possible to create an extension which autom. detects all enums implementing that interface and check for message-id clashes. however, when it comes to bean-validation we have the issue that we can't reference the message-id in a type-safe manner (due to the limited capability of java-annotations in combination with the fact that bv specifies that the message-attribute of constraint-annotations needs to be a string).

to allow at least one enum-type per bv-constraint we can benefit from the composite-constraint feature which is available since v1.0. with that we can define e.g.:

furthermore, in some cases it's useful to use information about the property in the violation message. in the listing above it's realized with the constraint-attribute propertyLabel. with std. bv you can hardcode that info. the main issue here is that there is no i18n support for the constraint-attribute value. instead of (manually) post-processing the violation-messages, it would be better to use the std. key-syntax to reference a different value in the message-source.

to summarize it, we would like e.g. to store the violation-text:
The length of '{propertyLabel}' should be between '{min}' and '{max}'
in a database, create a custom enum which implements a custom interface like MessageId and optionally (type-safe) labels which support i18n (the label-texts are stored in message-sources as well).
for the property-label we also create the corresponding entries in the database.
using those parts with @Length would e.g. look like:

and the resulting message is e.g.:
The length of 'Surname' should be between '2' and '50'

the propertyLabel attribute can be a string following the std. key-format to support i18n. alternatively it can be also a custom enum (implementing a custom interface). it isn't the same, but similar to the type-safe message-enum itself. due to the autom. interpolation the label-enum needs to be slightly different - e.g.:
the (custom) LabelId interface is just used to distinguish labels from the message itself. since the label is a constraint-attribute it gets interpolated by bv itself and therefore we need to force the key-format to identify the parts which need to be resolved in an own step.

to realize all that you just need to add the ds-bv-label-addon e.g. by adding https://rawgit.com/os890/ds-bv-label-addon/public as maven-repository and afterwards the maven-dependency as well as the custom message-interpolator:

to resolve violation-messages e.g. from a database you can add one or more beans like:
if you like to use message- and/or label-enums you can implement one or more beans like:
the git-repository illustrates different use-cases including one which shows how to share one constraint between different modules without using a shared message-enum (but still keep the type-safe approach) by using a shared composite-constraint in combination with a composite-constraint per module (which delegate to the shared composite-constraint).

speedup the tomee startup

apache tomee is based on apache tomcat and adds the java-ee web-profile on top of it (based on apache projects like myfaces, openwebbeans, bval,...). the runtime performance is great and also the startup time is nice. esp. during the development phase every second hurts (at least a bit). with a simple change it's easy to remove some overhead! the following part shows the difference.

tomee just adds some libs to tomcat. that means you can also use a different version of tomcat easily - so it's easy to get tweaks and bugfixes of the latest version of tomcat also for tomee and you can use the std. tomcat plugin for your ide. however, that also means you (can) get some overhead - currently the demo apps shipped with tomcat cause such an overhead during the server startup. just by removing the demo web-apps you can reduce the startup time of tomcat itself by about 50 percent (here from ~1.4 seconds to ~0.7 seconds). for tomee you can do the same, but you have to keep a webapp called "tomee" (it's needed to use remote-ejbs - so it isn't a demo). if you don't need remote-ejbs, you can remove all webapps shipped by tomee to improve the startup performance even further.

the following chart shows the differences of the mentioned constellations. the value for jboss as7 is just a reference value.

the following chart shows the overhead introduced by tomee (compared to a standalone tomcat).

please note:
1)
all those values depend on the machine, operating-system,... - in addition the values are rounded and should just give a basic impression about the differences (please don't see it e.g. as a tomee vs as7 comparison).

2)
there are 2 values printed during the tomcat/tomee startup. the first one is listed as "Initialization processed in ..." and  the second one as "Server startup in ...". the values in the charts always show the sum of both ( "Server startup in ..." sounds like the sum but it is not the sum of the full startup process).

3)
as7 is also based on tomcat but the integration is way deeper and therefore it isn't given that the startup of tomcat itself takes the same time as with tomcat standalone or tomee (that's the reason why there is no separation for as7 in the second chart).