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

[Cantor, Scott]

On 2/15/14, 7:05 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>
>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.

+1

>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.

But then presumably we change the inheritance later for the classes that
are already manually exposing a public setId()?


>DESTRUCTABILITY
>
>- For the sake 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

+1

>- Everywhere in our configuration that there is currently a
>³default-init-method² needs to gain a ³default-destroy-method².

That should be done anyway, since the beans default doesn't really mean to
exclude one or the other.

>VALIDATABILITY
>
>- What about data storage?

That code's not really being used and we can add it back if we implement
something that would call it.

-- Scott