[jira] [Commented] (UIMA-4793) Unable to localize exceptions when using alternative classloader

["Marshall Schor (JIRA)" <de...@uima.apache.org>]

    [ https://issues.apache.org/jira/browse/UIMA-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16119056#comment-16119056 ] 

Marshall Schor commented on UIMA-4793:
--------------------------------------

To fix this, we need to understand the desired behavior for serialization of exceptions like this.

The first principle 
* the exception is using message bundles,
** an indirection between the message-id and the actual message

Now, when you have one of these exceptions, and you want to serialize it, whose message bundle should it be looked up in?
For DUCC, it would seem that the environment (service) creating the exception probably needs to resolve the message bundle lookup in that same environment.
* Example: imagine you have a DUCC service, that creates an exception with a message bundle key "my-special-service-key".  Serializing that back to a client as the raw (unresolved) exception, would require that the client have a message bundle that defined "my-special-service-key".  

A better design, it seems to me, is to convert messages that need to be serialized to another environment to a form that doesn't use a message bundle (the message bundle lookup already having been performed in the serializing environment).

WDYT?

> Unable to localize exceptions when using alternative classloader
> ----------------------------------------------------------------
>
>                 Key: UIMA-4793
>                 URL: https://issues.apache.org/jira/browse/UIMA-4793
>             Project: UIMA
>          Issue Type: Bug
>          Components: Core Java Framework
>    Affects Versions: 2.8.1SDK
>            Reporter: Richard Eckart de Castilho
>            Assignee: Marshall Schor
>             Fix For: 2.9.0SDK, 3.0.0SDK-alpha
>
>
> If a component is initialized through a resource manager with a custom classloader, then it may not have access to its localized exception message bundles.
> The reason is, that within the classloader chain, the CL which knows about the Core UIMA framework is at a higher level than the CL used by the resource manager that created the component. The component CL would have access to the message bundle, but InterationalizedException uses it's own classloader (the higher level one that knows about Core UIMA) to load message bundles:
> {noformat}
> // locate the resource bundle for this exception's messages
>          // turn over the classloader of the current object explicitly, so that the
>          // message resolving also works for derived exception classes
>          ResourceBundle bundle = ResourceBundle.getBundle(
>                getResourceBundleName(), aLocale, this.getClass()
>                      .getClassLoader());
> {noformat}
> {noformat}
> Thread [main] (Suspended (exception MissingResourceException))	
> 	owns: PrintWriter  (id=92)	
> 	owns: ThrowableInformation  (id=93)	
> 	owns: ConsoleAppender  (id=94)	
> 	owns: RootLogger  (id=95)	
> 	ResourceBundle.throwMissingResourceException(String, Locale, Throwable) line: 1564	
> 	ResourceBundle.getBundleImpl(String, Locale, ClassLoader, ResourceBundle$Control) line: 1387	
> 	ResourceBundle.getBundle(String, Locale, ClassLoader) line: 1082	
> 	AnalysisEngineProcessException(InternationalizedException).getLocalizedMessage(Locale) line: 240	
> 	AnalysisEngineProcessException(InternationalizedException).getLocalizedMessage() line: 218	
> 	AnalysisEngineProcessException(Throwable).toString() line: 480	
> 	String.valueOf(Object) line: 2994	
> 	PrintWriter.println(Object) line: 754	
> 	Throwable$WrappedPrintWriter.println(Object) line: 764	
> 	AnalysisEngineProcessException(Throwable).printStackTrace(Throwable$PrintStreamOrWriter) line: 655	
> 	AnalysisEngineProcessException(Throwable).printStackTrace(PrintWriter) line: 721	
> 	DefaultThrowableRenderer.render(Throwable) line: 60	
> 	ThrowableInformation.getThrowableStrRep() line: 87	
> 	LoggingEvent.getThrowableStrRep() line: 413	
> 	ConsoleAppender(WriterAppender).subAppend(LoggingEvent) line: 313	
> 	ConsoleAppender(WriterAppender).append(LoggingEvent) line: 162	
> 	ConsoleAppender(AppenderSkeleton).doAppend(LoggingEvent) line: 251	
> 	AppenderAttachableImpl.appendLoopOnAppenders(LoggingEvent) line: 66	
> 	Logger(Category).callAppenders(LoggingEvent) line: 206	
> 	Logger(Category).forcedLog(String, Priority, Object, Throwable) line: 391	
> 	Logger(Category).log(String, Priority, Object, Throwable) line: 856	
> 	Log4jLogger_impl.log(Level, String, Throwable) line: 272	
> 	PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(CAS) line: 417	
> 	PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(CAS) line: 308	
> 	PrimitiveAnalysisEngine_impl(AnalysisEngineImplBase).process(CAS) line: 269	
> 	PrimitiveAnalysisEngine_impl(AnalysisEngineImplBase).process(JCas) line: 284	
> 	AnalysisEngine$process.call(Object, Object) line: not available	
> ...
> {noformat}
> The IMHO best way would be if UIMA would at try here to use the thread's context classloader - and maybe that UIMA actually sets the thread context classloader to the resource manager CL while running components... in my case, I already do that outside UIMA atm, so searching the thread CL would be sufficient for me atm.
> See also: https://issues.apache.org/jira/browse/UIMA-3692



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)