Hi all, the dropins capability of C5 has been currently redesigned with the primary focus on server startup time reduction.
The existing implementation is a Carbon server listener which listens to the Carbon server startup in order to execute. Some of the major drawbacks of the existing C5 implementation are as follows: - *whether there is a change to the dropins folder files or not, compared with the previous server startup*, the bundles.info file of the Carbon profile is always updated. - the user has no option to update the required Carbon profile bundles.info file with the latest dropins directory, OSGi bundle information *without starting the server*. After a series of team discussions, we have managed to come up with the following design decisions: - As mentioned by Sameera in the above mail, the user has the opportunity to enable/disable the mechanism of updating the relevant Carbon Profile bundles.info file at the server startup. - A user will have the opportunity to run an external, dropins tool (which does not require the server running when executing) which updates a chosen Carbon Profile or all Carbon Profiles with the latest, dropins directory OSGi bundle information. - The overview of the mechanism used for this profile update is as follows: 1. The OSGi bundle information of the latest dropins directory bundles will be read once. 2. The existing bundles.info file of the chosen Carbon Profile *or* bundles.info files of all Profiles will be compared with latest information - if the existing bundle information are different to the latest bundle information, the desired Carbon Profile(s) will be updated with the latest information. During an internal team discussion today, we reached the following decisions: - The Profile update mechanism at server startup will use the 'profile' system property if defined to identify which Profile to be updated, if the property is unspecified - 'default' Carbon Profile will be updated. - The dropins tool will provide the user with the opportunity to choose a specific Carbon Profile or choose all Profiles to be updated. Appropriate usage instructions of the tool are to be provided, if incorrectly used. - It was decided that during the execution of the above functionality, the latest OSGi bundle information of dropins directory are to be read only once, rather than reading the latest information for every Profile to be updated. This information will be used for further processing. - The need for accurate, clear, informative logs of the execution of the function was highly emphasized. This will ease the developers' work in clearly understanding the dropins capability mechanism. Clear, informative error logs in order to track any issues will be vital. - It was discussed that this mechanism is to be tested for numerous, possible scenarios (ex:- scenarios associated with different file permissions) - The introduction of the CarbonTool interface, a functional interface which has to be implemented when adding a new, custom, external tool to Carbon-kernel. Currently, the existing Carbon JAR-to-OSGi-bundle converter tool and the new dropins tool will implement this. A tool executor will execute the relevant tool based on the system property specifying which tool to run (passed from the relevant tool script file) and the tool arguments. Further, it was agreed that any implementation of this interface will have to perform exception handing within the implemented method itself and refrain from throwing further exceptions from the interface method (ex:- a pattern used by majority of Java's functional interfaces such as, Runnable and Callable). Any suggestions and feedback are highly appreciated. On Thu, Apr 7, 2016 at 2:57 PM, Sameera Jayasoma <[email protected]> wrote: > Hi All, > > Suggestion is to allow users to enable/disable dropins bundle deployment > and patch installation during server startup. We can enable these tasks by > default. But users can disable these tasks in production deployments / > docker based deployments. This will reduce the server startup time. > > Then we need to provide tooling to install dropins bundles as well as > patches. This way users can pre-configure our product distribution with > dropins and patches. Also this would allow users to disable dropins and > patch installation during the server startup. > > This would eliminate the need to verify whether the dropins bundles and > patches are installed properly. > > Note: We have not finalized patching model for C5 yet. > > Thanks, > Sameera. > > > > -- > Sameera Jayasoma, > Software Architect, > > WSO2, Inc. (http://wso2.com) > email: [email protected] > blog: http://blog.sameera.org > twitter: https://twitter.com/sameerajayasoma > flickr: http://www.flickr.com/photos/sameera-jayasoma/collections > Mobile: 0094776364456 > > Lean . Enterprise . Middleware > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Chiranga Alwis, Software Engineering Intern, +94 77 5930497 +94 77 6368208
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
