Hi All, Existing OSGi deployment logic [1] keep updating the bundles.info file as and when a bundle is added/removed from the [product_home]/lib directory.
1. It first read the bundles.info file of the current runtime 2. Then take the list of bundles coming from "plugins" directory. 3. Adds the bundles in the [product_home]/lib directory to the previous list 4. Get distinct bundles based on the bundle symbolic name and version. (ignores bundles with same symbolic name and version already in the list, hence bundles in the plugins directory get the priority) 5. Update the bundles.info file The above-mentioned approach assumes all basic bundles for the runtime coming from the "plugins" directory and adds the external bundles on top of it. Recently we were looking into the C5 update/patching model and there was a concern on how we could add a temporary log patches, etc. to identify an issue. (in a case where all other possibilities failed). The most convenient to the client is to just add the given log patch to the pack, restart, collect the relevant logs, and finally revert the log patch. Any additional steps would be an overhead as the client is already undergoing a severe issue and client is trying to help us to identify the issue by applying the log patch. Hence this should be modeled in a convenient way to the users. There is a possibility to let the clients add the log patch into the [product_home]/lib directory and remove it once done. But with the current OSGi bundle deployment logic, we can't do that as it always gives the priority to the bundles in the plugins directory. If we put a bundle with the same bundle-symbolic-name and version into the plugins directory it will be ignored. To achieve this behavior we have to modify the existing OSGi bundle deployment logic as follows. 1. In the first run make a backup of the original bundles.info file (bundles.info.original this will be used as the baseline for each time it updated the bundles.info file) 2. Read the bundles.info.original file 3. Add the bundles in the [product_home]/lib directory 4. Update the bundles.info file And The logic in selecting effective bundles list should be changed to not to give priority to bundles in the plugins directory. Instead modify the entries, if a similar bundle (symbolic name and version) is found in the [product_home]/lib Above suggested approach allows easily add the patched jars into the [product_home]/lib directory for temporary purposes. And reverting the patch is also possible as we have a backup of the original bundles.info file WDYT? [1] https://github.com/wso2/carbon-kernel/blob/v5.2.0-m3/ launcher/src/main/java/org/wso2/carbon/launcher/extensions/ OSGiLibBundleDeployerUtils.java Thanks, *Jayanga Dissanayake* Associate Technical Lead WSO2 Inc. - http://wso2.com/ lean . enterprise . middleware email: jaya...@wso2.com mobile: +94772207259 <http://wso2.com/signature>
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
