I'm having a trouble deploying a Spring boot application in webLogic 12C.
10.4.4 403 Forbidden
The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
I was wondering if someone can help with that.
I reviewed your code and saw an issue in this class of your code:
https://github.com/purrox/Spring-example/blob/master/src/main/java/hello/Application.java
You're doing it correctly (as defined in the SpringBoot docs) but it seems there's a bug with Weblogic12C (or maybe an interpretation of the standard). It seems like Weblogic12C Searches for a class that implements WebApplicationInitializer DIRECTLY. Notice how your code extends SpringBootServletInitializer (which implements WebApplicationInitializer). Weblogic12C doesn't like it that way it seems. So, the simplest way is to make your Application class implement WebApplicationInitializer. So, change this line:
public class Application extends SpringBootServletInitializer {
to this:
public class Application extends SpringBootServletInitializer implements WebApplicationInitializer {
Note: once you fix the above, you'll run into another Weblogic12C deploy issue: "java.lang.IllegalArgumentException: LoggerFactory is not a Logback LoggerContext but Logback is on the classpath". To fix that other issue, create a new file src/main/webapp/WEB-INF/weblogic.xml and put this content in it:
<?xml version="1.0" encoding="UTF-8"?>
<wls:weblogic-web-app xmlns:wls="http://xmlns.oracle.com/weblogic/weblogic-web-app" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.4/weblogic-web-app.xsd">
<wls:weblogic-version>12.1.1</wls:weblogic-version>
<wls:context-root>helloApp</wls:context-root>
<wls:container-descriptor>
<wls:prefer-application-packages>
<wls:package-name>org.slf4j.*</wls:package-name>
</wls:prefer-application-packages>
</wls:container-descriptor>
</wls:weblogic-web-app>
If you are going to use multipart
file request, you may still find issues in deploying the war.
The root of the problem is that OrderedCharacterEncodingFilter is running after HiddenHttpMethodFilter. HiddenHttpMethodFilter
triggers processing of the request body as it calls getParameter
on the request. OrderedCharacterEncodingFilter
then runs and sets the request's encoding. Setting the request's encoding after its body has been processed is bad and, on WebLogic, causes the request to lose track of all its multipart data.
A workaround is to disable the character encoding filter in application.properties:
spring.http.encoding.enabled: false
You need to add "implements WebApplicationInitializer" to your hello.Application.
This is redundant as it extends SpringBootServletInitializer, which itself implements WebApplicationInitializer, however, as @Pierre points out, weblogic requires a class to directly implement it.
I hit this issue last time. After applying all proposals from this post I was still getting error 403. In my case the problem was in the web.xml
file. I was using version 2.5 instead of 3.0 without configuring it to load an ApplicationContext
via a DispatcherServlet
.
From the post: What exactly is the web-app version? What does it affect?.
Versioning refers to XML schema version that syntax of your web.xml file must obey. More important, it also indicates the version of Servlet specification that your application implements.
And from Spring documentation http://docs.spring.io/spring-boot/docs/current/reference/html/howto-traditional-deployment.html:
Older Servlet containers don’t have support for the ServletContextInitializer bootstrap process used in Servlet 3.0. You can still use Spring and Spring Boot in these containers but you are going to need to add a web.xml to your application and configure it to load an ApplicationContext via a DispatcherServlet.
Finally I've changed the version of web.xml
file to 3.0 and it starts working.