Note - the annotation processor will still be required in 3.0. Instead of generating a Log4jplugins.dat file it generates a Java class file. That class file is loaded via the ServliceLoader.
Also, Log4j 3 requires Java 11 and supports JPMS. With JPMS applications have to specify the annotation processor(s) to run as they are not automatically loaded from the module path. The annotation processor is also in its own jar in Log4j 3. Package scanning is just too slow to be acceptable at run time. Ralph > On Feb 24, 2023, at 1:22 PM, Matt Sicker <m...@musigma.org> wrote: > > We’re removing it in 3.0. In 3.0, plugins are instead loaded via > ServiceLoader from the JDK. The annotation processor was updated to generate > the service classes with the plugin metadata, though that can be created > manually if necessary. This is related to supporting Java modules which don’t > work very well with classpath scanning. > >> On Feb 24, 2023, at 2:00 PM, Kish, Robert [AG] >> <robert.k...@ag.nj.gov.INVALID> wrote: >> >> I see with version 2.20 that plugin package scanning is now marked for >> deprecation. This sounds great except for my use case of running a Tomcat >> web application inside of Eclipse. Eclipse compiles the code itself and >> launches Tomcat for ease of development. But this internal compiler has no >> clue about the Log4j2Plugins.dat file. I'm just at a loss for how to get >> this thing to work in this situation. We use maven to build our application >> but that doesn't really apply here as Eclipse's internal compiler is doing >> its own thing, and doesn't run all the plugins that one would place in the >> pom.xml. >> >> Does anyone have any suggestions on what to do about this when the package >> scanning is finally removed? >> CONFIDENTIALITY NOTICE: The information contained in this communication from >> New Jersey Department of Agriculture is privileged and confidential and is >> intended for the sole use of the persons or entities who are the addressees. >> If you are not an intended recipient of this email, the dissemination, >> distribution, copying or use of the information it contains is strictly >> prohibited. If you have received this communication in error, please >> immediately contact the sender of this email message to arrange for the >> return of this information. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
