The context makes it entirely appropriate. A FactoryBean allows you to construct complex objects, or construct objects Spring can't easily create itself (e.g. JndiFactoryBean). A ProxyFactoryBean builds Spring AOP proxy beans.
As it turns out, there was no need for the class as it has been deprecated. However, providing an abstract singleton scoped proxy factory bean is indeed convenient. If there was a need for a factory that creates AOP proxies then it would be very useful to have an abstract class that implements most of the methods for you, and create them with singleton scope. In that case, AbstractSingletonProxyFactoryBean is sensible.
It's a corner case. It was used by one class, but that was deprecated later, so this was deprecated as there wasn't really a need for the convenience class.
I take this lot of stuff seriously because I see a lot of ignorant pattern bashing by those who haven't taken the time to understand why patterns are very useful and potentially can make OOP code cleaner and easier to maintain.
For the record, I spent 10-12 years coding Java (the last 4 or so w/ Spring). Lots of OOP, lots of pattern based enterprisey big boy stuff. I definitely have a solid (but atrophying) understanding of the concepts. I get that they're the right way to do big Java apps. But Java makes implementing them fucking laborious. Back when that was all I knew, it seemed elegant and I was used to the scaffolding.. but the truth is that in a number of other languages the same patterns require so much less scaffolding and even thought, that we don't even notice them. They're a given.
I give my users vastly more value-per-line-of-code now than I ever did writing Java.
That said, I have nothing against Java or folks that enjoy doing it... but even when it was a language that I was knee deep in and stoked on, I was able to laugh at some of the shark-jumping complexity of these cartesian products of patterns that would arise.
As it turns out, there was no need for the class as it has been deprecated. However, providing an abstract singleton scoped proxy factory bean is indeed convenient. If there was a need for a factory that creates AOP proxies then it would be very useful to have an abstract class that implements most of the methods for you, and create them with singleton scope. In that case, AbstractSingletonProxyFactoryBean is sensible.
It's a corner case. It was used by one class, but that was deprecated later, so this was deprecated as there wasn't really a need for the convenience class.
I take this lot of stuff seriously because I see a lot of ignorant pattern bashing by those who haven't taken the time to understand why patterns are very useful and potentially can make OOP code cleaner and easier to maintain.