8:34 a.m.
Hi All,
I'm using Weld in Open Liberty and seeing a NullPointerException from
WeldInitialListener when an app fails to start. The scenario goes
something like this:
1) Server and app starts to start.
2) An error occurs in my app code throwing an uncaught exception.
3) Liberty's web container code then attempts to stop the
still-not-yet-started app - this calls the WeldInitialListener's
contextDestroyed method without ever calling the contextCreated method.
4) Because contextCreated was never called, there is a NullPointerException
thrown from contextDestroyed (the lifecycle field is null), which ends up
masking the root cause of the problem.
I am in the process of fixing part of the problem (not logging the original
exception) in Open Liberty issue 13124[1], but I wonder if we should also
check if lifecycle is null in the contextDestroyed method[2] to avoid the
NPE.
Thanks,
Andy
[1] https://github.com/OpenLiberty/open-liberty/issues/13124
[2]
https://github.com/weld/core/blob/2fe5d1f64c03b89cc562a14cda317098225590c...
9:08 a.m.
Hello,
thanks for reporting this.
I am not quite following how you manage to register a listener, *not* invoke
contextInitialized but attempt to invoke contextDestroyed on it?
Is the error happening during initialization of other listeners?
To me it seems like Liberty shouldn't try to do that, e.g. only invoke
contextDestroyed for listeners that had a chance to perform contextInitialized.
I think I saw similar approach in Undertow (used in WFLY) but I am not sure from the top
of my head.
Adding null checks is also an option of course, but I kind of think this situation
shouldn't really happen.
I might be wrong, feel free to disagree :)
Regards
Matej
----- Original Message -----
From: "Andy McCright" <j.andrew.mccright(a)gmail.com>
To: weld-dev(a)lists.jboss.org
Sent: Wednesday, July 22, 2020 3:34:35 PM
Subject: [weld-dev] NullPointer in WeldInitialListener
Hi All,
I'm using Weld in Open Liberty and seeing a NullPointerException from
WeldInitialListener when an app fails to start. The scenario goes something
like this:
1) Server and app starts to start.
2) An error occurs in my app code throwing an uncaught exception.
3) Liberty's web container code then attempts to stop the
still-not-yet-started app - this calls the WeldInitialListener's
contextDestroyed method without ever calling the contextCreated method.
4) Because contextCreated was never called, there is a NullPointerException
thrown from contextDestroyed (the lifecycle field is null), which ends up
masking the root cause of the problem.
I am in the process of fixing part of the problem (not logging the original
exception) in Open Liberty issue 13124[1], but I wonder if we should also
check if lifecycle is null in the contextDestroyed method[2] to avoid the
NPE.
Thanks,
Andy
[1] https://github.com/OpenLiberty/open-liberty/issues/13124
[2]
https://github.com/weld/core/blob/2fe5d1f64c03b89cc562a14cda317098225590c...
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
12:40 p.m.
Hi Matej,
Thanks for the quick response. I think you make a good point, and I have
started the conversation with the Open Liberty web container developers to
see what they think - but ultimately, I agree that it doesn't make much
sense to destroy something that was never initialized.
That said, I don't think a null check would hurt anything - this would only
occur on app shutdown, so performance shouldn't be a factor. I'll leave it
up to you. The changes to how the startup exception is logged in Open
Liberty fixes my primary concern (determining the original startup problem).
Thanks for considering!
Andy
On Wed, Jul 22, 2020 at 9:08 AM Matej Novotny <manovotn(a)redhat.com> wrote:
Hello,
thanks for reporting this.
I am not quite following how you manage to register a listener, *not*
invoke contextInitialized but attempt to invoke contextDestroyed on it?
Is the error happening during initialization of other listeners?
To me it seems like Liberty shouldn't try to do that, e.g. only invoke
contextDestroyed for listeners that had a chance to perform
contextInitialized.
I think I saw similar approach in Undertow (used in WFLY) but I am not
sure from the top of my head.
Adding null checks is also an option of course, but I kind of think this
situation shouldn't really happen.
I might be wrong, feel free to disagree :)
Regards
Matej
----- Original Message -----
> From: "Andy McCright" <j.andrew.mccright(a)gmail.com>
> To: weld-dev(a)lists.jboss.org
> Sent: Wednesday, July 22, 2020 3:34:35 PM
> Subject: [weld-dev] NullPointer in WeldInitialListener
>
> Hi All,
>
> I'm using Weld in Open Liberty and seeing a NullPointerException from
> WeldInitialListener when an app fails to start. The scenario goes
something
> like this:
> 1) Server and app starts to start.
> 2) An error occurs in my app code throwing an uncaught exception.
> 3) Liberty's web container code then attempts to stop the
> still-not-yet-started app - this calls the WeldInitialListener's
> contextDestroyed method without ever calling the contextCreated method.
> 4) Because contextCreated was never called, there is a
NullPointerException
> thrown from contextDestroyed (the lifecycle field is null), which ends up
> masking the root cause of the problem.
>
> I am in the process of fixing part of the problem (not logging the
original
> exception) in Open Liberty issue 13124[1], but I wonder if we should also
> check if lifecycle is null in the contextDestroyed method[2] to avoid the
> NPE.
>
> Thanks,
>
> Andy
>
> [1] https://github.com/OpenLiberty/open-liberty/issues/13124
> [2]
>
https://github.com/weld/core/blob/2fe5d1f64c03b89cc562a14cda317098225590c...
>
>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
2017
days inactive
2017
days old
2 comments
2 participants
participants (2)
-
Andy McCright -
Matej Novotny