Closed wind57 closed 6 months ago
Hello!
Thanks a lot for your question and attention you payed to our meetup.
Yes, I absolutely agree with your comment. Our purpose was to show that starting GenericFactoryBeanApplication
can't lead to NullPointerException
inside PokemonFactoryBean::getObject
. But you're right , there was no any PokemonFactoryBean::getObject
call. So we need to improve our GenericFactoryBeanApplication
demo part with configuring some new bean with our Pokemon
beans as dependencies. It will be fair enough, such configuration leads to PokemonFactoryBean::getObject
call.
Sorry for not replying earlier, was on vacation.
Thx for acceptance! I'll close this one since we agreed on it.
I was watching the video you put up on youtube and I found the explanations you have for that
NullPointerException
a bit too "thin" and while you did indeed understand the problem at hand, the explanation given is not accurate, at least it's not complete.The idea to make such a video and explain how
BeanFactoryPostProcessor
works is great, it just needs to be amended here and there. I hope you don't mind me opening such a discussion.The
NullPointerException
is not coming of the result of the creation ofPokemonFactoryBean
. If you properly debug the code, you will notice thatPokemonFactoryBean
is created just fine, indeed because of that eager init flag that is set totrue
. Granted, you do understand correct that oncePokemonFactoryBean
bean is created, it needs a bean of typePokemonConfigurationProperties
simply because both of its constructors take it as argument , and Spring creates a "partial" bean for it (without any of its fields being filled).The exception comes from the second factory:
PokemonMasterFactoryBean
. Same init flag that is set to true is causing this bean to be created, but its constructor:says that it needs an instance of
Pokemon
. So Spring does a very simple thing: tries to find/create one. Since one such bean does not exist,PokemonFactoryBean::getObject
will be invoked and this is where that partialPokemonConfigurationProperties
matters. This is where calling any method on that instance will return anull
, because as you already noted its too early for its fields to be populated, thus thatNullPointerException
.What might confuse someone (as me) about your explanation, is that around
25:14
you are stating that fields fromPokemonConfigurationProperties
are populated (for theGenericFactoryBeanApplication
), which is not correct. Those fields are not populated either, but it does not matter because no one actually needs aPokemon
bean for that example, as suchPokemonFactoryBean::getObject
is not called at all, thus you do not see that exception.