Changing log4j version gives error in Session class. WHy?

[Yogesh Gandhi]

Hi,

I am trying to upgrade my log 4j version from 1.x to 2.x

Earlier log4j entry in pom.xml
<dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.2.15</version> </dependency>

Now I am trying to upgrade it to 2.x

<!-- https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core --> <dependency>    <groupId>org.apache.logging.log4j</groupId>    <artifactId>log4j-core</artifactId>    <version>2.17.1</version> </dependency> <!-- https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-api --> <dependency>    <groupId>org.apache.logging.log4j</groupId>    <artifactId>log4j-api</artifactId>    <version>2.17.1</version> </dependency>

But the problem is, I get compilation problems in Some other class (i.e javax.mail or something like that)

But why is that compiler is not able to find these classes after I find log4j version.

Can someone explain me please?

Even i tried to add bridge log4j jars, so that if there is a possibility that these jars are inturn using 1.x log4j, then they may be satisifed, but even that doesnt help.

[Campbell Ritchie]

What did the compiler error messages say? Please copy'n'paste the errors rather than posting screenshots.

[Yogesh Gandhi]

Campbell Ritchie wrote:What did the compiler error messages say? Please copy'n'paste the errors rather than posting screenshots.

Session cannot be resolved to a type
InternetAddress cannot be resolved

etc etc

[Campbell Ritchie]

How did you import those types? How did you add the log4j types to the application? Did you use the CLASSPATH?

[Yogesh Gandhi]

Campbell Ritchie wrote:How did you import those types? How did you add the log4j types to the application? Did you use the CLASSPATH?

It was a working maven project. I was able to compile it completely earlier.

When I change the log4j dependencies from 1.x to 2.x, why the heck these classes start giving compilation error.
I am surpised because there are in no way related to the log4j in any way or is it?

[Tim Holloway]

It appears that the compile/edit classpath of your IDE project is damaged. Possibly there is a syntax error somewhere in your POM from when you edited it. If not, you may have to re-sync Maven and your IDE (Eclipse can be bad about that).

It's quite likely that if you ran Maven from the command line, the app would compile and build OK if the POM is OK.

No, changing the version of Log4J should definitely not cause errors like you showed us.

By the way, I believe that Log4J has stabilised at 2.17.2 now.

[Rob Spoor]

Those classes are from JavaMail. Apparently its API module is a dependency of Log4J 1.x (see https://mvnrepository.com/artifact/log4j/log4j/1.2.15). You'll need to include it manually.
I was surprised by this, but I think it was a mistake. The previous version (https://mvnrepository.com/artifact/log4j/log4j/1.2.14) didn't have any dependencies, the next version (https://mvnrepository.com/artifact/log4j/log4j/1.2.16) made it an optional dependency. I'm guessing that version 1.2.15 added a new appender that needed JavaMail, but the developers forgot to make JavaMail optional.

[Rob Spoor]

By the way, depending on your type of application, you should include the JavaMail dependency with scope provided. In any JEE compliant container like JBoss, WebLogic, GlassFish, etc., JavaMail is part of the container's core library set. You don't need to include it in your application, in the same way you don't need to include the Servlet API or Bean Validation API. If you're deploying on Tomcat you probably need it as a compile time dependency (no scope necessary), if you have a standalone application you definitely need it as a compile time dependency.

[Tim Holloway]

Let me see if I can sort things out a bit.

I was under the impression that your screenshot was part of the application source code. If that is true, then you might have a version conflict with what log4j17.2 wants and need to upgrade your application source. If not, then the following should apply:

As Rob said, full-stack JEE servers should already have JavaMail as an integral library to the server and the Maven scope would be "provided". If you had an explicit (non-transitive) POM dependency, make sure that it looks for a compatible version.

Lightweight JEE servers such as Tomcat and Jetty do not include JavaMail as a built-in service, so the Maven scope there should be "compile" (which is the default). Compile scope means that not only will the implementation library you're depending on be referenced for compiling (just like "provided" scope), but that additionally, a copy of that JAR will be included in the generated WAR's /WEB-INF/lib directory.