<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE project [
<!--

    Copyright (c) 2017, 2018 Oracle and/or its affiliates. All rights reserved.

    This program and the accompanying materials are made available under the
    terms of the Eclipse Public License v. 2.0, which is available at
    http://www.eclipse.org/legal/epl-2.0.

    This Source Code may also be made available under the following Secondary
    Licenses when the conditions for such availability set forth in the
    Eclipse Public License v. 2.0 are satisfied: GNU General Public License,
    version 2 with the GNU Classpath Exception, which is available at
    https://www.gnu.org/software/classpath/license.html.

    SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0

-->

<!ENTITY autodeployUtil SYSTEM "./../util/util.xml">
<!ENTITY commonBuild SYSTEM "./../../config/common.xml">
]>
<!--
    Note that this currently assumes that the ear/earwithejb and ejb/statelesshello projects have run to build
    the ear used for this test.

    Also note that this test expects the 'grep' command to be present in the operating environment.
    This is fine on Solaris and Linux systems, and should be fine on Windows systems prepared
    according to the requirements for building the app server.
-->

<project name="autodeploy-slowcopy" default="all" basedir=".">

         &commonBuild;
        &autodeployUtil;

    <property name="testName" value="slowcopy"/>

    <target name="prepare" depends="init">
        <property name="inputArchive" value="${autodeploy.archive}"/>
        <property name="outputArchive" value="${autodeploy.dir}/${autodeploy.archive.name}"/>
        <!--
            The next property setting represents a 4-second delay between
            writes to the autodeployed file (by the SlowCopy test class invoked
            below).  This is based on the 2-second
            interval with which the autodeploy thread rechecks the files
            in the autodeploy directory.  By using a setting significantly
            longer than the 2-second autodeploy period, we test two code paths in the
            autodeploy code.

            One code path suppresses a retry of the file
            if it has failed to open successfully as an archive previously
            and has grown in size since the last check of the file.  The
            assumption in this case is that, since the file has grown since the
            last check, it might continue to grow and so we decide not to
            retry it at that moment.

            The other code path detects runs when the
            size has not changed since the last check.  This set of logic
            then tries to open the file as an archive
            again.  (Here, the assumption is that since the file did
            not grow since the previous check, it might be done growing and
            therefore it makes sense to try to open it again now).
            For most of the iterations, this code path finds that the archive
            still will not open correctly - because the slow copy is still
            in progress - and does not further work with the file in the
            current iteration but leaves the file in the map of files to be
            monitored.

            At last, when the copy completes, an iteration discovers that
            the file size has been stable since the last time through and
            the attempt to open the file as an archive succeeds.  The file
            is then autodeployed normally.
        -->
        <property name="slowcopy.delay" value="4000"/>

        <property name="result.property.file" value="${build}/result.properties"/>

        <mkdir dir="${build}" />
    </target>

    <target name="build" depends="prepare">

        <echo>Using previously-built ${inputArchive}</echo>
        <!--
            Some earlier tests should have run already, so the app we use for autodeploy testing
            should already be in place in the build directory.
        -->

    </target>

    <target name="private-all" depends="build">

        <antcall target="declare-test">
            <param name="description" value="autodeploy/slow Test autodeploy with slowly-copied file"/>
        </antcall>

        <!--
            The next task discards any previous temporary file used to gather property settings that
            record the results of the autodeploy directory monitoring Java class.
        -->
        <delete file="${result.property.file}" quiet="true"/>

        <tstamp prefix="slowcopy">
            <format property="NOW" pattern="${dateFormat}"/>
        </tstamp>

        <!--
            Do the auto-deployment but use the special tool that copies slowly.
         -->
         <echo>Copying ${inputArchive} slowly to the autodeploy directory</echo>
        <javaWithResult
                fork="true"
                failonerror="false"
                jvm="${JAVA}"
                classname="autodeploy.slowtest.SlowCopy"
                resultproperty="slow.autodeploy.deployResult"
                output="${build}/1.output.log"
            >
            <arg value="timed"/>
            <arg value="${inputArchive}"/>
            <arg value="${outputArchive}"/>
            <arg value="${slowcopy.delay}"/>

            <classpath refid="autodeploy.compile.classpath"/>

        </javaWithResult>

        <antcall target="useMonitorToWaitForAutodeployCompletion">
            <param name="log.id" value="2"/>
        </antcall>

        <!--
            Now undeploy the app.
        -->
        <antcall target="deploy.autoundeploy">
            <param name="archive.file" value="${outputArchive}"/>
            <param name="archive.name" value="${autodeploy.archive.name}"/>
            <param name="autodeploy.dir" value="${autodeploy.dir}"/>
            <param name="undeployResultPropertyName" value="undeployResult"/>
            <param name="log.id" value="3"/>
        </antcall>

        <!--
            Make the result properties of the several substeps accessible now because we need them in
            the next several steps.  The prefix attribute helps avoid possible collisions with other
            property names that might already be present.
        -->
        <property file="${result.property.file}" prefix="slow.autodeploy"/>

        <!--
            Decide whether the test was successful or not.  Make sure that the deploy and
            undeploy results are good.
        -->
        <condition property="result" value="0">
            <and>
                <equals arg1="${slow.autodeploy.deployResult}" arg2="0"/>
                <equals arg1="${slow.autodeploy.undeployResult}" arg2="0"/>
            </and>
        </condition>

        <!--
            If the property "result" was not set by the "condition" task just above then something
            went wrong and we set result to 1 now.
        -->
        <condition property="result" value="1">
            <not>
                <isset property="result"/>
            </not>
        </condition>

        <antcall target="processResult">
            <param name="result" value="${result}"/>
            <param name="log" value="${build}/output.log"/>
        </antcall>

    </target>

    <target name="useMonitorToWaitForAutodeployCompletion">
        <javaWithResult
                fork="true"
                failonerror="false"
                jvm="${JAVA}"
                classname="autodeploy.test.AutoDeployMonitor"
                resultproperty="autodeployResult"
                output="${build}/${log.id}.output.log"
            >
            <jvmarg value="-Dmonitor.debug=true"/>

            <classpath refid="autodeploy.compile.classpath"/>

            <arg value="${autodeploy.archive.name}"/>
            <arg value="${autodeploy.dir}"/>
            <arg value="${dateFormat}"/>
            <arg value="${slowcopy.NOW}"/>
        </javaWithResult>

        <!--
            The result property name used in the next task is an argument to the called target.
            Note that the echo is a little oddly formatted.  The </echo> is on a line by itself and left-justified so
            that the output to the file being written will reside on a line by itself.  The
            left-justification is not really needed but the properties file looks a bit nicer
            if you open it in an editor.  This is because the next line in the properties file being
            written is indented as far as the </echo> is indented here in the build.xml file.
        -->
        <echo file="${result.property.file}" append="true">${resultPropertyName}=${autodeployResult}
</echo>
    </target>

</project>