It didn't fail for me on trunk when running the whole test suite. but it did
fail running just the one test UimaFitAnalysisEngineWithManditoryParameterTest.
I put in a catcher to see where all the class loaders are being created, and
they're all (all 8 of them!) being created as a result of the test case line 66:
AnalysisEngine ae = AnalysisEngineFactory.createEngine(RutaEngine.class,
RutaEngine.PARAM_RULES, script);
The uimaFIT code for createEngineDescription has:
TypeSystemDescription typeSystem = createTypeSystemDescription();
TypePriorities typePriorities = createTypePriorities();
...
createEngineDescription(...)
Each of these calls ends up creating a newResourceManager, which in turn is
setting up a new UIMA Extension Class Path.
Following the creation of the description, createEngine(desc) is called. This
creates another UIMA Class loader because of line 205 in AnalysisEngineFactory
(the call to newResourceManager()).
Then the produceAnalysisEngine eventually calls the "initialize" method, which
then runs RutaEngine.initialize, which calls
addUimafitAnalsysEngine, which then creates another Engine Description (doing
another 2 classloaders, one for the type system description, the other for the
type priorities (see above) ), and then creates the engine description from
those (another classloader),
and then creates an Engine from that description.
All of the extra class loader instances are mostly thrown away I think, but
there are two nested Engines, which is causing this issue.
So, one fix is to not have uimaFIT stick in the placeholder UIMA extension
loader every time it makes an Engine.
Another fix is to extend core UIMA to support multiple levels of nesting.
Any Opinions?
-Marshall
