Name Mapper which delegates the name mapping, extract the name and convert it to a bean name + prefix
target: configure a validation strategy via a managed bean facility -> allows to inject other beans
instead of api calls + hardcoded bean names
allowed bean scopes:
the validation strategy is stateless: application/singleton
the validation strategy is stateful: none/prototype
don't use the session or a conversation scope
it isn't linked to jsr 303
it's just a helper for proxies - you just need it, if you define the validation strategy as bean and
e.g. spring creates a proxy for it.
it isn't linked to jsr 303
it's just a helper for proxies - you just need it, if you define the validation strategy as bean and
e.g. spring creates a proxy for it.
during the registration process the information gets evaluated
instead of a class array a string array is used so that it's possible to implement
an artifact for different modules. if an add-on restricts an artifact to specific modules,
not all modules have to be used by the webapp. if a module key is unknown, the artifact won't get registered
for this module. if an artifact doesn't implement this interface, it gets registered for all modules
path recording is performed to get a key for cross-validation
every base after the first call which is null stops recording
with a dynamic map syntax the last property in the middle of an expression has to be a string.
centralized in order that these information aren't spread over the complete code base
+ some of them can be customized within a custom impl. of the bean
(extend this class and provide it via convention or web.xml)
the static api should only be used
needed for some component libs - if required initialization is used e.g. for visual indicators
but features like severity aware validation aren't used.
e.g. to allow in metadata extraction interceptors to know if they are invoked during validation or
component initialization (if needed)
example: client-side validation - some functionality shouldn't be processed during rendering
API:
parts you might need for custom implementations and which are quite stable in view of changes
INTERNAL:
if you think about referencing an artifact which is marked as internal, ask for support.