RE: A different abstract class with the same name was previously loaded by com.

ahmed joti, modified 4 Months ago.

A different abstract class with the same name was previously loaded by com.

New Member Posts: 6 Join Date: 8/15/20 Recent Posts

hello Everyone,

im using 7.4.3.132 and java 21, but when I try to access a page, I get this error indicating a classloader conflict:

 

{"timestamp": "2025-04-16 17:34:10.738", "thread":"http-nio-8080-exec-5", "level":"ERROR", "loggerName":"PortletRequestDispatcherImpl", "message":"Unable to dispatch request: java.lang.LinkageError: loader constraint violation: loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @3c7a6cc2 wants to load abstract class javax.servlet.jsp.PageContext. A different abstract class with the same name was previously loaded by com.liferay.shielded.container.internal.ShieldedContainerClassLoader @680bddf5. (javax.servlet.jsp.PageContext is in unnamed module of loader com.liferay.shielded.container.internal.ShieldedContainerClassLoader @680bddf5, parent loader 'bootstrap')", "endOfBatch":false, "loggerFqcn":"com.liferay.portlet.internal.PortletRequestDispatcherImpl", "contextMap":{}, "threadId":"98", "threadPriority":"ERRORrio"}

In my pom.xml I have this:

<dependencies>
<dependency>
<groupId>com.liferay.portal</groupId>
<artifactId>release.portal.api</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.apache.shiro</groupId>
<artifactId>shiro-web</artifactId>
<version>${shiro.version}</version>
<exclusions>
<exclusion>
<groupId>org.bouncycastle</groupId>
<artifactId>*</artifactId>
</exclusion>
<exclusion>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
</exclusion>
<exclusion>
<groupId>javax.servlet.jsp</groupId>
<artifactId>jsp-api</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.hazelcast</groupId>
<artifactId>hazelcast</artifactId>
<version>5.5.0</version>
</dependency> <dependency>
<groupId>org.apache.shiro</groupId>
<artifactId>shiro-core</artifactId>
<version>${shiro.version}</version>
<exclusions>
<exclusion>
<groupId>org.bouncycastle</groupId>
<artifactId>*</artifactId>
</exclusion>
<exclusion>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
</exclusion>
<exclusion>
<groupId>javax.servlet.jsp</groupId>
<artifactId>jsp-api</artifactId>
</exclusion>
</exclusions>
</dependency> <dependency>
<groupId>com.liferay.portal</groupId>
<artifactId>com.liferay.util.slf4j</artifactId>
<scope>provided</scope>
</dependency> <dependency>
<groupId>antlr</groupId>
<artifactId>antlr</artifactId>
<scope>provided</scope>
<version>${antlr}</version>
</dependency> <dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-crypto</artifactId>
<scope>provided</scope>
<version>5.8.10</version>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
</exclusion>
</exclusions>
</dependency> <dependency>
<groupId>com.esotericsoftware</groupId>
<artifactId>kryo</artifactId>
<version>5.5.0</version>
<exclusions>
<exclusion>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
</exclusion>
<exclusion>
<groupId>javax.servlet.jsp</groupId>
<artifactId>jsp-api</artifactId>
</exclusion>
</exclusions>
</dependency> <dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<scope>provided</scope>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
</exclusion>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency> <dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<scope>provided</scope>
</dependency>
</dependencies>

 I think the issue comes from the Shiro dependencies — it persists even if I exclude the affected javax.servlet packages.
someone have a idea about this issue ?

thank you,

thumbnail
David H Nebinger, modified 2 Months ago.

RE: A different abstract class with the same name was previously loaded by com.

Liferay Legend Posts: 14933 Join Date: 9/2/06 Recent Posts

 Normally you'll get this if you have a compileInclude on a dependency that Liferay already has available. Changing to just compile or compileOnly may resolve it.

Community
Company
Feedback