Spring Tool Suite
  1. Spring Tool Suite
  2. STS-2377

Gradle web projects with javax.servlet dependency lead to errors on server

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.8.0.RELEASE, 2.8.1.RELEASE
    • Fix Version/s: 2.9.0.M2
    • Component/s: GRADLE
    • Labels:
      None

      Description

      We are in the process of writing an application (for a Spring MVC/Web Flow book) and we use Gradle as our build tool. We hoped to be able to use the Gradle support build-in STS. However strange things happen.

      We have a multi module project and each web project has 'org.glassfish:javax.servlet:3.0' and 'org.glassfish:javax.servlet.jsp:3.0' as a providedCompile dependency for the web app. If we now deploy this application to the tc server shipped with STS (or an freshly installed tomcat) we get errors as soon as a page is being displayed.

      We get LinkageErrors on the classes from the javax.servlet package. It appears as if the jars get deployed with the application and also loaded.

      The strange thing is if we use the eclipse plugin from gradle (gradlew cleanEclipse eclipse) it works like a charm, but using the plugin from STS we constantly get these exceptions.

        Activity

        Hide
        Kris De Volder (c) added a comment -

        Please have a look at this bug report.

        https://issuetracker.springsource.com/browse/STS-2063

        This seems like a very similar problem to yours. Though I did put something in that should address it... it is possible that your project or method of deployment etc. isn't quite covered by the fix. (I can't tell, because there is not enough information in your bug report to try to reproduce the problem).

        In any case, I think it is likely that the problem has something todo with dependencies being doubly deployed (once available from the server itself, and once from your web application). So you may be able to fix it by tweaking the "Gradle Dependencies Deployment Exclusions" configured via "Windows >> Preferences >> Gradle >> WTP".

        This isn't a nice solution, but it is the best that I can do unless Gradle guys resolve this issue:
        http://issues.gradle.org/browse/GRADLE-1777

        If you'd like a proper fix (I imagine you do), please vote on GRADLE-1777

        I'm keeping the bug open for now, but if you want me to look into it deeper, I'd need more info from you.
        Ideally, I'd like a sample project and some detailed steps on how to reproduce the problem with that sample.

        Show
        Kris De Volder (c) added a comment - Please have a look at this bug report. https://issuetracker.springsource.com/browse/STS-2063 This seems like a very similar problem to yours. Though I did put something in that should address it... it is possible that your project or method of deployment etc. isn't quite covered by the fix. (I can't tell, because there is not enough information in your bug report to try to reproduce the problem). In any case, I think it is likely that the problem has something todo with dependencies being doubly deployed (once available from the server itself, and once from your web application). So you may be able to fix it by tweaking the "Gradle Dependencies Deployment Exclusions" configured via "Windows >> Preferences >> Gradle >> WTP". This isn't a nice solution, but it is the best that I can do unless Gradle guys resolve this issue: http://issues.gradle.org/browse/GRADLE-1777 If you'd like a proper fix (I imagine you do), please vote on GRADLE-1777 I'm keeping the bug open for now, but if you want me to look into it deeper, I'd need more info from you. Ideally, I'd like a sample project and some detailed steps on how to reproduce the problem with that sample.
        Hide
        Kris De Volder (c) added a comment -

        > The strange thing is if we use the eclipse plugin from gradle (gradlew cleanEclipse eclipse) it works like a charm, but using the plugin from STS we constantly get these exceptions.

        This is somewhat expected. The tooling API is not providing enough information to properly configure the deployment assembly. So the dependencies inside the 'Gradle Dependencies' classpath container will all be deployed, even those that shouldn't be deployed because they are 'provided' by the server.

        Show
        Kris De Volder (c) added a comment - > The strange thing is if we use the eclipse plugin from gradle (gradlew cleanEclipse eclipse) it works like a charm, but using the plugin from STS we constantly get these exceptions. This is somewhat expected. The tooling API is not providing enough information to properly configure the deployment assembly. So the dependencies inside the 'Gradle Dependencies' classpath container will all be deployed, even those that shouldn't be deployed because they are 'provided' by the server.
        Hide
        Kris De Volder (c) added a comment -

        PS: If you can fix your problem by adding some jar patterns to the 'excludes' list in the Gradle WTP preferences page, please let me know. It may be useful to add this exclusion as a default for the next release of STS.

        Show
        Kris De Volder (c) added a comment - PS: If you can fix your problem by adding some jar patterns to the 'excludes' list in the Gradle WTP preferences page, please let me know. It may be useful to add this exclusion as a default for the next release of STS.
        Hide
        Marten Deinum added a comment -

        As mentioned we use the javax.servlet dependency from glass fish (those are the servlet 3.0 api jars available in the central maven repo). So I added javax.servlet.*\.jar as an exclusion which seems to solve the issue.

        However I still think this is a workaround instead of an actual solution. Would be nice if GRADLE-1777 would be fixed by the Gradle Team.

        Show
        Marten Deinum added a comment - As mentioned we use the javax.servlet dependency from glass fish (those are the servlet 3.0 api jars available in the central maven repo). So I added javax.servlet.*\.jar as an exclusion which seems to solve the issue. However I still think this is a workaround instead of an actual solution. Would be nice if GRADLE-1777 would be fixed by the Gradle Team.
        Hide
        Kris De Volder (c) added a comment -

        Thanks for confirming this. I will add "javax.servlet.*\.jar" to the default exclusions list.

        > However I still think this is a workaround instead of an actual solution. Would be nice if GRADLE-1777 would be fixed by the Gradle Team.

        I agree. A correct solution shouldn't have to use a list of regexp to do this but use the fact that a dependency is 'provided' instead. So I hope you put a vote on Gradle-1777

        I'll close this ticket. But I've opened a new ticket (STS-2380) to track the work I need to do once Gradle-1777 gets resolved.

        Thanks again for reporting the issue.

        Show
        Kris De Volder (c) added a comment - Thanks for confirming this. I will add "javax.servlet.*\.jar" to the default exclusions list. > However I still think this is a workaround instead of an actual solution. Would be nice if GRADLE-1777 would be fixed by the Gradle Team. I agree. A correct solution shouldn't have to use a list of regexp to do this but use the fact that a dependency is 'provided' instead. So I hope you put a vote on Gradle-1777 I'll close this ticket. But I've opened a new ticket ( STS-2380 ) to track the work I need to do once Gradle-1777 gets resolved. Thanks again for reporting the issue.
        Hide
        Kris De Volder (c) added a comment -

        Fix committed.

        Show
        Kris De Volder (c) added a comment - Fix committed.
        Hide
        Marten Deinum added a comment -

        Just an addition, we had also to add javax.servlet.jsp.*\.jar as an exclusion.

        Show
        Marten Deinum added a comment - Just an addition, we had also to add javax.servlet.jsp.*\.jar as an exclusion.
        Hide
        Kris De Volder (c) added a comment - - edited

        Doesn't the pattern "javax.servlet.*\.jar"
        already match everything that "javax.servlet.jsp.*\.jar" matches?
        I can add the extra pattern, no problem, but it seems redundant to me?

        Kris

        Show
        Kris De Volder (c) added a comment - - edited Doesn't the pattern "javax.servlet.*\.jar" already match everything that "javax.servlet.jsp.*\.jar" matches? I can add the extra pattern, no problem, but it seems redundant to me? Kris

          People

          • Assignee:
            Kris De Volder (c)
            Reporter:
            Marten Deinum
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              First Response Date: