bike part reward : setting bean ID property automatically

[Tom Zeller]

> 1) (Channelling Ian) We need to add an interface to ComponentSupport which
> implies settability of identity (and we need to change the javadoc on
> IndentifableComponent which is wrong in a number of ways).  I am not
> proposing adding to the AbstractClasses.  This feels like a requirement no
> matter what else we do.

Could you say more regarding why we need to add an interface to
ComponentSupport ? My assumption was the interface would be like
IdentifiableComponent, but replacing getId() with setId().

> 2) We need to retro fit this Interface to 20 odd class which expose #setId()
> as public (see below)

Thanks for listing those.

> 3) This then allows us to extend Tom's change away from a specific class to
> all implementors of this interface.   We'd need to move the
> ProfileActionBeanPostProcessor code to somewhere more general and the bean
> definition to an upper level (or possibly introduce a different
> post-processor).

Probably move what I did to a new BeanPostProcessor.

> 4) I'd suggest that as a development aid only, and only for a short time, we
> also add a log message to the BeanPostProcess to call out the case where the
> two ids are the same - this should allow us to clean up our xml files (which
> we need to do anyway).

I am okay with log.warn in the long term, curious why you suggest
short term only.

> I'll admit that having a code which effectively duplicates the work of
> Spring worries me, but given that we already have post processors it's not a
> big deal and anyway I'm not sure that I see a cleaner mechanism.

Agree, and thanks Rod.