Wildy 10.1.0 doesn't work for some jsp:include.

[sepgs2004]

Let us say the file (cycleList.jsp) is in this path:

C:\develop\wildfly-10.1.0.Final\standalone\deployments\myapp.ear\myWeb.war\jsp\pages\fields

EAR file deploy successfully

I am able to access many pages of the application good

In one JSP page, I have code like below.

<jsp:include page="/jsp/pages/fields/cycleList.jsp" flush="true" />

Application does not load this JSP. It silently fails (to load).

This was working in JBoss 7.1.1

On the browser, if I put http://localhost:8080/myapp/, it goes to the index page

However, if i access   http://localhost:8080/myapp/jsp/pages/fields/cycleList.jsp, it say access "HTTP 403 forbidden".

This could mean that, from the browser, jboss is able to see the folder

but why not <jsp:include...>

contents of my application.xml

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE application PUBLIC

    "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN"

    "http://java.sun.com/dtd/application_1_3.dtd">

<application>

  <display-name>myapp</display-name>

  <description>Parent project for artifacts.</description>

  <module>

    <web>

      <web-uri>myWeb.war</web-uri>

      <context-root>myapp</context-root>

    </web>

  </module>

</application>

I do not have anything mentioned for context-root in jboss-web.xml

When wildfly starts, I see this message below in the log file

10:55:54,306 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 81) WFLYUT0021: Registered web context: /myapp

If it helps for this to know the following in the log including the version of the so called undertow, this is what I see...

10:55:26,345 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0003: Undertow 1.4.0.Final starting

10:55:26,528 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0006: Undertow HTTP listener default listening on 0.0.0.0:8080

10:55:54,446 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://0.0.0.0:9990/management

10:55:54,447 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://0.0.0.0:9990

10:55:54,447 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.1.0.Final (WildFly Core 2.2.0.Final) started in 31299ms - Started 1818 of 2090 services (456 services are lazy, passive or on-demand)

Could you please guide me?

Message was edited by: Gnanasekaran Sakthivel - because the title could mislead people.

[sepgs2004]

Since I saw some relative path issues online and these JSP includes weren't working, I was misled to think this was a relative path issue.

This is also due to the fact that I could not get the logging working correctly. So I could not see why it was failing to load.

Actually, on all these JSP files (that were not successful in getting included), there were image tags with 'alt' attribute mentioned twice. I mean two times, alt was mentioned in the image tags, like shown below.

<img alt="Info." src="images\info.gif" align="right" alt="Information" />

For some 508 compliance or something, few developers were asked to do this, alt on image tags. They just kind of did it in every image tags, without even looking if there was already one.

However, JBoss 7.1.x did not complain about this.

Wildfly 10.1.x decided to not load the page at all (throwing an error message in the log). After I fixed the logging, I was able to see the error.

15:02:30,029 ERROR [stderr] org.apache.jasper.JasperException: /jsp/pages/fields/page.jsp (JBWEB004251: An error occurred at line: 40 column: 120) jsp.error.attribute.duplicate

Thank you for your time.

[jaikiran]

Thanks for posting that detail. It's interesting that this duplicate attribute contributed to the JSP inclusion problems. What exactly was preventing this logs/exception from appearing?

[sepgs2004]

About why the logging was not working -

When we were in JBoss 4 and 7, we had incorporated ESAPI (Enterprise Security API) for our logging, based on some standard compliance.

I was not in the direct development picture on this work. However, I guess it is like a filter sitting before the logging APIs, so it can encrypt (secure) the messages or whatever. Probably ESAPI takes over the logging, and so it may contain the log4j, etc.

Anyways, in order for this ESAPI to load successfully, we needed to exclude the log4j in our deployment file (C\JBoss-as-7.1.1.Final\standalone\deployments\myapp.ear\META-INF).

<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1">

     <deployment>

        <!-- Required for JBoss7 ESAPI to load.  Exclusions prevent automatic log4j dependency -->

       <exclusions>

            <module name="org.apache.log4j" />

        </exclusions>

    </deployment>

    <sub-deployment name="mloWeb.war">

          <exclusions>

               <module name="org.apache.log4j" />

          </exclusions>

    </sub-deployment>

</jboss-deployment-structure>

Even with this exclusion, our app was logging fine in JBoss 7.1.x.

Unfortunately, for WildFly 10.1.0, we had to remove this exclusion, for now, to make the logging work, until we figure out a way.