If I run unit tests for Quarkus from inside Eclipse, the Eclipse console view shows Quarkurs' log output. However, when I run the same tests in Maven, the Quarkus output is completely swallowed and does not appear anywhere. If there is a test failure due to an exception in the application code I get the test failure message but I cannot see what actually went wrong inside the application. The Java log manager is configured to use JBoss logging by using the surefire system property.
Does anyone know where one can find the Quarkus log output or how it can be enabled?
You haven't posted any code or configuration files, so there is no way to know what may be causing your problem.
Potentially you may want to check out a few things:
In the application configuration file, make sure quarkus.log.console.enable is set to true (if you can't find it don't worry about it, since by default it's true)
Is quarkus.log.file.enable set to true? (by default it's false)
While I can't tell you what the problem is exactly, since there is no code to review, I will put links to the official Quarkus logging guide. What may interest you is under Runtime configuration and Logging configuration reference.
Related
I am working on project that is not having debug options in eclipse.
I would like to understand the flow of execution from within Java classes across workspace.
Is there a method to understand the flow of execution. I am working on struts application and I have configured all dependant java files accordingly. But while running the application, new field added is not persisting to database and remains blank.
Any help is much appreciated.
lazy way of debugging is by adding a print statement for every line you want to follow.
The right way would be using debug logs with Log4j
I unfortunately may have two questions in one, or rather the solution may go two different ways. I have log4j loggers set up in a few classes that I unit test on. When I run mvn clean install it obviously runs those tests and in turn creates a log file (that is usually empty as nothing exciting is being logged). This isn't necessarily a problem except that Jenkins doesn't seem to like this when I do Perform Maven Release. It yells about the workspace having local changes and it cites the log file before declaring failure.
I know its the unit tests because if I changed them to integration tests or ignore them, everything works fine. But I'd like a solution not a workaround.
Are there configurations in Jenkins that can allow me to remedy this?
Or is there a strategy for mocking or ignoring logging for Unit tests?
I don't necessarily want to ignore them, but it is interfering with creating a release.
I am not quite aware of what Perform Maven Release does, but I can suggest a couple of solutions:
Remove the log file from your source code repository (as the log files gets regenerated on every run, I don't think it should reside in your source code repository).
Add the path of the offending log file to a list of files that are ignored by version control (e.g. git uses a file called gitignore - https://git-scm.com/docs/gitignore)
Hope this helps!
Amit has some good ideas, and I'll suggest a few more:
Use slf4j for logging in your project, and don't bind a logging implementation during the test phase
going one better, bind slf4j-test during the test phase, which logs to memory. Then you can also write tests against your logging to ensure it happens when you expect it to.
I'm thinking of developing a maven plugin which will cause your maven build to output info messages and above if the build fails.
The context is that I'd like to configure maven to work with warn by default and disable all logs of my company (this will be done by logback configuration) and I'd like to have a plugin which talks to another in-memory logback appender to get the entire log to throw to the user in case the build fails since at that point all the data is relevant.
My question is if and how I can get that "notification" that the build failed?
For those interested my intention, which I still need to validate, is then to programmatically change the consoleAppender back to info and write everything that was accumulated to it.
I was asked about my motivations and so there are two.
The first is that I think (still crunching data to see if I'm right) that our build logs are so verbose it's effecting our build times.
The second is that some of our tests cause exceptions to be thrown as part of them which confuse the logs. I'd still like the entire log in case the build fails so that developers have all the info they need to debug their failure
First i don't understand your intention why not using a continious integration solution which records the whole output and can be stored for a period of time. If you need to analyze you can take a look into it. Apart from that i don't understand your need to do something what you described and what the advantage would be...
Furthermore a maven plugin will simply not work for your intention cause a maven plugin is bound to the life cycle.
If you really need something outside the mave life cycle you could take a look into the EventSpy which could be used in the way you described, but its an extension which must be put into lib/ext folder of your maven installation. Best is to use the AbstractEventSpy as parent for your own implementation.
Currently we have J2EE applications that run on WebSphere and log4j 1.x is our company's standard for Java logging. We'd like to investigate the ability to change the log4j configuration xml file at runtime so we can change to the DEBUG level, for example, when problems are identified, and return to the ERROR level once those problems are cleared up and DEBUG is no longer needed. We'd like to do all this without having to recycle the application to reread the config file.
I see that DOMConfigurator.configureandWatch() is an available method that would allow the config file to be reread at runtime. However, because it spawns a separate thread that won't be shut down when the application is shut down, it is unsafe to run in a J2EE environment.
http://logging.apache.org/log4j/1.2/faq.html#a3.6
Does anyone know if this was fixed in log4 2? I haven't found anything definitive yet from the documentation and was curious if it is safe to change the config file at runtime in J2EE.
Re-reading the configuration file is not something you want to do in production. It means that you're changing resources which many app servers don't expect to change. Development environments can get away with it on the grounds that blowing up the app server isn't a big deal. It also means that your app might behave differently if it has to be restarted.
You're going to want to change the log levels programmatically. You can do this by using LogManager.getLogger() for the packages you care about. Once you have the logger, change the level to debug, and change it back when you are done.
I'm trying to run a windows service with cobertura. The only problem is cobertura reports results when the shutdown hook is executed. I am unable to directly modify the code for these results, so I was wondering if it is possible to run a java application as a windows service and still gather cobertura results. I instrument the code, add it to the classpath, but when reporting, I get nothing. When viewing a trace file, it fails to load/save any cobertura information. This leads me to believe that shutdown hooks never get executed, otherwise I would get results.
Thanks for the assistance!
You might want to look at Emma instead, it allows you to instrument in advance.
http://emma.sourceforge.net/
When using Cobertura, do you get a .ser file at all?
I assume that you can't tweak the code to force an export, as shown at the bottom of this FAQ?
http://cobertura.sourceforge.net/faq.html