Click
  1. Click
  2. CLK-340

Click still deploys files when war is not unpacked

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.4
    • Fix Version/s: 1.5 M1, 1.4.1
    • Component/s: None
    • Labels:
      None

      Description

      When a servlet container is setup not to unpack its war, Click still continues to deploy its files.

      This can be reproduced in Tomcat by setting the <Host> property unpackWARs="false" in server.xml.

      Once this property is disabled, Click will still deploy its files to a "null" directory.

        Activity

        Hide
        Bob Schellink added a comment -

        fix checked in for 1.5M1 and 1.4.1

        Show
        Bob Schellink added a comment - fix checked in for 1.5M1 and 1.4.1
        Hide
        Malcolm Edgar added a comment -

        How does this scenario work. Tomcat is configured not to unpack WAR files, how will he click resources be made available?

        regards Malcolm Edgar

        Show
        Malcolm Edgar added a comment - How does this scenario work. Tomcat is configured not to unpack WAR files, how will he click resources be made available? regards Malcolm Edgar
        Hide
        Bob Schellink added a comment -

        If a WAR is not unpacked deployment cannot work. The war itself must be self contained. In other words everything the war needs must already be available in the war.

        Since the developer or server admin decided not to unpack wars, they will have to include everything in the WAR manually. Thus their WAR must include the "click" dir with all resources before packing up their war.

        There is not much Click can do about it since getRealPath() will return null. This is compliant with the Servlet Spec as well. ServletContext#getRealPath states:

        "The real path returned will be in a form appropriate to the computer and operating system on which the servlet container is running, including the proper path separators.
        This method returns null if the servlet container cannot translate the virtual path to a real path for any reason (such as when the content is being made available from a .war archive)."

        The best we can do is FAQ on this topic.

        BTW the problem this issues tries to fix is that Click tried to deploy the files to the getRealPath("/") directory even when WAR was not unpacked. If the WAR is not unpacked getRealPath("/") returns null. Click then deployed to this null directory. In my case this null directory ended up under the bin folder:

        c:\ apps \ java \ tomcat-6.0.13 \ bin \ null \ ...

        Show
        Bob Schellink added a comment - If a WAR is not unpacked deployment cannot work. The war itself must be self contained. In other words everything the war needs must already be available in the war. Since the developer or server admin decided not to unpack wars, they will have to include everything in the WAR manually. Thus their WAR must include the "click" dir with all resources before packing up their war. There is not much Click can do about it since getRealPath() will return null. This is compliant with the Servlet Spec as well. ServletContext#getRealPath states: "The real path returned will be in a form appropriate to the computer and operating system on which the servlet container is running, including the proper path separators. This method returns null if the servlet container cannot translate the virtual path to a real path for any reason (such as when the content is being made available from a .war archive)." The best we can do is FAQ on this topic. BTW the problem this issues tries to fix is that Click tried to deploy the files to the getRealPath("/") directory even when WAR was not unpacked. If the WAR is not unpacked getRealPath("/") returns null. Click then deployed to this null directory. In my case this null directory ended up under the bin folder: c:\ apps \ java \ tomcat-6.0.13 \ bin \ null \ ...
        Hide
        Andre Bremer added a comment -

        Perhaps a click "main" method to deploy Click resources would be useful for build scripts like ANT or even Maven

        Making it easier to build the whole application without a container setup.

        If someone writes the "main" method I'll help the Maven plugin goal (Perhaps even the Ant task)

        vyoman

        Show
        Andre Bremer added a comment - Perhaps a click "main" method to deploy Click resources would be useful for build scripts like ANT or even Maven Making it easier to build the whole application without a container setup. If someone writes the "main" method I'll help the Maven plugin goal (Perhaps even the Ant task) vyoman
        Hide
        Ahmed Mohombe added a comment -

        > Since the developer or server admin decided not to unpack wars,
        > they will have to include everything in the WAR manually.
        > Thus their WAR must include the "click" dir with all resources
        > before packing up their war.
        IMHO this is too much trouble if one considers the 3rd party controls too.
        A better approach would be to have a "predeploy" ant task, that the developer
        could use, and that would call the "onDeploy" for all pages and controls, ensuring
        correct resources(just before packaging the WAR).

        Click.xml would also need a predeployed="true" parameter (default false), to know that
        it's pre-deployed, and not try to do it.

        IMHO this would be clean and simple for such scenarios.

        One could use the "predoploy" strategy to increase runtime startup performance too (not
        just for cases where the WAR won't be unpacked.

        Ahmed.

        -------------------------------------------------------------------------
        Check out the new SourceForge.net Marketplace.
        It's the best place to buy or sell services for
        just about anything Open Source.
        http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
        _______________________________________________
        Click-development mailing list
        Click-development@lists.sourceforge.net
        https://lists.sourceforge.net/lists/listinfo/click-development

        Show
        Ahmed Mohombe added a comment - > Since the developer or server admin decided not to unpack wars, > they will have to include everything in the WAR manually. > Thus their WAR must include the "click" dir with all resources > before packing up their war. IMHO this is too much trouble if one considers the 3rd party controls too. A better approach would be to have a "predeploy" ant task, that the developer could use, and that would call the "onDeploy" for all pages and controls, ensuring correct resources(just before packaging the WAR). Click.xml would also need a predeployed="true" parameter (default false), to know that it's pre-deployed, and not try to do it. IMHO this would be clean and simple for such scenarios. One could use the "predoploy" strategy to increase runtime startup performance too (not just for cases where the WAR won't be unpacked. Ahmed. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Click-development mailing list Click-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/click-development

          People

          • Assignee:
            Malcolm Edgar
            Reporter:
            Bob Schellink
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development