Embedded Jetty 9 Logging with Logback - jetty

I use jetty in a maven project and logging is already in place using slf4j and logback.
Hence, I have a logback.xml where I configure logging and it works so far (format, setting levels for my project and libraries, ...).
However, now that I added jetty in the pom.xml as a dependency, I get tons of new DEBUG logs which I do not want to see (usually).
How can I set the log level for jetty to a higher level?
At the beginning, jetty reports that it recognized slf4j:
13:08:57 [main] [DEBUG] log - Logging to Logger[org.eclipse.jetty.util.log] via org.eclipse.jetty.util.log.Slf4jLog
In my logback.xml, I tried to mute jetty as follows, but it does not work:
<logger name="org.eclipse.jetty" level="INFO" />
This does the trick for other libraries that I use.
I read the jetty documentation regarding logging, but they only document the use of standalone jetty - unfortunately, I was not able to adapt it for the embedded use case.

I found the answer myself - it is slightly embarrassing.
The issue is that there are two configuration files for logging: logback.xml and logback-test.xml.
I did not adjust the level of the logger in logback-test.xml which is used during development in a maven project.
The logback.xml configuration, on the other hand, is used when a package is built, e.g. in production use.
From the logback documentation:
If you are using Maven and if you place the logback-test.xml under the
src/test/resources folder, Maven will ensure that it won't be included
in the artifact produced. Thus, you can use a different configuration
file, namely logback-test.xml during testing, and another file,
namely, logback.xml, in production.
Due to lack of experiences with logback and maven, I did not know this.
To conclude:
Adding the following to the logback-test.xml solves my issue:
<logger name="org.eclipse.jetty" level="INFO" />

Related

Disable Liquibase execution at startup using Jetty + Spring (not Spring boot!)

I'm working in an application developed with Spring5 (not Spring boot!) that runs on Jetty. This application has module that uses the plugin liquibase-maven-plugin.
We generate a image from a dockerfile (base image jetty:9-jre8), where we add the application (war file) in the jetty application directory.
In some specific environments, where I deploy the application, I want to be able to disable that execution.
Is it possible to do so?
I've seen on spring boot documentation, that it's possible to do so by defining the property spring.liquibase.enabled (or liquibase.enabled on Spring4) to false, but that seems that doesn't work:
I've tried to define them at the properties file, define them as env properties and also as java options (-Dspring.liquibase.enabled=false).
This has the same behavior when I deploy the container, or when I execute locally the maven command: mvn jetty:run
Do you have any ideas or hints how to do this?
Thank you in advance
Well I just discovered that it's possible to disable the execution of liquibase by adding the JAVA_OPTION
-Dliquibase.shouldRun=false
For more details see here
I will keep this quesion anyway, in case someone has the same problem I did.

Is it possible to configure spdlog from a file like log4j or log4cxx?

I have experience of log4j, and have used a port of it called log4net in c#. In both cases I find it very useful to configure loggers at run time, by means of logger config files. For example you can increase the log level of a particular subsystem without a recompile.
I am searching for a logging framework for c++. Currently checking log4cxx and spdlog.
I see that log4cxx can read its configuration from an xml file.
Does this ability to configure at run time exist for spdlog?
There is https://github.com/guangie88/spdlog_setup to configure spdlog using TOML

Where can I find request and response logs for Spark?

I have just started using Spark framework. And experimenting with a local server on Mac OS
The documentation says that to enable debug logs I simply need to add a dependency.
I've added a dependency and can observe logs in the console.
The question is where the log files are located?
If you are following the Spark example here, you are only enabling slf4j-simple logging. By default, this only logs items to the console. You can change this programmatically (Class information here) or by adding a properties file to the classpath, as seen in this discussion. Beyond this you will likely want to implement a logging framework like log4j or logback, as slf4j is designed to act as a facade over an existing logging implementation.

OSGi support of org.eclipse.jetty.aggregate

Since version 9.x Jetty seems not to have an aggregate artifact that provides the Jetty server within OSGi environments. It would be very helpful if the project could provide an OSGi compliant aggregate artifact for 9.x and further. In 8.x we had the org.eclipse.jetty.aggregate:jetty-all-server artifact. Why does it not exist for 9.x?
Can anybody help me or has some explanations?
The aggregates that exist for Jetty are not meant to be used by projects directly. They were created specifically for the documentation, and specifically for command line use to demonstrate some of the features of Embedded Jetty use.
It is not recommended to use aggregates for your project.
In fact, jetty-all (a name kept for historical reasons), isn't even "all of jetty" anymore. This concept isn't even possible anymore, as there are many component options for Jetty that cannot exist in the same jar at the same time.
Would highly recommend using the individual artifacts properly, and with a build tool that supports the global central repository, such as maven, ant+ivy, buildr, groovy grape, gradle+grails, scala sbt, or even leiningen.
Once you have a good build setup, you can then pick and choose and setup your own uber jars for jetty that fit your specific needs. Keep in mind that for OSGi, this would mean having to rewrite the manifest for this uberjar to include all of the OSGi references properly. Also note, that if you do this, you will likely not play well in the rest of OSGi world that is using Jetty properly. That is a decision you should make. Do I play in my own world of OSGi and never use OSGi bundles from other open source projects, or do I want to use other popular OSGi bundles in the future.

How to test Entity classes from another Eclipse project in a Stateless Session Bean within a JUnit Test

So here's what I'm trying to do and stuck at:
I have a shared Eclipse Java project with #Entity (EJB 3.1) classes that is used by a couple of other Eclipse WebApp projects. This project itself has no persistence.xml! The other WebApp projects that use this project declare their own persistence.xml under WebContent/META-INF and refer to the JAR of this project in their persistence.xml using the jar-file tag. Of course the shared project's JAR is added as a deployment dependency in these WebApp projects and is placed under WEB-INF/lib.
Now I am creating JUnit4 Testcases to test Stateless session beans in these WebApp projects. I'm using Apache TomEE 1.5.0 Plus and in the testcase I use a #Before method to start the OpenEJB container in Embedded mode using EJBContainer.createEJBContainer() method. For this to work properly, I have created an alternate test.persistence.xml (that uses a different datasource to an HSQL memory db and creates the tables using forward mapping). I have placed this in META-INF of the src folder and in the #Before method, I set the "openejb.altdd.prefix" to "test" so that the alternate test.persistence.xml is read. All this setup is working.
The trouble is that as soon as OpenJPA 2.2.0 starts, it complains that there are no persistent classes from the shared project! This is because, the jar-file tag in test.persistence.xml refers to a jar that doesn't exist! When Eclipse deploys the other WebApp projects, it creates the JAR under WEB-INF/lib and the actual persistence.xml refers to the jar under that path! However, I do not find any such JAR when running a JUnit testcase.
So how do I refer to this JAR or the classes in the shared project in the test.persistence.xml without making the testcase itself overly dependent on deployment structure or any specific hard-coded path! This testcase will eventually be committed to the repository and hence must be such that any dev checking it out can simply run it.
Any pointers in the right direction would be greatly appreciated!
IMO the easiest and better way to do that is to use Arquillian.
It's far more easier to control the packaging, the life cycle of the container, etc
TomEE also provides a great integration (adapter) with Arquillian you can use.
Check the documentation page http://tomee.apache.org/documentation.html
There is an arquillian section.
You can also check TomEE examples page where you can find a huge amount of small samples including arquillian.
Hope it helps
Jean-Louis