[ 
https://issues.apache.org/jira/browse/FELIX-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861072#action_12861072
 ] 

Peter Gardfjäll commented on FELIX-2201:
----------------------------------------

Right, the patch wasn't foolproof. I guess it could be corrected quite easily 
by handling the case of equal timestamps:

/**
 * {...@link Comparator} that sorts {...@link File}s in increasing order of 
modification time 
 * ("oldest first"). When modification times are equal, artifacts are processed 
in lexicographical 
 * pathname order. 
 */
 private final class FileModificationTimeComparator implements Comparator {
     public int compare(Object arg0, Object arg1) {
         File lhs = (File) arg0;
         File rhs = (File) arg1;                                
         if (lhs.lastModified() == rhs.lastModified()) {
               return lhs.compareTo(rhs);
         }        
         return (int) (lhs.lastModified() - rhs.lastModified());
     }
}

@Martin: the artifact installer I'm writing handles zip file artifacts that 
group together several bundle jars, allowing them to be deployed as a single 
unit. This is similar to the Application/Subsystem spec (?) under development 
in the Aries project. In some cases, when my "subsystems" depend on one another 
(say bundles in B.zip relies on packages exported by bundles in A.zip), it is 
nice to know that FileInstall won't change the processing order after a clean 
restart of the framework. In the current, "no-order" processing, it is possible 
that, after a restart, FileInstall processes B.zip prior to A.zip, which causes 
B.zip installation to fail. Introducing a deterministic processing order seemed 
like a simple way to handle this, without introducing extra logic to my 
installer (to handle failed artifacts). Does that make any sense?

Anyhow, if this sounds totally unreasonable, it is fine to cancel this issue.
I have a working solution based on a custom-written directory watcher. 
Just thought it'd be nice to reuse the functionality provided by the 
FileInstall bundle.

> [FileInstall] Make Scanner process artifacts in 
> "oldest-file-modification-time first" order
> -------------------------------------------------------------------------------------------
>
>                 Key: FELIX-2201
>                 URL: https://issues.apache.org/jira/browse/FELIX-2201
>             Project: Felix
>          Issue Type: Improvement
>          Components: File Install
>    Affects Versions: fileinstall-2.0.4
>            Reporter: Peter Gardfjäll
>            Assignee: Guillaume Nodet
>             Fix For: fileinstall-2.0.10
>
>         Attachments: processing_order_patch.diff
>
>   Original Estimate: 0.08h
>  Remaining Estimate: 0.08h
>
> Currently FileInstall does not process new files in the load directory in any 
> particular order.
> It would be beneficial to have these artifacts processed in a 
> First-Come-First-Served order.
> That is, in order of increasing file modification time.
> Refer to the following email thread for details
>   http://www.mail-archive.com/us...@felix.apache.org/msg06949.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to