I'll defer to Arjan as to the wisdom of this, but it's almost certainly to late to implement this.

We're scheduled to deliver FAB materials to the JCP 7/31 (i.e., today), although I don't think we'll do so until Tuesday (8/1). We'll miss slip our FAB date a week if we don't deliver the materials by 8/2.

In order to deliver FAB materials we need the TCK to be done, and a clean run of tests against the RI.

On 07/28/2017 01:12 PM, Guillermo González de Agüero wrote:

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.

Regards,

Guillermo González de Agüero

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

Hi,

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?

Regards,

Guillermo González de Agüero:

[1] https://javaee.groups.io/g/javaee-security-spec/message/324
[2] https://github.com/javaee/security-soteria/issues/104
[3] https://github.com/javaee/security-soteria/pull/124

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803