[
https://issues.apache.org/jira/browse/UIMA-5054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15419557#comment-15419557
]
Richard Eckart de Castilho commented on UIMA-5054:
--------------------------------------------------
* UIMA-3692 probably yes
* UIMA-4793 imho requires that InterationalizedException doesn't use its own
classloader but a "suitable" one. My idea here was that UIMA may actually set
the thread context classloader itself (in a similar strategy as we were
discussing it recently for the thread-local UimaContextHolder) and that
InterationalizedException uses it to resolve the bundle. An alternative would
be to allow (or even require) passing a classloader as a constructor argument
to InterationalizedException. Googling for the use of the thread context
classloader, I found a few blog articles pointing out possible problematic
scenarios when thread context classloader strategies are being used in an OSGi
environment. Thus it might be advisable for UIMA itself not to manipulate the
context classloader and instead pass the component classloader to
InterationalizedException.
* I'm not sure I can follow the details of UIMA-5038 to assess its impact.
> JCas returning generic class instead of JCas cover class
> --------------------------------------------------------
>
> Key: UIMA-5054
> URL: https://issues.apache.org/jira/browse/UIMA-5054
> Project: UIMA
> Issue Type: Bug
> Components: Collection Processing
> Affects Versions: 2.8.1SDK
> Reporter: Richard Eckart de Castilho
> Fix For: 2.9.0SDK
>
>
> A DKPro Core user reported that when deploying an AE in a CPE
> he was unable to access a JCas cover class in the
> entityProcessComplete(...) CPE callback. See:
> https://groups.google.com/d/msg/dkpro-core-user/-DtO5Ivnk9I/sjQAPPv1BwAJ
> {noformat}
> public void entityProcessComplete(CAS cas, EntityProcessStatus
> status) {
> try {
> JCas jcas = cas.getJCas();
> // here getting a JCas cover class fails. Instead,
> // an AnnotationImpl is returned from the jcas.
> } catch (CASException e) {
> e.printStackTrace();
> }
> }
> {noformat}
> The problem appears to be that the static CAS classloaders are restored
> *before* invoking the entityProcessComplete() callback (CPMEngine 3468):
> {noformat}
> try {
> if (null != cas)
> ((CASImpl)cas).switchClassLoaderLockCas(statCL);
> statCL.entityProcessComplete(cas, eps);
> } finally {
> if (null != cas)
> ((CASImpl)cas).restoreClassLoaderUnlockCas();
> }
> {noformat}
> Is there any reason that the classloaders are switched out before invoking
> the callback? If not, any objection if I change the code such that the
> callback is invoked before the classloaders are switched out?
> {noformat}
> Thread [[Procesing Pipeline#7 Thread]::] (Suspended (breakpoint at line 1021
> in CASImpl))
> CASImpl.setLocalFsGenerators(FSGenerator<FeatureStructure>[]) line:
> 1021
> FSClassRegistry.swapInGeneratorsForClassLoader(ClassLoader, CASImpl)
> line: 225
> JCasImpl.switchClassLoader(ClassLoader) line: 548
> CASImpl.switchClassLoader(ClassLoader) line: 4195
> CASImpl.switchClassLoaderLockCasCL(ClassLoader) line: 4183
> CASImpl.switchClassLoaderLockCas(Object) line: 4176
> CPMEngine.callEntityProcessCompleteWithCAS(StatusCallbackListener, CAS,
> EntityProcessStatus) line: 3472
> ProcessingUnit.doNotifyListeners(Object, boolean, EntityProcessStatus)
> line: 1650
> ProcessingUnit.notifyListeners(Object, boolean, EntityProcessStatus)
> line: 1592
> ProcessingUnit.processNext(Object[], ProcessTrace) line: 917
> ProcessingUnit.run() line: 575
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
