Further questions on deprecation.

[Rod Widdowson]

> For anything that's not being built by the Spring parsers, don't we have to do that if we want to deprecate something? 

That would be my preference certainly.  But it could be argued that a combination of @deprecate in the code, removal of use from all
our bean definitions and careful documentation would suffice.  But why both for the cost of adding some logging?  

It sounds as though you agree with me that we need to log, so I'll add a case per product to cover the work of logging deprecated
APIs and do my own.

> I don't know if it's worth doing for things the parsers already warn about.

"Up to a point Lord Copper".  The customer parsers can only warn about use of custom syntax (i.e. changes in schema files).  They
shouldn't (except in exception circumstances like legacy relying party) be calling deprecated APIs (changes in java files). Changes
to beans have to be self-deprecating since they can always be called by custom wiring.


Thanks
R