Re: IdentityStore/AuthenticationMechanism properties validation

Guillermo González de Agüero

Just a ping here as the FAB is scheduled for this Sunday. Does anyone have an opinion here?

Both implementation and spec changes should be minimal and I could work on them myself if you agree on this.


Guillermo González de Agüero

El mié., 26 jul. 2017 a las 7:56, Guillermo González de Agüero (<z06.guillermo@...>) escribió:

We already talked about validation of attributes ([1] and [2]) 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 [3] 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 [3] case reducing runtime exceptions to just unexpected ones.

What do you think?


Guillermo González de Agüero:


Join to automatically receive all group messages.