UIMA
  1. UIMA
  2. UIMA-1714

Message Bundles not visible when loaded under a UIMA Resource Manager class loader

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.3
    • Fix Version/s: 2.3.1SDK
    • Component/s: Core Java Framework
    • Labels:
      None

      Description

      UIMA-AS has message bundles. When uima-as classes are loaded under a resource manager class loader, the message bundle is not visible when logging occurs.

        Activity

        Hide
        Marshall Schor added a comment -

        This seems quite difficult to fix, and stems from a strange situation where the uima-as framework, rather than being "added" to the base uima framework, is being supplied via a UIMA ResourceManager extension classpath and its associated loader.

        Rather than trying to fix the error logging mechanism so this would work (I think it can be done, see below, but it's rather ugly), another approach would be to better integrate uima-as with the core framework.

        This would mean that we would need to figure out how to properly hook up the uima-as fragment bundle to the CDE plugin, if it was available, and change the CDE classpath-from-project code to exclude the uima-as jars (so they would be obtained from the bundle fragment). This exclusion might be quite hard to do, and also would be hard to maintain, so maybe it's not quite the right approach. The current method excludes jars by seeing if the candidate jar contains a particular class belonging to the set to be excluded. Currently, only uimaj-core is excluded.

        The fix for the error logging mechanism is to have the constructor for UIMA Framework classes that do logging calls test to see if they're beling loaded by a UIMA ClassLoader, and if so, make up a dummy resourceManager instance, setting its extension class loader to use that same UIMA ClassLoader, and then telling the class's particular logging instance to use that resource manager to get the loader to load the resource bundles for the error messages.

        Unfortunately, this "fix" hits every class which does logging in uima-as (and also maybe in uima base jars if they are doing logging), other than the core jar, I think).

        I think work on this I'll defer to post 2.3.0 release

        Show
        Marshall Schor added a comment - This seems quite difficult to fix, and stems from a strange situation where the uima-as framework, rather than being "added" to the base uima framework, is being supplied via a UIMA ResourceManager extension classpath and its associated loader. Rather than trying to fix the error logging mechanism so this would work (I think it can be done, see below, but it's rather ugly), another approach would be to better integrate uima-as with the core framework. This would mean that we would need to figure out how to properly hook up the uima-as fragment bundle to the CDE plugin, if it was available, and change the CDE classpath-from-project code to exclude the uima-as jars (so they would be obtained from the bundle fragment). This exclusion might be quite hard to do, and also would be hard to maintain, so maybe it's not quite the right approach. The current method excludes jars by seeing if the candidate jar contains a particular class belonging to the set to be excluded. Currently, only uimaj-core is excluded. The fix for the error logging mechanism is to have the constructor for UIMA Framework classes that do logging calls test to see if they're beling loaded by a UIMA ClassLoader, and if so, make up a dummy resourceManager instance, setting its extension class loader to use that same UIMA ClassLoader, and then telling the class's particular logging instance to use that resource manager to get the loader to load the resource bundles for the error messages. Unfortunately, this "fix" hits every class which does logging in uima-as (and also maybe in uima base jars if they are doing logging), other than the core jar, I think). I think work on this I'll defer to post 2.3.0 release
        Hide
        Marshall Schor added a comment -

        defer past 2.3.0

        Show
        Marshall Schor added a comment - defer past 2.3.0
        Hide
        Marshall Schor added a comment -

        After some more investigation, I think a better fix is to change the way the resource bundles are looked up for error messages. Right now, the logic is spread across multiple classes.

        For instance, for the JSR47 logger, part is in JSR47Logger_impl, in the method getExtensionClassLoader which returns the ResourceManager's extension class loader or null if there is none. Then, the I18nUtil.localizeMessage method has logic to use the passed-in extensionClassLoader (which might be null) and if it is null, it uses the class loader that loaded the I18nUtil class or the "system" classloader if it gets "null" for I18nUtil.class.getClassLoader() call.

        I think that a better strategy would be to, in essence, try a series of class loaders, until one succeeds, or all of them fail. The order would go something like:

        1. ResourceManager's extension class loader
        2. the thread's contextClassLoader
        3. the class loader that loaded the I18nUtil class
        4. the class loader that loaded the caller of the localizeMessage method
        5. the class loader that loaded the 2nd previous caller
        6. the class loader that loaded the 3rd previous caller
          etc.

        Of course, you would only try a class loader if it was different from one already tried.

        This approach allows frameworks to find and load resources they cannot see with their own class loaders, but which belong with class-loader-isolated components. Here's one article that tries to explain why this is a good idea: http://www.javaworld.com/javaworld/javaqa/2003-06/01-qa-0606-load.html

        Another similar approach is used by the Eclipse plugin mechanism when it is trying to find classes or resources to load that might belong to user code - sets up a ContextClassLoader to do the work of running up the chain of callers, as above, trying them to see if they can load the thing requested. See http://wiki.eclipse.org/Context_Class_Loader_Enhancements. Eclipse defines a new class loader which implements this kind of algorithm - see

        Java has a method which returns the set of classes on the call stack, in order: aSecurityManagerInstance.getClassContext().

        Show
        Marshall Schor added a comment - After some more investigation, I think a better fix is to change the way the resource bundles are looked up for error messages. Right now, the logic is spread across multiple classes. For instance, for the JSR47 logger, part is in JSR47Logger_impl, in the method getExtensionClassLoader which returns the ResourceManager's extension class loader or null if there is none. Then, the I18nUtil.localizeMessage method has logic to use the passed-in extensionClassLoader (which might be null) and if it is null, it uses the class loader that loaded the I18nUtil class or the "system" classloader if it gets "null" for I18nUtil.class.getClassLoader() call. I think that a better strategy would be to, in essence, try a series of class loaders, until one succeeds, or all of them fail. The order would go something like: ResourceManager's extension class loader the thread's contextClassLoader the class loader that loaded the I18nUtil class the class loader that loaded the caller of the localizeMessage method the class loader that loaded the 2nd previous caller the class loader that loaded the 3rd previous caller etc. Of course, you would only try a class loader if it was different from one already tried. This approach allows frameworks to find and load resources they cannot see with their own class loaders, but which belong with class-loader-isolated components. Here's one article that tries to explain why this is a good idea: http://www.javaworld.com/javaworld/javaqa/2003-06/01-qa-0606-load.html Another similar approach is used by the Eclipse plugin mechanism when it is trying to find classes or resources to load that might belong to user code - sets up a ContextClassLoader to do the work of running up the chain of callers, as above, trying them to see if they can load the thing requested. See http://wiki.eclipse.org/Context_Class_Loader_Enhancements . Eclipse defines a new class loader which implements this kind of algorithm - see Java has a method which returns the set of classes on the call stack, in order: aSecurityManagerInstance.getClassContext().

          People

          • Assignee:
            Unassigned
            Reporter:
            Marshall Schor
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development