WIP: WELD-2503 Create Exception handler for applications run using StartMain #1838

smoyer64 · 2018-06-06T19:59:33Z

Work in progress towards WELD-2503 - please review.

Theory

ExceptionHandler's can be registered with StartMain through the ServiceLoader mechanism. Each ExceptionHandler specifies one or more types of that it will support (one danger is that only the first ExceptionHandler found for a type will be called and the ServiceLoader has no mechanism for ordering the services it loads).

An exception handler can:

Analyze the supplied Throwable
Produce an appropriate log message (or more than one line if desired)
Suppress or log the stack-trace of the Throwable
Terminate the program with a custom error code using System.exit() - StartMain

StartMain has been altered to return an exit code of zero if the program terminates normally or an exit code of one if the program terminates due to an exception. Of course, the application itself is still free to exit with its chosen error code at any time - the ExceptionHandler is only called when any checked or unchecked exception is allowed to reach the main() method.

It's recognized that some Throwable instances may contain very complex internal structures - understanding this content is solely the responsibility of an ExceptionHandler registered for the offending type.

Outstanding tasks

Add ExceptionHandler registration to StartMain
Add test coverage
Add javadocs
Add documentation
Create POC example using Wildfly's Microprofile-Config and DeploymentException

WeldJenkins · 2018-06-06T20:00:01Z

Can one of the admins verify this patch?

manovotn · 2018-06-07T09:08:56Z

ok to test

Generic array types are problematic

Relies on weld/core#1838

smoyer64 · 2018-06-07T13:36:15Z

I've updated a previous POC we created here at Penn State to use the new ExceptionHandler mechanism. The application output below shows that the DefaultExceptionHandler was used (since there are no additional ExceptionHandlers found by the ServiceLoader. Notice that this default execution is available at commit PennState/weld-se-config-shade-poc@d69e5f9.

08:36:36.729 [] [main] ERROR org.jboss.weld.environment.se.DefaultExceptionHandler - Weld-SE application exited with an exception org.jboss.weld.exceptions.DeploymentException: Error while validating Configuration
No Config Value exists for another.string
No Config Value exists for a.third.string
No Config Value exists for some.string
        at org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:38)
        at org.jboss.weld.bootstrap.events.AfterDeploymentValidationImpl.fire(AfterDeploymentValidationImpl.java:28)
        at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:499)
        at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:93)
        at org.jboss.weld.environment.se.Weld.initialize(Weld.java:800)
        at org.jboss.weld.environment.se.StartMain.go(StartMain.java:52)
        at org.jboss.weld.environment.se.StartMain.main(StartMain.java:62)
Caused by: javax.enterprise.inject.spi.DeploymentException: Error while validating Configuration
No Config Value exists for another.string
No Config Value exists for a.third.string
No Config Value exists for some.string
        at org.wildfly.microprofile.config.inject.ConfigExtension.validate(ConfigExtension.java:122)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:95)
        at org.jboss.weld.injection.MethodInvocationStrategy$SpecialParamPlusBeanManagerStrategy.invoke(MethodInvocationStrategy.java:144)
        at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:330)
        at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:123)
        at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:308)
        at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:286)
        at javax.enterprise.inject.spi.ObserverMethod.notify(ObserverMethod.java:124)
        at org.jboss.weld.util.Observers.notify(Observers.java:170)
        at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:285)
        at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:273)
        at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:177)
        at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:171)
        at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:53)
        at org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:35)
        ... 6 common frames omitted

swm16@swm16-xps-15:~/git/psu/weld-se-config-shade-poc$ echo $?
1

After this commit, we've added a custom (and admittedly simplified) ExceptionHandler that only outputs the DeploymentException's message and changes the application's exit code to 2. The output of this program is now:

09:30:02.399 [] [main] ERROR edu.psu.swe.poc.DeploymentExceptionHandler - Error while validating Configuration
No Config Value exists for another.string
No Config Value exists for a.third.string
No Config Value exists for some.string
swm16@swm16-xps-15:~/git/psu/weld-se-config-shade-poc$ echo $?
2

manovotn · 2018-06-07T14:01:33Z

retest this please

manovotn · 2018-06-14T07:58:30Z

Alright, I finally got down to this, so here are some thoughts...

Thanks for PoC, it makes things a lot clearer. I can see the point of this effort and I think it's a good idea to be able to handle exception in a custom way.

One thing I find a bit weird is that this approach will only work if you are using the built-in main method.
If you were to write your own main (which I think is pretty common), then this has no effect. As a matter of fact, you can even now write your own main with just this code and it will work.

So the question is, whether it's good "default" behaviour. Since it doesn't change the way it behaved up until now, I'd say it's fine.

P.S. I know streams are cool and all, but what's wrong with List? :)

mkouba · 2018-06-14T07:56:49Z

environments/se/core/src/main/java/org/jboss/weld/environment/se/ExceptionHandler.java

+
+    Stream<Class<? extends Throwable>> getExceptionTypes();
+
+    void handle(Throwable t);


I would simplify the API so that ExceptionHandler only declares boolean handle(Throwable t) which returns true if the handler is able to handle the given exception.

I would lean towards two methods, supports() and handle(), much like it's designed in Junit for instance.

The JUnit 5 ParameterResolver was actually my inspiration for this interface ... I've simplified it a bit now but the user will be responsible for all the supports() logic now. Any chance that weld-core can be setup to also run JUnit 5 tests?

Any chance that weld-core can be setup to also run JUnit 5 tests?

That shouldn't be problem, it can be run in parallel with JUnit 4, though I am not sure what is the actual benefit?
Plus any more complex testing that pure unit testing has to stick with JUnit 4 because Arquillian doesn't support it ATM (at least last time I checked it didn't).

mkouba · 2018-06-14T07:58:12Z

environments/se/core/src/main/java/org/jboss/weld/environment/se/DefaultExceptionHandler.java

+
+    @Override
+    public Stream<Class<? extends Throwable>> getExceptionTypes() {
+        return null;


I think this would result in NPE (see also the default supports() implementation).

The DefaultExceptionHandler has to be at the end of the list and isn't registered via the ServiceLoader. See the orElse clause in StartMain.

mkouba · 2018-06-14T07:58:26Z

environments/se/core/src/main/java/org/jboss/weld/environment/se/DefaultExceptionHandler.java

@@ -0,0 +1,21 @@
+package org.jboss.weld.environment.se;


Missing license header...

Also in the ExceptionHandler interface.

mkouba · 2018-06-14T07:58:49Z

environments/se/core/src/main/java/org/jboss/weld/environment/se/StartMain.java

+            new StartMain(args).go();
+            System.exit(0);
+        } catch (Throwable t) {
+            StreamSupport.stream(exceptionHandlerLoader.spliterator(), false)


I think there is no need to use streams here...

I like the use of the Stream here but agree that it's a bit out of place in the ExceptionHandler interface. (in this case, the findFirst() and orElse() methods eliminate a lot of if/elseif logic)

smoyer64 · 2018-06-14T12:58:47Z

So the question is, whether it's good "default" behaviour. Since it doesn't change the way it behaved up until now, I'd say it's fine.

It doesn't change the default behavior but it does represent code that has to be maintained in the future. My opinion is that it's probably not the type of code that will cause maintenance issues as it's functionality is pretty clear. In any case, I'll leave that decision up to you.

One thing I find a bit weird is that this approach will only work if you are using the built-in main method.

Should the ExceptionHandlers be executed as part of the CDI life-cycle instead? This would only change the behavior of existing applications if they registered a handler.

P.S. I know streams are cool and all, but what's wrong with List? :)

I was looking over this code with a colleague and we both realized that the signature in ExceptionHandler should probably contain a Set. Using stream processing in the StartMain catch block made the code's behavior much clearer and I simply returned a Stream to make that easier. Since only the first "supporting" handler is executed, a list might help as the developer can then specify the order of the handlers. An alternative would be to execute all supporting handlers, though it's my opinion that would increase the application's complexity. What do you both think?

I have in fact "wrapped" the StartMain class to perform the functionality included in #2502 - the ability to include one ore more ExceptionHandlers as defined in this WIP allows us essentially put a help message into the logs output when there's a configuration or infrastructure problem.

manovotn · 2018-06-14T13:18:13Z

Should the ExceptionHandlers be executed as part of the CDI life-cycle instead?

Can't see how this would work. All I was saying is that I 'think' (I cannot know for sure) that a lot of people using Weld SE also define their own Main. Hence they won't even be aware of this change and anyone willing to adopt it will basically have to go to our code and copy-paste the code executing handlers which is a pity but I have no other solution for the time being.

An alternative would be to execute all supporting handlers, though it's my opinion that would increase the application's complexity.

Yea it would, but it's complexity that user themselves can introduce if they wish to. Not really our concern. What we could do is to allow using @Priority on the implementations and then sorting the list based on that to impose some ordering. Or does that sounds too crazy?

I'd either allow for one handler only, or enable some way to order your handlers. WDYT @mkouba ?

smoyer64 · 2018-07-16T17:05:13Z

I just removed the System.exit(0) as in WELD-2502 so I wouldn't forget

smoyer64 · 2018-09-04T11:56:41Z

@mkouba Is there something I need to do to move this off "hold"?

manovotn · 2018-09-05T10:29:42Z

Hey Steve, thanks for the nudge, this has gone somewhat stall.

So, I talked this through with Martin and here is what we agreed on:

Rename ExceptionHandler to ~~WeldMainExceptionHandler~~ StartMainExceptionHandler
- To make the name less vague and indicating that it goes together with our main
WeldMainExceptionHandler will implement javax.enterprise.inject.spi.Prioritized and java.lang.Comparable
- there will be a default implementation of compareTo() right on the interface, leveraging getPriority() method
- I would not add default impl of getPriority()
Allow to execute all exception handlers based on priority (not just one/first)
- Get List of all handlers, sort them
- Handlers with the lowest priority go first (this has to be documented)
- if no handlers are found, use the default one
Correct License headers (some files are missing it, some are outdated)
Last but not least, add tests :)

Let me know if it sounds reasonable and if you are fine making these changes.

smoyer64 · 2018-09-05T10:58:26Z

That all sounds reasonable ... I'm really busy at work this month but I can dig into this work in a few weeks. Would StartMainExceptionHandler be a better name than WeldMainExceptionHandler given it's only going to work if you launch via StartMain?

I've been pushing the https://github.com/eclipse/ConfigJsr and https://github.com/smallrye/smallrye-config projects to clean up how their validation errors are reported so I might yet be able to catch DeploymentExceptions in Java SE CDI projects and display an alternate (configuration oriented) help screen.

Thanks!

mkouba · 2018-09-05T11:00:28Z

Would StartMainExceptionHandler be a better name...

+1, this would be my choice as well ;-)

manovotn · 2018-09-05T11:03:40Z

Would StartMainExceptionHandler be a better name...

Ok, I have been outvoted, StartMainExceptionHandler it is! :)

manovotn · 2018-10-03T08:10:35Z

@smoyer64 Just to let you know, next release is 3.1.0 meaning this PR should get in.
Now is the time to move in forward ;-)

manovotn · 2018-11-26T12:35:43Z

@smoyer64 a casual friendly inconspicuous poke

smoyer64 · 2018-11-26T12:37:39Z

ouch! I still plan to get back to this soon but things at work have been quite busy.

…

On Mon, Nov 26, 2018 at 7:35 AM Matej Novotny ***@***.***> wrote: @smoyer64 <https://github.com/smoyer64> a casual friendly inconspicuous poke — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1838 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAUCjeYDop9KL5GMMHxE0EZ3PEuqNKT-ks5uy-AggaJpZM4UdRj6> .

-- Sent from my iBerry MacPhone

manovotn · 2019-01-22T08:54:26Z

Weld release is scheduled very early in Feb, this issue should either get a solid PR by the end of Jan, or we will have to postpone it.

smoyer64 · 2019-01-22T13:02:29Z

Okay ... I've got perhaps a day I can spare and I don't think it's too onerous. I think I'm good to go based on the previous discussion but I'm wondering how much documentation should be included. I'm assuming that needs to go in the users guide?

manovotn · 2019-01-22T13:21:10Z

The SE part of Weld docs might be the place I think - http://docs.jboss.org/weld/reference/latest/en-US/html_single/#weld-se
In code, that translated into [this asciidoc|https://github.com/weld/core/blob/master/docs/reference/src/main/asciidoc/environments.asciidoc].

manovotn · 2020-08-25T18:37:34Z

Closing because the PR has been stale for far too long.

Steve Moyer added 2 commits June 6, 2018 08:44

WELD-2502 Make Weld-SE StartMain compatible with container execution

b42d0b6

Allows pluggable exception handlers when using StartMain

0c8be59

Cleaned up formatting (to hopefully satisfy CheckStyle)

0a776f3

weld deleted a comment from WeldJenkins Jun 7, 2018

Changes getExceptionTypes() return type

e8d1599

Generic array types are problematic

smoyer64 pushed a commit to PennState/weld-se-config-shade-poc that referenced this pull request Jun 7, 2018

Adds a custom ExceptionHandler for DeploymentExceptions

07fe3ab

Relies on weld/core#1838

mkouba requested changes Jun 14, 2018

View reviewed changes

Steve Moyer added 2 commits June 14, 2018 09:09

Merge branch 'master' of github.com:weld/core

7493f47

Changes from JBoss Logger to the WeldSELogger

94ed520

Steve Moyer added 2 commits July 6, 2018 12:35

Merges upstream changes

b76641c

Simplifies the ExceptionHandler interface

1c93239

smoyer64 pushed a commit to PennState/weld-se-config-shade-poc that referenced this pull request Jul 6, 2018

Updates based on WIP at weld/core#1838

fd3bc25

mkouba added the hold label Jul 10, 2018

Removes System.exit(0) when execution completes successfully

fbecf1a

smoyer64 mentioned this pull request Aug 30, 2018

[#27] Encapsulates each deployment problem in a ConfigException smallrye/smallrye-config#28

Merged

Steve Moyer added 3 commits November 26, 2018 12:22

Keeps new handler calls to resolve merge conflict

0325b72

Fixes merge conflict with removal of System.exit(0)

0a90b41

Merges conflict in StartMain (again)

6bf6340

smoyer64 mentioned this pull request Dec 7, 2018

Configuration value location smallrye/smallrye-config#59

Closed

manovotn closed this Aug 25, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WIP: WELD-2503 Create Exception handler for applications run using StartMain #1838

WIP: WELD-2503 Create Exception handler for applications run using StartMain #1838

smoyer64 commented Jun 6, 2018 •

edited

WeldJenkins commented Jun 6, 2018

manovotn commented Jun 7, 2018

smoyer64 commented Jun 7, 2018

manovotn commented Jun 7, 2018

manovotn commented Jun 14, 2018

mkouba Jun 14, 2018

manovotn Jun 14, 2018

smoyer64 Jul 6, 2018 •

edited

manovotn Jul 7, 2018

mkouba Jun 14, 2018

smoyer64 Jul 6, 2018

mkouba Jun 14, 2018

smoyer64 Jul 6, 2018

mkouba Jun 14, 2018

smoyer64 Jul 6, 2018 •

edited

smoyer64 commented Jun 14, 2018

manovotn commented Jun 14, 2018

smoyer64 commented Jul 16, 2018

smoyer64 commented Sep 4, 2018

manovotn commented Sep 5, 2018 •

edited

smoyer64 commented Sep 5, 2018

mkouba commented Sep 5, 2018

manovotn commented Sep 5, 2018

manovotn commented Oct 3, 2018

manovotn commented Nov 26, 2018

smoyer64 commented Nov 26, 2018 via email

manovotn commented Jan 22, 2019

smoyer64 commented Jan 22, 2019

manovotn commented Jan 22, 2019

manovotn commented Aug 25, 2020


		Stream<Class<? extends Throwable>> getExceptionTypes();

		void handle(Throwable t);

WIP: WELD-2503 Create Exception handler for applications run using StartMain #1838

WIP: WELD-2503 Create Exception handler for applications run using StartMain #1838

Conversation

smoyer64 commented Jun 6, 2018 • edited

Theory

Outstanding tasks

WeldJenkins commented Jun 6, 2018

manovotn commented Jun 7, 2018

smoyer64 commented Jun 7, 2018

manovotn commented Jun 7, 2018

manovotn commented Jun 14, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

smoyer64 Jul 6, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

smoyer64 Jul 6, 2018 • edited

Choose a reason for hiding this comment

smoyer64 commented Jun 14, 2018

manovotn commented Jun 14, 2018

smoyer64 commented Jul 16, 2018

smoyer64 commented Sep 4, 2018

manovotn commented Sep 5, 2018 • edited

smoyer64 commented Sep 5, 2018

mkouba commented Sep 5, 2018

manovotn commented Sep 5, 2018

manovotn commented Oct 3, 2018

manovotn commented Nov 26, 2018

smoyer64 commented Nov 26, 2018 via email

manovotn commented Jan 22, 2019

smoyer64 commented Jan 22, 2019

manovotn commented Jan 22, 2019

manovotn commented Aug 25, 2020

smoyer64 commented Jun 6, 2018 •

edited

smoyer64 Jul 6, 2018 •

edited

smoyer64 Jul 6, 2018 •

edited

manovotn commented Sep 5, 2018 •

edited