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