I have been searching for a robust solution to identify the changes made in WebLogic third-party libraries (version 14) or JDK 8 and 11 that could resolve the reported issue. Despite my efforts, I have not yet found a definitive solution to completely eliminate the problem. However, I did discover a temporary workaround that partially satisfies the requirements for running the project on WebLogic 14. Naturally, this interim fix involves some modifications to the existing setup. As is widely known, Oracle WebLogic Server has used EclipseLink MOXy as the default JSON provider since version 12.1.1. However, starting with WebLogic Server 12.2.1.2, it is possible to switch to Jackson for JSON serialization and deserialization. This flexibility allows developers to choose the JSON provider that best suits their needs. In the legacy EJB application, each subsystem independently implements its own REST APIs. The REST API resources are configured through a class that extends the JAX-RS Application class. The Application class is responsible for registering JAX-RS resource classes (e.g., classes annotated with @Path) and providers (e.g., filters, interceptors, or custom message body readers/writers).

@ApplicationPath("/security") // Base URI for all resources
public class SecurityApplication extends Application {}

WebLogic Server does not include Jersey as its default RESTful web services framework. Instead, it relies on the Java API for RESTful Web Services (JAX-RS), which provides flexibility in choosing the preferred implementation. By default, WebLogic utilizes EclipseLink MOXy for JSON serialization and deserialization. EclipseLink MOXy is specifically designed for handling JSON serialization and deserialization. However, if your REST API in WebLogic processes XML, MOXy is not involved in such operations. For XML processing, WebLogic and JAX-RS implementations typically use JAXB (Java Architecture for XML Binding) by default. JAXB is a robust framework for converting Java objects to XML and vice versa. That said, it is possible to configure WebLogic Server to use Jersey instead. This can be achieved by packaging Jersey as a shared library and configuring your application to utilize it, as previously mentioned. By doing so, you can leverage Jersey's advanced features and capabilities within your WebLogic environment. The org.glassfish.jersey.server.ResourceConfig class is a key component of the Jersey framework, which is a widely used implementation of JAX-RS. This class is used to configure and customize the behavior of a JAX-RS application in a Java EE environment. ResourceConfig extends the standard javax.ws.rs.core.Application class, adding convenience methods and features specific to Jersey, thereby enhancing its functionality and ease of use. To address this issue, I implemented a class within the framework module of the legacy application that can be shared across all subsystems. This class is designed to serve as a reusable solution for anyone encountering the same problem. Instead of using the standard Application class, developers can now inherit from this newly created class to resolve the issue effectively.

public class JsonConfig extends ResourceConfig{
  public TosanRestApplication() {
    List<String> packageList=new ArrayList<>();
    packageList.add(this.getClass().getPackage().getName());
    property(CommonProperties.MOXY_JSON_FEATURE_DISABLE_SERVER, Boolean.TRUE);
    register(org.glassfish.jersey.jackson.JacksonFeature.class);
    packages(packageList.toArray(new String[packageList.size()]));
  }
}  

Therefore, any subsystem that encounters such a problem should inherit from JsonConfig instead.

@ApplicationPath("/security") 
public class SecurityApplication extends JsonConfig {}

In this case, I added the package name of the current class to the packageList. Next, I registered the Jackson feature to enable JSON processing. Finally, I configured the Jersey application to scan the specified packages for resources and providers. This approach proved to be an effective solution, successfully resolving the issue.