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.
Guillermo González de Agüero
El mié., 26 jul. 2017 a las 7:56, Guillermo
González de Agüero (<z06.guillermo@...
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
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.
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
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.
do you think?
Guillermo González de Agüero:
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803