Description Vlad Klicnik 2001-10-10 22:49:15 EDT

PluginDescriptor.gerResourceBundle(Locate) is not fragment-aware (only looks inside the 
	plugin directory). Consequently, the NL versions of the plugin.properties files cannot be
	contributed by fragments.

NOTES:

JM (7/26/2001 10:04:07 AM)
	Shouldn't getResourceBundle() use the same classpath as the normal plugin class loader?
	Actually it is unclear why we need a different class loader at all?  the current code limits us to 
	finding resource bundles only in the install dir of the plugin.  Bundles in jars and in library
	directories will not be found.

VK (7/26/01 10:20:44 AM)
	I think where we are right now is a statement of how we evolved. The code predates fragments
	and was there so workbench could get at translated plugin.properties, or any other resource
	bundle that was NOT part of the actual code .jar. None of our plugins specify <library name="./"/>
	so the extra class loader was just a cheap way (in terms of coding) of getting the plugin.properties
	found and loaded. So the question is, what are the correct semantics to support? Some possible
	choices:
	(1)	use extra loader, make its classpath include plugin dir, and all detected fragment dirs. This
			would be "morally equivalent" to the current support. One would place plugin.properties
			files in the root of the plugin or fragment directory
	(2)	defer to the plugin loader to do the loading. This would require all plugins to specify
			<library name="./"/> so the default plugin.properties are found.
	(3)	use extra loader as today, but parent it using the plugin loader (rather than null).
			This would preserve current behavior (ie. not have the downside of (2)), but if we fail
			would then do the regular search (fragment aware). The fragments would have a choice
			of specifying <library name="./"/> and exposing the property file, or could just
			bundle it at a root of one of the supplied jars.
	Would need the <library name="./"/> handling fixed (as file:, not jar:).
	I think I would vote for (3) ... 

VK (7/26/01 10:43:21 AM)
	On second thought, (3) would cause the parent loader to be searched first before going to the 
	base plugin directory, so this may not be what we want. So
	(4)	use extra loader, its classpath set to plugin directory + classpath of plugin loader

VK (7/26/01 11:09:33 AM)
	Have tried with option (3) as the fix and things seem to work. 

	Looking at the trace, option (3) causes the classloaders for ALL plugins that contribute to the UI to be created 
	as part of the workbench startup. This is because the workbench is looking for the plugin.properties strings
	and option (3) causes the plugin loaders to be created. This may be OK (not a heavy operation) but some of the 
	plugin loaders may never be actually used beyond this point. Also, when searching for the bundles, option (3)
	causes the prereq loader trees to be searched (search is guaranteed to fail for plugin.properties bundles)

VK (7/27/01 11:56:41 AM)
	Have done a few unscientific measurements using option (3) [the simplest fix]. All are done using the following configuration:
		slow machine: PII-266
		Win-NT
		launching self-hosted eclipse, base drop + example plugins
		running from jars (not dev mode)
		running with -debug, but only runtime tracing enabled (to get timings)
		2 perspectives open on startup (resource, scripting)

		Case 1: drop 0.127
												1			2			3			4			5			Average (ms)
			Startup complete:	24925	24936	24916	24956	24876		24922

		Case 2: drop 0.127 + change for option (3)

			Startup complete:	26088	26150	26138	26077	26098		26110

		So it would appear the startup cost of creating all the loaders that contrinuted UI elements, PLUS performing 
		longer lookup searches for the plugin.properties bundles is about 1 second on my slow machine. 
		This is with the base drop plus examples. In a large configuration we are likely to have 2-5 times as many plugins
		contributing to the UI so we would see corresponding increase in startup times.

VK (7/30/01 3:03:18 PM)
	Option (4) comes out marginally slower than current support ... basically not paying the performance cost of option (3).
	The conclusion is that the actual extra cost is not from creation of the loaders, but rather from the unnecessary
	searching down the prerequisite tree (always guaranteed to fail for the bundle, is multipled by Java locale-based
	qualified name search). 

VK (7/30/01 11:47:39 AM)
	Have created "1GHOOPO: ITPCORE:WINNT - translated plugin.properties (R1.0 support)" to track the R1.0 partial fix.
	Using option (4) as the fix. Keeping this PR open to make sure we revisit this in the 2.0 stream.