reckart opened a new issue, #430: URL: https://github.com/apache/uima-uimaj/issues/430
**Describe the refactoring action** UIMA 3.6.0 introduced a new way of resolving imports in descriptors through SPIs via the `TypeSystemProvider.findResourceUrl(String)` method. Internally, the resolving of the imports is currently handled by the `Import_impl.findAbsoluteUrl(ResourceManager)` method which looks up all `TypeSystemProvider` implementations and then scans them until it finds one that provides the imported resource. Looking up the `TypeSystemProvider` implementation is particularly slow when using spifly in OSGi contexts. But also generally, whenever an SPI is looked up, it is instantiated so any information about the type systems is currently not cached in the providers. That means resolving imports, etc. is prone to be slow and this slowness is amplified by the lack of caching. So there are various options we might look at, e.g.: * `ResourceManager` or `RelativePathResolver` implementations could look up `TypeSystemProvider` implementations once and then cache them. The scope of visibility of one of these is less likely to change over time - and if so, it is much easier for the user to discard them and create new ones. Also, they already cache imported descriptors anyway, so it seems to be the proper place to also cache the SPIs. * The **uima-bnd-plugin** could possible be extended to not only consider the imports found in the current module but also follow these imports transitively while collecting package names to generate as OSGI package imports. This could be done by just looking at the UIMA import elements (like now) - or - by resolving the imports and then look at the package names of the imported types (which would work only if types and their XML descriptors live in the same packages - which they often do not). Also, if the scope of visibility of the imports is different at build time than they are at compile time, the generated OSGI package imports might be wrong - not sure if that could be a problem or if the scope at build time should always prescribe the scope at runtime... after all, for Java classes its like that and it works well (with OSGi). * `TypeSystemProvider` implementations could internally **statically** cache their information. However, that information might become stale as bundles are loaded/unloaded and the scope of visibility changes. It would be tricky also to reset these caches. Does not seem like a good life-cycle management. **Expected benefit** Situations that require looking up type systems and resolving imports should be fast again. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@uima.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
