felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Gardfjäll (JIRA) <j...@apache.org>
Subject [jira] Commented: (FELIX-2201) [FileInstall] Make Scanner process artifacts in "oldest-file-modification-time first" order
Date Mon, 26 Apr 2010 20:02:33 GMT

    [ 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/users@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.


Mime
View raw message