net.shibboleth.utilities.java.support.component.*

Rod Widdowson rdw at steadingsoftware.com
Sat Feb 15 07:05:22 EST 2014


I took an AI yesterday to write up
net.shibboleth.utilities.java.support.component discussion.  I want to
distinguish my opinion from what I heard as decided so this mail is in two
parts:

DECIDED:
This is what I heard as decided in the meeting or in previously mail

1) IdentifiableComponent is to be renamed to IdentifiedComponent
2) We will introduce an Interface with the #setId(String) method.
3) We will new a new bean post processor (in spring-extension) for the
setting of the id (and remove the code from ProfileActionBeanPostProcessor
4) We will remove all vestiges of ValidatableComponent from the code.  
5) We will collapse Abstract classes such that if InitializableComponent is
implemented then so is DestructableComponent.

PROPOSED:
This is what I propose

- IDP-368 deals with Nameability
- A new case deals with removing ValidatableComponent
- Another new case deals with making all InitializableComponents
destructible.

NAMEABILITY

- The new Interface noted in (2) above is called NameableComponent and it
extends IndentifiedComponent
- We introduce a new base Class AbstractNameableInitializableComponent.  I’m
pretty sure that all the classes I identified extend
AbstractIdentifiableInitializableComponent directly so there is no issue
about intermediate classes gaining a public setId.  

DESTRUCTABILITY

- For the same of short names, and given that we have stated that
Initializable implies Destructable, I propose that rather than remove
AbstractIdentifiableInitializableComponent and
AbstractInitializableComponent and leave
AbstractDestructableIdentifiableInitializableComponent and
AbstractDestructableInitializableComponent, we just remove the longer named
classes (it also means for less wide spread changes since not many classes
extend the destructible variants
- Everywhere in our configuration that there is currently a
“default-init-method” needs to gain a “default-destroy-method”.
 - All the above means we end up with one less base class.

VALIDATABILITY

- When we remove the Validatable interface we strip out all associated code.
The data connectors implement Validator, not ValidatableComponent.
- What about data storage?

Absent any other offers I’ll take on this work since it is pretty simple,
and I’ll plan to do it next Saturday when killing the jenkins and
rototilling huge checkins will cause less perturbance.

Comments? Thoughts?



More information about the dev mailing list