NoSuchFlowExecutionException

[Dan McLaughlin]

Sorry, I thought you were talking about something else.  Yes, I'm
familiar with the bean init/destroy. In our own code base we've added
init/destroy methods throughout because we do hot deployments multiple
times a day in our dev and test environments and if we didn't we
leaked so much memory we could only do about 10 hot deployments before
we would blow out the heap.  The IDP we've never been able to hot
deploy very often because of the same issue.

Although I was noticing something interesting yesterday when I had
debug logging enabled for spring.  Spring seems by default to be
looking for a destroy method named "destroyMethod" by default, which I
had never seen before.  We also name all of our destroy methods
"destroy" and so when we define our beans we set
destroy-method="destroy", same as in the change you checked in.    But
now I'm starting to wonder if we just named our destroy methods
"destroyMethod" instead of "destroy" if Spring would automatically
call that method even if we didn't explicitly define it in our bean
declarations.

--

Thanks,

Dan

On Thu, Oct 20, 2022 at 11:44 AM Cantor, Scott <cantor.2 at osu.edu> wrote:
>
> >    Curious.  When you say init/destroy stuff.  Is that what explains when
> >    I have debug logging enabled I see it trying to initialize LDAP
> >    properties, even though we aren't using LDAP?
>
> No. Spring normally manages bean lifecycle, we got cute and added our own hooks and requirements to init/destroy objects that Spring will call and if it doesn't know to call them, it doesn't.
>
> Properties don't do anything by themselves. Beans that are meant to be conditionally created have to be lazy-init regardless and the LDAP stuff generally is. It's not going to start trying to talk to a non-existent LDAP server.
>
> -- Scott
>
>