Actions should not be Identifiable ?

[Tom Zeller]

>> >Not sure of the context, but I was leaning to a public method which may
>> >throw an unchecked exception
>
> Assuming we are talking of #getId(), why would it need to throw any sort of
> exception?

It wouldn't, I was thinking of setId(), and was being confusing.

>>  to flatten the parent type hierarchy.
>
> I'm still struggling to understand what value this brings us.  It certainly
> comes at a cost because if we moved getId down into a lower class we'd end
> up having to add setId to many classes all of which we have decided did not
> need an identity.  From what I have heard so far it seems that a better
> discussion is whether some of our classes are being derived from the wrong
> base class; we have already identified all the prototype beans, are there
> others?

I was wanting "one" base class, e.g. AbstractComponent.

>> >Defaulting the ID to the default impl of toString() sounds ok to me.
>
> No.
>
> Whilst I'm happy to be argued out of it right now this feels like a really
> bad idea.  If we have decided that something needs to have an identity then
> we need to check that during initialization.  Adding a default value just
> allows difficult-to-find bugs to slip by and our job is to find bugs as
> cheaply as possible ("shift-left").
>
> If the ID is being used for logging purposes then no value is added by an ID
> set to the class name since it is there already, if the ID is used for more
> than that then you have just introduced a bug.   Either way it will be
> costly to fix after release.

Well, I guess what is bothering me is that our design[1] says that
Components have a "unique identifier", which is not actually the case,
and that unique ID is used mostly for logging and Spring - but is
defined in a module (java-support) which is specifically Spring
independent.

[1] https://wiki.shibboleth.net/confluence/display/IDP30/General+Architecture

> I guess that my point is that if we find ourselves needing a default then
> the class is derived from the wrong parent.

I was hoping to provide a single abstract parent for Components.

Apologies for the confusion.