Actions should not be Identifiable ?

[Rod Widdowson]

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

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

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

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

> >Component.getId() then can be @nonnullafterinit.
> 
> I think the annotation's just wrong now.

I'd agree, modulo the observation that in order to be strictly correct we
would then need to make the Identifiable Interface extend the Initializable
one or only set the annotation on the base classes.

> I don't think getLogPrefix needs to be public.

I'd completely agree -it isn't in any of its current implementations.  We'd
also need another protected abstract method to setup the "type"
("DataConnector", "AttributeResolver", "AttributeFilter"). By extension
these would have nothing to do with the Identifable & Identified interface
and purely be support methods provided by AbstractIdentifedComponent.