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]
