uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard Eckart de Castilho (Jira)" <...@uima.apache.org>
Subject [jira] [Updated] (UIMA-6239) RelativePathResolver_impl does never fall back to context classloader
Date Fri, 05 Jun 2020 11:00:14 GMT

     [ https://issues.apache.org/jira/browse/UIMA-6239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Richard Eckart de Castilho updated UIMA-6239:
---------------------------------------------
    Description: 
The {{RelativePathResolver_impl}} can theoretically fall back to the thread context classloader
in {{resolveRelativePath(URL)}}:

{code}
URL absURL;
    if (mClassLoader != null) {
      absURL = mClassLoader.getResource(f);
    } else {// if no ClassLoader specified (could be the bootstrap classloader), try the system
    // classloader
    
      // https://issues.apache.org/jira/browse/UIMA-5902
      ClassLoader tccl = Thread.currentThread().getContextClassLoader();
      absURL = (tccl != null) ? tccl.getResource(f)  
                              : ClassLoader.getSystemClassLoader().getResource(f);
    }
    return absURL;
{code}

However, the default constructor explicitly sets the {{mClassLoader}} field:

{code}
  public RelativePathResolver_impl() {
    this(null);
    mClassLoader = getClass().getClassLoader();  // default value, maybe overridden by setPathResolverClassLoader
  }
{code}

This means, unless the classloader is explicitly set to null or unless the non-default constructor
is used, it never falls back to the thread context classloader.

My expectation would be that the fallback should be active by default and only if the user
explicitly sets a classloader, then it should not happen.

----

Also, there is no signature of {{UIMAFramwork.newDefaultResourceManager()}} which accepts
a classloader (or {{null}}). One has to create a {{new ResourceManager_impl(classloader)}}.

  was:
The {{RelativePathResolver_impl}} can theoretically fall back to the thread context classloader
in {{resolveRelativePath(URL)}}:

{code}
URL absURL;
    if (mClassLoader != null) {
      absURL = mClassLoader.getResource(f);
    } else {// if no ClassLoader specified (could be the bootstrap classloader), try the system
    // classloader
    
      // https://issues.apache.org/jira/browse/UIMA-5902
      ClassLoader tccl = Thread.currentThread().getContextClassLoader();
      absURL = (tccl != null) ? tccl.getResource(f)  
                              : ClassLoader.getSystemClassLoader().getResource(f);
    }
    return absURL;
{code}

However, the default constructor explicitly sets the {{mClassLoader}} field:

{code}
  public RelativePathResolver_impl() {
    this(null);
    mClassLoader = getClass().getClassLoader();  // default value, maybe overridden by setPathResolverClassLoader
  }
{code}

This means, unless the classloader is explicitly set to null or unless the non-default constructor
is used, it never falls back to the thread context classloader.

My expectation would be that the fallback should be active by default and only if the user
explicitly sets a classloader, then it should not happen.


> RelativePathResolver_impl does never fall back to context classloader
> ---------------------------------------------------------------------
>
>                 Key: UIMA-6239
>                 URL: https://issues.apache.org/jira/browse/UIMA-6239
>             Project: UIMA
>          Issue Type: Task
>          Components: Core Java Framework
>    Affects Versions: 2.10.4SDK
>            Reporter: Richard Eckart de Castilho
>            Priority: Major
>
> The {{RelativePathResolver_impl}} can theoretically fall back to the thread context classloader
in {{resolveRelativePath(URL)}}:
> {code}
> URL absURL;
>     if (mClassLoader != null) {
>       absURL = mClassLoader.getResource(f);
>     } else {// if no ClassLoader specified (could be the bootstrap classloader), try
the system
>     // classloader
>     
>       // https://issues.apache.org/jira/browse/UIMA-5902
>       ClassLoader tccl = Thread.currentThread().getContextClassLoader();
>       absURL = (tccl != null) ? tccl.getResource(f)  
>                               : ClassLoader.getSystemClassLoader().getResource(f);
>     }
>     return absURL;
> {code}
> However, the default constructor explicitly sets the {{mClassLoader}} field:
> {code}
>   public RelativePathResolver_impl() {
>     this(null);
>     mClassLoader = getClass().getClassLoader();  // default value, maybe overridden by
setPathResolverClassLoader
>   }
> {code}
> This means, unless the classloader is explicitly set to null or unless the non-default
constructor is used, it never falls back to the thread context classloader.
> My expectation would be that the fallback should be active by default and only if the
user explicitly sets a classloader, then it should not happen.
> ----
> Also, there is no signature of {{UIMAFramwork.newDefaultResourceManager()}} which accepts
a classloader (or {{null}}). One has to create a {{new ResourceManager_impl(classloader)}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message