Bug 778042 (SOA-567)

Summary: reconfigure macro in schema/build.xml destroys original files
Product: [JBoss] JBoss Enterprise SOA Platform 4 Reporter: tcunning
Component: Build ProcessAssignee: Mike Brock <cbrock>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: 4.2 CP01CC: rruss
Target Milestone: ---   
Target Release: 4.3 IR4   
Hardware: Unspecified   
OS: Unspecified   
URL: http://jira.jboss.org/jira/browse/SOA-567
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-10-07 04:44:26 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description tcunning 2008-06-11 02:29:10 UTC
Date of First Response: 2008-06-11 08:51:26
project_key: SOA

The reconfigure macro moves files to {file}.orig, and then moves them instead of copying them - which destroys the original file.      If the second move in the sequence were a copy instead of a move, it would be possible to rerun the schema script.    I think the intention was to preserve the original file - the subsequent copies don't overwrite the .orig files.   

      <macrodef name="reconfigure">
            <attribute name="file"/>
            <attribute name="old"/>
            <attribute name="new"/>
            <sequential>
                <move file="@{file}" tofile="@{file}.orig"/>
                <move file="@{file}.orig" tofile="@{file}">
                    <filterchain>
                        <replacestring from="@{old}" to="@{new}"/>
                    </filterchain>
                </move>
            </sequential>
        </macrodef>

Comment 1 Len DiMaggio 2008-06-11 12:51:26 UTC
Tom - isn't this the same as:  SOA-512

Comment 2 Len DiMaggio 2008-06-16 12:28:00 UTC
Tom - isn't this a duplicate of SOA-512?

Comment 3 tcunning 2008-06-16 12:36:23 UTC
I don't believe so.      SOA-512 suggests that it's possible to change database configuration by removing files - this bug says that we destroy the original files so it will be impossible to accurately switch the database a second time.     The original files will no longer be there to use as replacement/change templates.

Comment 4 Jiri Pechanec 2008-08-20 14:19:01 UTC
Link: Added: This issue related SOA-695


Comment 5 nwallace 2008-09-25 19:29:33 UTC
Link: Added: This issue duplicates SOA-853


Comment 6 Jiri Pechanec 2008-10-07 04:44:26 UTC
Verified in IR5