Community
Participate
Working Groups
Here is a copy of a bug that has been entered against PluginParser but that is also probably true for the ExtensionsParser. The PluginConverterImpl and various Classes in core.runtime aquire a ServiceReference to the SAXParserFactory each time they want to parse an XML file. After parsing each file we end up releasing the service reference and discarding the SAXParserFactory. This likely only effects performance on initial startup when we are reading all the xml files the first time and caching the data (This will happen twice for each installed bundle). While this operation is not extremely expensive, it does not come for free either. It would help to use a ServiceTracker object that can be used to cache our reference to the SAXParserFactory service.
take a quick look for RC2. The idea is to make a service tracker and keep it around then just to getService() when you need the service.
Created attachment 11883 [details] patches for runtime and tests.runtime
Tom, could you review the changes?
I suggest you don't initialize the ServiceTracker object in a static initializer. This will prevent the runtime bundle from working if it is stopped and started again without refreshing (note that this is not really a supported scenario, but I would not recommend adding more reasons to why this cannot be done) I suggest you add two static methods to ExtensionsParser: initiaize() - to initialize and open the ServiceTracker object shutdown() - to close and null out the ServiceTracker object The initialize() should be called by InternalPlatform.start() and shutdown should be called by InternalPlatform.stop().
Created attachment 11909 [details] patch for runtime (did not include the patch for tests.runtime since they don't have anything interesting)
Incorporated Tom's suggestions (with slight differences). Jeff, please review.
Created attachment 11910 [details] patch for runtime
Created attachment 11911 [details] patch for tests.runtime
I had already released my previous changes when we realized that we had a thread safety problem. These patches are against what is in HEAD. You may want to apply the changes and then compare against two revisions before the latest one. Tom, please review. Jeff will re-review and release the code tonight.
Jeff, just to make sure you noticed it: the changes to tests.runtime must be released at the same time.
patch looks good to me.
patch for runtime and runtime.tests comitted.