[Springframework-developer] Singleton pre-instantiation, and general bean instantiation strategy

[Colin S. <col...@ex...>]

I was wondering about the rationale for (always) pre-instantiating 
singletons. Since most beans in my contexts are singletons, in practice, 
I find that this brings in the kitchen sink, even when a good portion of 
the stuff in the context will not be used. Now it is true that the more 
heavy-weight stuff, like the Hibernate session factory, is always used.

Have people found on-demand instantiation for singletons problematic in 
the past?  Once issue I can see is the fact that you get feedback on 
config problems much later, but this is manageable in a lot of cases 
(i.e by initially running in a pre-instantiation mode, and switching to 
on-demand later, etc.).

I was contrasting this strategy, and the general strategy for bean 
instantiation, with HiveMind's, where HiveMind create services 
completely on demand. That is, when you ask HiveMind for a service, what 
it gives you back is (always) just a proxy. The initial use of that 
service will force HiveMind to actually create it. If a service in 
HiveMind is created, and it's properties are populated with other 
services, those services will never actually be created until used. Of 
course in Spring, if you get a bean from the factory, any other beans it 
references as properties will also be created (unless you get into some 
custom usage of interceptors in a context). Both valid approaches, but I 
am just wondering if there is a use-case for supporting the HiveMind 
model as well?

Regards,
Colin