Cargo
  1. Cargo
  2. CARGO-1051

The CARGO Jetty remote deployer uses a deprecated class

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.1.4
    • Component/s: Jetty
    • Labels:
      None
    • Complexity:
      Intermediate
    • Number of attachments :
      3

      Description

      As per Jetty's documentation at Eclipse, the ContextDeployer is deprecated in favor of something else.

      Next week I'll try to update your DeployerServer or hack-up a new implementation and see if I'm able to overcome this.

      I think that the new DeploymentManager exists since Jetty 7.1 (but not in Jetty 7.0): http://archive.eclipse.org/jetty/7.1.0.v20100505/apidocs/org/eclipse/jetty/deploy/DeploymentManager.html

        Issue Links

          Activity

          Hide
          Kohányi Róbert added a comment -

          (Ah, sorry I've commented to the wrong issue, I've copied the following from here.)

          I've looked into the issue some more. What I've found out that I can't load classes from the jetty-deploy-xxx.jar at runtime in a servlet's doXxx(...) method... only in the constructor. (See this link for an example of what I'm getting at.)

          Even if I capture Thread.currentThread().getContextClassLoader() in the constructor, which, I assume, actually loads the DeploymentManager class (because no exception is thrown there), and use that ClassLoader in doXxx(...) to instantiate the DeploymentManager I still get an exception.

          I admit that I don't get exactly how class loading works in a container environment, but still, this is just too much to handle.

          I wrote to Jetty's mailing list regarding this. I get back with the answer (if I get one).

          Show
          Kohányi Róbert added a comment - (Ah, sorry I've commented to the wrong issue, I've copied the following from here .) I've looked into the issue some more. What I've found out that I can't load classes from the jetty-deploy-xxx.jar at runtime in a servlet's doXxx(...) method... only in the constructor. (See this link for an example of what I'm getting at.) Even if I capture Thread.currentThread().getContextClassLoader() in the constructor, which, I assume, actually loads the DeploymentManager class (because no exception is thrown there), and use that ClassLoader in doXxx(...) to instantiate the DeploymentManager I still get an exception. I admit that I don't get exactly how class loading works in a container environment, but still, this is just too much to handle. I wrote to Jetty's mailing list regarding this. I get back with the answer (if I get one).
          Hide
          Savas Ali Tokmen added a comment -

          Fair enough -please let us know

          Show
          Savas Ali Tokmen added a comment - Fair enough -please let us know
          Hide
          Kohányi Róbert added a comment - - edited

          I've managed to solve the problem without too much work. (See this thread on the Jetty users mailing list for background.)

          Basically, one has to explicitly declare which classes or packages (from $JETTY_HOME/lib) can be seen by a webapp. There is a Jetty Wiki page describing the issue (it's a bit confusing).

          I'm going to include a patch for the DeployerServlet which fixes the java.lang.NoClassDefFoundExcetpion issue that I've described earlier (CARGO-983 ).

          I've yet to grasp the inner workings of the DeploymentManager to be able to actually use it. If the patch is adequate and tests still pass after its applied, then maybe we can save ourselves the trouble of updating the servlet.

          Show
          Kohányi Róbert added a comment - - edited I've managed to solve the problem without too much work. (See this thread on the Jetty users mailing list for background.) Basically, one has to explicitly declare which classes or packages (from $JETTY_HOME/lib ) can be seen by a webapp. There is a Jetty Wiki page describing the issue (it's a bit confusing). I'm going to include a patch for the DeployerServlet which fixes the java.lang.NoClassDefFoundExcetpion issue that I've described earlier ( CARGO-983 ). I've yet to grasp the inner workings of the DeploymentManager to be able to actually use it. If the patch is adequate and tests still pass after its applied, then maybe we can save ourselves the trouble of updating the servlet.
          Hide
          Kohányi Róbert added a comment -

          The promised patch for the DeployerServlet.

          Show
          Kohányi Róbert added a comment - The promised patch for the DeployerServlet .
          Hide
          Kohányi Róbert added a comment -

          OK. Class loading works as expected, however I'm back at square one, because when I'm trying to deploy remotely a WAR that uses JNDI I get the exception that got back at CARGO-983. Namely the: javax.naming.NamingException: This context is immutable; remaining name 'env'. (At the time I didn't even noticed that I got this exception... it was in the second log.

          However I've managed to track the source this "new" issue.

          In the deployArchive(...) method of the DeployerServllet a new WebAppContext is created for the inbound WAR after the actual WAR file is copied into Jetty's webapps directory. However copying a WAR into this directory automatically initiates Jetty's loading sequence generating... issues.

          I don't exactly what are the implications of removing the WebAppContext creating stuff from the DeployerServlet, however for me this solves the problem so I'm going to attach a new patch, which contains this new modification (as well as the previous).

          Show
          Kohányi Róbert added a comment - OK. Class loading works as expected, however I'm back at square one, because when I'm trying to deploy remotely a WAR that uses JNDI I get the exception that got back at CARGO-983 . Namely the: javax.naming.NamingException: This context is immutable; remaining name 'env' . (At the time I didn't even noticed that I got this exception... it was in the second log. However I've managed to track the source this "new" issue. In the deployArchive(...) method of the DeployerServllet a new WebAppContext is created for the inbound WAR after the actual WAR file is copied into Jetty's webapps directory. However copying a WAR into this directory automatically initiates Jetty's loading sequence generating... issues. I don't exactly what are the implications of removing the WebAppContext creating stuff from the DeployerServlet , however for me this solves the problem so I'm going to attach a new patch, which contains this new modification (as well as the previous).
          Hide
          Kohányi Róbert added a comment -

          Patch (contains the previous server_classes_redefinition.patch).

          Show
          Kohányi Róbert added a comment - Patch (contains the previous server_classes_redefinition.patch ).
          Hide
          Savas Ali Tokmen added a comment -

          Hi Kohányi

          Unfortunately your patch does not work: once applied, the remote container tests fail.

          You can try yourself by running mvn clean install -Pjetty8x, attaching the results and the logs.

          Can you please check?

          Show
          Savas Ali Tokmen added a comment - Hi Kohányi Unfortunately your patch does not work: once applied, the remote container tests fail. You can try yourself by running mvn clean install -Pjetty8x, attaching the results and the logs. Can you please check?
          Hide
          Kohányi Róbert added a comment - - edited

          For now I can only confirm that after applying the patch tests are failing with the same 404 error for me as well. However it does job for me (at least for now). I can deploy my WAR to my company's remote Jetty server without a hitch (I didn't try to redeploy and un-deploy though).

          I didn't look at the failing test cases too much, so I don't what can be the problem yet. I'll look into some more when I have the time! (I'm a little busy right now.)

          Show
          Kohányi Róbert added a comment - - edited For now I can only confirm that after applying the patch tests are failing with the same 404 error for me as well. However it does job for me (at least for now). I can deploy my WAR to my company's remote Jetty server without a hitch (I didn't try to redeploy and un-deploy though). I didn't look at the failing test cases too much, so I don't what can be the problem yet. I'll look into some more when I have the time! (I'm a little busy right now.)
          Hide
          Savas Ali Tokmen added a comment -

          This has probably been fixed by version 1.1.4, see related ticket references.

          Show
          Savas Ali Tokmen added a comment - This has probably been fixed by version 1.1.4, see related ticket references.

            People

            • Assignee:
              Unassigned
              Reporter:
              Kohányi Róbert
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: