You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@uima.apache.org by re...@apache.org on 2020/06/05 12:45:40 UTC

[uima-uimafit] branch bugfix/UIMA-6240-Failure-to-resolve-type-system-imports-when-generating-descriptors created (now 4ac38a4)

This is an automated email from the ASF dual-hosted git repository.

rec pushed a change to branch bugfix/UIMA-6240-Failure-to-resolve-type-system-imports-when-generating-descriptors
in repository https://gitbox.apache.org/repos/asf/uima-uimafit.git.


      at 4ac38a4  [UIMA-6240] Failure to resolve type system imports when generating descriptors

This branch includes the following new commits:

     new 4ac38a4  [UIMA-6240] Failure to resolve type system imports when generating descriptors

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.



[uima-uimafit] 01/01: [UIMA-6240] Failure to resolve type system imports when generating descriptors

Posted by re...@apache.org.
This is an automated email from the ASF dual-hosted git repository.

rec pushed a commit to branch bugfix/UIMA-6240-Failure-to-resolve-type-system-imports-when-generating-descriptors
in repository https://gitbox.apache.org/repos/asf/uima-uimafit.git

commit 4ac38a4d7360b47237261d13da505078cf1ac10b
Author: Richard Eckart de Castilho <re...@apache.org>
AuthorDate: Fri Jun 5 14:10:17 2020 +0200

    [UIMA-6240] Failure to resolve type system imports when generating descriptors
    
    - Work around UIMA-6239 by explicitly passing a null classloader to the resource manager if a context classloader is set to force it to fall back to the context classloader.
---
 .../apache/uima/fit/internal/ResourceManagerFactory.java    | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/uimafit-core/src/main/java/org/apache/uima/fit/internal/ResourceManagerFactory.java b/uimafit-core/src/main/java/org/apache/uima/fit/internal/ResourceManagerFactory.java
index 4905564..5bf34fa 100644
--- a/uimafit-core/src/main/java/org/apache/uima/fit/internal/ResourceManagerFactory.java
+++ b/uimafit-core/src/main/java/org/apache/uima/fit/internal/ResourceManagerFactory.java
@@ -27,6 +27,7 @@ import org.apache.uima.UimaContextHolder;
 import org.apache.uima.impl.UimaVersion;
 import org.apache.uima.resource.ResourceInitializationException;
 import org.apache.uima.resource.ResourceManager;
+import org.apache.uima.resource.impl.ResourceManager_impl;
 import org.springframework.util.ClassUtils;
 
 /**
@@ -81,7 +82,17 @@ public class ResourceManagerFactory {
           // If there is no UIMA context, then we create a new resource manager
           // UIMA core still does not fall back to the context classloader in all cases.
           // This was the default behavior until uimaFIT 2.2.0.
-          ResourceManager resMgr = UIMAFramework.newDefaultResourceManager();
+          ResourceManager resMgr;
+          if (Thread.currentThread().getContextClassLoader() != null) {
+            // If the context classloader is set, then we want the resource manager to fallb
+            // back to it. However, it may not reliably do that that unless we explictly pass
+            // null here. See. UIMA-6239.
+            resMgr = new ResourceManager_impl(null);
+          }
+          else {
+            resMgr = UIMAFramework.newDefaultResourceManager();
+          }
+          
           
           // Since UIMA Core version 2.10.3 and 3.0.1 the thread context classloader is taken
           // into account by the core framework. Thus, we no longer have to explicitly set a