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]
