IdentityStore/AuthenticationMechanism properties validation
Guillermo González de Agüero
Guillermo González de Agüero:
Hi,We already talked about validation of attributes ( and ) and canceling deployment in case of invalid ones. At that time we came to the conclusion that it was too difficult to do and that it was better not to standarize that behavior at this time.
But then with  I had another idea I'd like to propose to the EG. The other time we talked about the runtime validating properties for the stores. What I propose now is that identity stores themselves validate their parameters. I've thought of two posible ways:
- Add a "init() throws Exception" method to IdentityStore/HttpAuthenticationMechanism.
- Specify that an exception thrown from a @PostConstruct annotated method on an IdentityStore or HttpAuthenticationMechanism makes deployment fail. Only unchecked exceptions can be thrown on @PostConstruct methods.
This behavior is aligned with what Servlets/Singleton EJBs/eager ApplicationScoped CDI beans do. The only required change is that identity stores and authentication mechanism would need to be created at deployment time, to be able to cancel deployment if needed.
I'd go for the @PostConstruct alternative as it's the less intrusive and more "CDIish" way to do it. Changes to the spec and implementation are minimal, while providing users the ability to validate their own artifacts. This would also help  case reducing runtime exceptions to just unexpected ones.
What do you think?