I filed a Jira task. https://issues.apache.org/jira/browse/FELIX-2201
best regards, Peter 2010/3/11 Peter Gardfjäll <[email protected]>: > Yes exactly. I'm just thinking of the file's last modification time. > > I guess you are right about the design. In this case the artifacts are > basically sets of "library bundles" that export packages rather than > services so there is not much I can do about that situation without > putting in a lot of effort. > > best regards, Peter > > On Thu, Mar 11, 2010 at 8:51 PM, Guillaume Nodet <[email protected]> wrote: >> 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] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
