Marshall, my current fix for the Serialization problem is kinda what you
suggest. Since I can't Serialize this class I stringify it and
create a RuntimeException wrapper around it. Perhaps not ideal solution but
it is what I came up with for now.
There is at least one voice opposing this fix. The objection has to do with
being able to interpret service failures on the client side.
The client code (remote process) may need to reason over the service
failure to determine what should happen next.
The client may want to do something like this:
if ( givenDeserializedException instanceof AnalysisEngineProcessException )
{
do something
}
If the exception is stringified the above is not possible. So I think
message bundles is one issue and be able to serialize
this class is another.
Jerry
On Tue, Aug 8, 2017 at 5:58 PM, Richard Eckart de Castilho (JIRA) <
dev@uima.apache.org> wrote:
>
> [ https://issues.apache.org/jira/browse/UIMA-4793?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel&focusedCommentId=16119085#comment-16119085 ]
>
> Richard Eckart de Castilho commented on UIMA-4793:
> --------------------------------------------------
>
> > 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).
>
> That would of course assume that the source environment and the target
> environment have the same locale.
>
> > 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)
>
