The main reason, as hinted by Jean-Baptiste is the fact that when using the deploy folder, there's a much more limited control over the deployment order of the bundles. For example if you need to deploy 10 bundles, you copy them to the deploy folder, but the scanner may run while copying, so it may try to install 3 bundles, which may fail because they need other bundles which have not been copied yet. The problem should be solved a few seconds later when the other bundles are copied and the scanner has run again. Although, this way of deploying bundles, the start level of bundles can't be controlled and you can't make sure the configuration bits will be deployed at the same time. I think the refreshing of other bundles (for optional packages, fragments, etc...) is correctly dealt with, so it may not be as complete as the features deployer processing.
Guillaume 2016-03-08 3:27 GMT+01:00 satish jupalli <[email protected]>: > Based on couple of questions over the usage of deploy folder on production > seems to be not a good option. > > Though I got that, I'm trying to understand the implications of using > deploy folder for production deployment instead of features. > > What is the underlying cause for suggesting features.xml instead of deploy > folder. > > Any insights will be helpful. Also any karaf documentation references with > regards to same are appreciated. > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
