akhikhl / gretty

Advanced gradle plugin for running web-apps on jetty and tomcat.
MIT License
657 stars 173 forks source link

Cannot resolve imports within JSP on Windows #372

Open Gontran08 opened 7 years ago

Gontran08 commented 7 years ago

I'm currently trying to migrate my ANT project to Gradle. I'm using Tomcat 8. Everything was going seamlessly on my Linux desktop, but for some reason, my JSP throw an exception if I try to run my project on Windows. My imports cannot be resolved. Yet, it's exactly the same project and I'm using Netbeans with both OS. I use appRun/appRunDebug to launch my app.

Here my build.gradle:

import org.gradle.internal.os.OperatingSystem
import org.apache.tools.ant.filters.ReplaceTokens

plugins {
    id 'java'
    id 'war'
    id 'org.akhikhl.gretty' version '2.0.0' 
}

sourceCompatibility = '1.8'
[compileJava, compileTestJava]*.options*.encoding = 'UTF-8'

repositories {
    mavenCentral()
    maven {
        url "https://clojars.org/repo" // Used for sqljdbc4
    }
}

dependencies {
    // https://mvnrepository.com/artifact/au.com.bytecode/opencsv
    compile group: 'au.com.bytecode', name: 'opencsv', version: '2.4'
    // https://mvnrepository.com/artifact/com.lowagie/itext
    compile group: 'com.lowagie', name: 'itext', version: '2.1.7'
    // https://mvnrepository.com/artifact/commons-dbutils/commons-dbutils
    compile group: 'commons-dbutils', name: 'commons-dbutils', version: '1.6'
    // https://mvnrepository.com/artifact/commons-discovery/commons-discovery
    compile group: 'commons-discovery', name: 'commons-discovery', version: '0.5'
    // https://mvnrepository.com/artifact/commons-fileupload/commons-fileupload
    compile group: 'commons-fileupload', name: 'commons-fileupload', version: '1.1.1'
    // https://mvnrepository.com/artifact/commons-lang/commons-lang
    compile group: 'commons-lang', name: 'commons-lang', version: '2.6'
    // https://mvnrepository.com/artifact/com.vividsolutions/jts
    compile group: 'com.vividsolutions', name: 'jts', version: '1.13'
    // https://mvnrepository.com/artifact/javax.mail/mailapi
    compile group: 'javax.mail', name: 'mailapi', version: '1.4.3'
    // https://mvnrepository.com/artifact/javax.servlet/jstl
    compile group: 'javax.servlet', name: 'jstl', version: '1.2'
    // https://mvnrepository.com/artifact/javax.xml/jaxrpc
    compile group: 'javax.xml', name: 'jaxrpc', version: '1.1'
    // https://mvnrepository.com/artifact/log4j/log4j
    compile group: 'log4j', name: 'log4j', version: '1.2.17'
    // https://mvnrepository.com/artifact/net.sf.json-lib/json-lib
    compile group: 'net.sf.json-lib', name: 'json-lib', version: '2.4', classifier: 'jdk15'
    // https://mvnrepository.com/artifact/org.apache.axis/axis
    compile group: 'org.apache.axis', name: 'axis', version: '1.4'
    // https://mvnrepository.com/artifact/org.apache.struts/struts-core
    compile group: 'org.apache.struts', name: 'struts-core', version: '1.3.10'
    // https://mvnrepository.com/artifact/org.apache.struts/struts-taglib
    compile group: 'org.apache.struts', name: 'struts-taglib', version: '1.3.10'
    // https://mvnrepository.com/artifact/org.codehaus.castor/castor-xml
    compile group: 'org.codehaus.castor', name: 'castor-xml', version: '1.3.3'
    // https://mvnrepository.com/artifact/org.jdom/jdom
    compile group: 'org.jdom', name: 'jdom', version: '1.1.3'
    // https://mvnrepository.com/artifact/org.seleniumhq.selenium/selenium-java
    compile group: 'org.seleniumhq.selenium', name: 'selenium-java', version: '2.33.0'
    // https://mvnrepository.com/artifact/wsdl4j/wsdl4j
    compile group: 'wsdl4j', name: 'wsdl4j', version: '1.5.3'

    // Libs provided by the tomcat server. Must use the same version as the tomcat provided by gretty.
    // https://mvnrepository.com/artifact/org.apache.tomcat/tomcat-catalina
    providedCompile group: 'org.apache.tomcat', name: 'tomcat-catalina', version: '8.0.44'
    // https://mvnrepository.com/artifact/org.apache.tomcat/tomcat-jdbc
    providedCompile group: 'org.apache.tomcat', name: 'tomcat-jdbc', version: '8.0.44'
}

gretty {
    // Servlet container to be used. With gretty 2.0.0, it's Tomcat 8.0.44 by default.
    // Can be defined manually: http://akhikhl.github.io/gretty-doc/Overriding-servlet-container-versions.html
    // If the tomcat version change, we must change dependencies too.
    servletContainer = 'tomcat8'
    dependencies {
        // https://mvnrepository.com/artifact/org.apache.tomcat/tomcat-dbcp
        gretty 'org.apache.tomcat:tomcat-dbcp:8.0.44'
        // https://mvnrepository.com/artifact/com.microsoft.sqlserver/sqljdbc4
        gretty 'com.microsoft.sqlserver:sqljdbc4:4.0'
        // https://mvnrepository.com/artifact/org.clojars.prepor/vertica-jdbc
        gretty 'org.clojars.prepor:vertica-jdbc:7.0.1-0'
    }
    scanner = 'jdk'

    // These three ports must be unique to be able to use multiple tomcat.
    httpPort = 8180 // TCP-port used by servlet-container for incoming HTTP-requests.
    servicePort = 9910 // TCP-port used by Gretty to send commands to servlet-container process.
    statusPort = 9911 // TCP-port used by servlet-container process to send status back to Gretty.

    contextPath = 'app' // Context path for the web-app.

    enableNaming = true // When true, Tomcat supports JNDI resource naming.
    recompileOnSourceChange = false // Should the given web-app automatically recompile on source change?
    reloadOnClassChange = false
    reloadOnConfigChange = false
    reloadOnLibChange = false

    logDir = 'logs'
    logFileName = 'myApp.log'
}
Gontran08 commented 7 years ago

If I use appRunWar/appRunWarDebug, my app works. It seems that we use the wrong classpath for JSP on Windows while using appRun/appRunDebug.

Gontran08 commented 7 years ago

I have the same problem while using appBeforeIntegrationTest. It prevents me from running my tests on Windows.

Gontran08 commented 7 years ago

I couldn't find any workaround for this issue. I always have an error saying that my import cannot be resolved when I try to open a JSP while using inplace mode on Windows. I don't have this problem while using Linux.


javax.servlet.ServletException: org.apache.jasper.JasperException: Unable to compile class for JSP: 

An error occurred at line: [14] in the generated java file: [[...]\build\serverBaseDir_tomcat8\work\Tomcat\localhost\app\org\apache\jsp\Main_jsp.java]
The import [...] cannot be resolved

The import that cannot be resolved comes from my project. Imports coming from javax are resolved without problem.

Gontran08 commented 7 years ago

I'm using a farm and the problem seems to only affect one of the two projects. Always the same project.

nickcotter commented 4 years ago

We have come across what looks to be the same or very similar issue very recently (within the last month or so - we cannot be sure when it began). Our web app project has various JSP tags that import classes that are either part of the web app or are part of a jar dependency. The imports for those classes that are part of the jar fail with the error described above. Again, the actual WAR file, when deployed, works fine, and appRunWar etc. work as well - it's only appRun.

We are seeing the problem on Windows machines (7 & 8) and OSX (10.15.1) but not Ubuntu 18.0.4. We're using java 8.0.232

nickcotter commented 4 years ago

We have further refined the problem in our case.

First, it's likely this problem was introduced (to us) when the dependency moved from being an external jar dependency to a gradle project dependency. Previously the jar was retrieved from a maven repo but now it's a different sub-project in the same gradle hierarchy, and this is definitely a new problem for us. We haven't verified this but the timing seems correct. Again I must stress that when a WAR is produced there is no problem.

Secondly it appears to be due to a name clash. It only affects classes whose name is the same as a package name - even when they have a different case. Eg in our case we have a package called com.company.report that couldn't be imported, but there is also a class called com.company.Report - this may be bad style but it shouldn't be a problem!

My suspicion would be that this is a combination of how jasper compilation works together with something in the way gradle (at least 4.10.3 which is the version we are using) unravels "project" dependencies.