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

2017-08-10 Thread Burn Lewis (JIRA)

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

Burn Lewis commented on UIMA-4793:
--

Perhaps the getLocalizedMessage method could save the msg when first called and 
return that on later calls.  Then we could add a writeObject method that forces 
the message to be saved and also nulls out the unserializable field before 
caller super.writeObject.  Then the message could be retrieved after 
deserializing without using the message bundle etc.  Would of course restrict 
the message to be in the service's 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

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

2017-08-09 Thread Marshall Schor (JIRA)

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

Marshall Schor commented on UIMA-4793:
--

Good point.  There are 2 factors involved in these messages:
* the message bundle - these are likely specific to each service, and it's 
somewhat likely that the client won't have access to the message bundles
* the "locale": used to select among multiple language message bundles, and 
also sets things like how numbers are formatted, etc.

The locale is often set from the machine environment the JVM is running in.  
There could be an issue if, for example, someone in Germany was running UIMA 
client connecting to a service running on a machine in Italy.  The messages 
might get translated to Italian, and sent back to the German client.

I don't think we need to provide support for this kind of scenario.
I do think we need to have remote services do their own message bundle lookups, 
because I think it somewhat likely that a service would have messages defined 
in its message bundle (specfic to that service, for example), that the client 
would not have in its message bundle.

> 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(AnalysisEngi

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

2017-08-09 Thread Burn Lewis
Can't the InternationalizedException class be made serializable?

On Tue, Aug 8, 2017 at 6:24 PM, Jaroslaw Cwiklik  wrote:

> 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
> > >  

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

2017-08-08 Thread Jaroslaw Cwiklik
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.

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

2017-08-08 Thread Richard Eckart de Castilho (JIRA)

[ 
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/br

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

2017-08-08 Thread Marshall Schor (JIRA)

[ 
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:

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

2016-08-21 Thread Richard Eckart de Castilho (JIRA)

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

Richard Eckart de Castilho commented on UIMA-4793:
--

Looks good now.

> 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
> Fix For: 2.9.0SDK
>
>
> 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.3.4#6332)


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

2016-08-19 Thread Marshall Schor (JIRA)

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

Marshall Schor commented on UIMA-4793:
--

I've committed the perhaps partial fix of capturing the original 
threadcontextclassloader when an InternationalizedException is created, and 
using it when looking up the message for a given locale.  Richard - can you run 
your test?

> 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
>
> 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.3.4#6332)


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

2016-08-19 Thread Marshall Schor (JIRA)

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

Marshall Schor commented on UIMA-4793:
--

there's a problem - the exception gets created, but only later when the message 
is requested from the exception is the "locale" information available. So, at 
exception creation time, the locale is unknown.  The same exception might be 
asked for its message in several "locales", even.

Change the solution to save at initialization time the current thread context 
class loader, not the resource bundle (which depends on the locale requested).

> 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
>
> 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



--
Th

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

2016-08-19 Thread Marshall Schor (JIRA)

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

Marshall Schor commented on UIMA-4793:
--

I figured out a (good) way to handle this I think.  At construction time, I'll 
save the current value of the thread context loader, and at message creation 
time, I'll pass that in as another loader to consider when looking for the 
bundle. 

> 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
>
> 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.3.4#6332)


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

2016-08-18 Thread Richard Eckart de Castilho (JIRA)

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

Richard Eckart de Castilho commented on UIMA-4793:
--

That would work for the case that the bundle can be obtained from the thread 
classloader. But if the bundle would have been obtained from climbing the 
callers we might still have lost access to the relevant classloader at some 
point. I see only two options: capturing all the accessible classloaders at the 
time the exception is created... or instantiating the messaged when the 
exception is created. The latter seemed simpler and thus more reasonable to me.

> 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
>
> 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.

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

2016-08-18 Thread Marshall Schor (JIRA)

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

Marshall Schor commented on UIMA-4793:
--

How about doing that message caching, only if the bundle comes from the thread 
context loader?  

> 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
>
> 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.3.4#6332)


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

2016-08-18 Thread Richard Eckart de Castilho (JIRA)

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

Richard Eckart de Castilho commented on UIMA-4793:
--

Took me a while to remember in which scenario I could try tracking this down.

I added another fallback on the Thread classloader in the 
MsgLocalizationClassLoader.getResource() method because in that particular case 
I am investigating now, the message bundle properties file fails to be located.

Unfortunately, that fixes the problem only half. There is a second part to the 
problem that I didn't see before.

I am testing in the context of a Groovy script that dynamically loads Maven 
dependencies and adds them to a context classpath.

So new fallback to the Thread classloader now fixes the internationalization of 
the exception as long as I print the exception message while I'm still within 
the context of my script (where the Thread classloader is active).

However, if I don't catch the exception in my script and instead let it 
percolate upwards, the Thread classloader gets eventually unset in a finally 
block. So when the exception finally reaches JUnit and JUnit tries to print the 
error message, the resource bundle *again* cannot be resolved.

So I would suggest that the error message should be prepared and cached 
directly in the constructor of the InternationalizedException instead of 
generating it lazily in getLocalizedMessage().

> 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
>
> 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
>   Primit

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

2016-08-17 Thread Marshall Schor (JIRA)

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

Marshall Schor commented on UIMA-4793:
--

Richard - can you test the fix I committed for InternationalizedException - 
it's making use of an already fixed lookup for bundles put into I18N class ( 
UIMA-1714 )

> 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
>
> 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.3.4#6332)