But how do you want to do that ? If you restart from a clean state, you don't have any prior information ? Or do I miss something. Are you thinking about the last modification date of the file itself ?
Also you may want to investigate why your three artifacts have to be deployed in significant order. In OSGi, this usually means a bad design (not relying on OSGi service, or not expecting an OSGi service to be absent). 2010/3/11 Peter Gardfjäll <[email protected]>: > Hi Guillame, > > The scenario is quite simple. I have three artifacts that my custom > ArtifactInstaller can handle. Call them A, B and C. > Also, C is dependent on the availability of B, which in turn is > dependent on artifact A. > That is, the deployment order needs to be A, followed by B, followed by C. > > At runtime, deploying these artifacts in the specified order works > fine. The ArtifactInstaller gets called to install each of the > artifacts in the order of deployment. In this case all artifacts will > be properly installed. > > Now, the framework is shut down and restarted fresh (with -clean flag > in equinox). This time, however, my ArtifactInstaller will be asked to > install the artifacts in the order C, A, B which will result in only A > and B being properly installed. If the directory watcher of > FileInstall honored the original deployment order ("oldest-first") the > deployment would succeed without needing to build in any special logic > in my ArtifactInstaller. > > I was just thinking that processing artifacts in "oldest-first" order > rather than "no-order" would be a non-intrusive change that can have > some nice benefits in terms of reduced complexity of custom > ArtifactInstallers. > > Does that make any sense? > > best regards, Peter > > > > On Wed, Mar 10, 2010 at 10:48 PM, Guillaume Nodet <[email protected]> wrote: >> And what kind of behavior do you see ? I mean how does it affect the >> runtime in any way ? >> >> 2010/3/10 Peter Gardfjäll <[email protected]>: >>> Right, the problem is not when artifacts are dropped in at runtime. >>> The problem is that after a framework restart, the artifacts get >>> reported out of order (that is, not in deployment order). >>> >>> best regards, Peter >>> >>> On Wed, Mar 10, 2010 at 10:08 PM, Guillaume Nodet <[email protected]> wrote: >>>> The deployment order should not be significant, unless there is a huge >>>> delay between copying two files, but in that case, trying to order the >>>> bundles won't matter, since some won't be available at all. If that's >>>> not the case, I would think this is a bug. >>>> >>>> The main reason is that all bundles are installed before being >>>> started, so you should not have any resolution problems, since all the >>>> bundles will be installed when the first one is resolved. >>>> >>>> 2010/3/10 Peter Gardfjäll <[email protected]>: >>>>> Hi, >>>>> >>>>> I've been experimenting some with writing a custom ArtifactInstaller >>>>> to extend the functionality of FileInstall. >>>>> As part of this effort, I have observed that the directory watcher >>>>> processes the files in the deployment/load directory in no particular >>>>> order. >>>>> I was thinking that since deployment order quite often is important >>>>> (at least judging from my experience), would it make sense to have the >>>>> directory watcher process files in an "oldest-first" manner (or at >>>>> least make the processing order configurable to some extent)? >>>>> This would prevent resolution problems for those cases where >>>>> bundles/artifacts have been copied to the "pickup directory" in >>>>> correct dependency order. >>>>> >>>>> Does it sound reasonable? If so, I can file a Jira issue. >>>>> >>>>> best regards, Peter >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Cheers, >>>> Guillaume Nodet >>>> ------------------------ >>>> Blog: http://gnodet.blogspot.com/ >>>> ------------------------ >>>> Open Source SOA >>>> http://fusesource.com >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
