[
https://issues.apache.org/jira/browse/UIMA-5156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15602279#comment-15602279
]
Marshall Schor commented on UIMA-5156:
--------------------------------------
It was pointed out that no existing code calls destroy() on RM, so backwards
compatibility might not be an issue.
It does however, seem that implementing any kind of automatic destroy() call
has the potential to break user code, for the case
where the user used the "automatic" creation of an RM, followed by then getting
that RM and passing it (in additionalParameters) to other produceResource calls.
I can't figure out a way to detect if this is happening. The test would need
to be something like: is this Resource manager "held" by some other Java
object?
Putting in this would "break" those kinds of applications. I wonder if the
benefit of this is worth the troubles it may cause to users?
Not putting this in would leave the requirement of calling destroy() to those
users for whom it was important; and they would have the extra burden of
calling it in the case where the UIMA Framework "automatically" created the RM.
> ResourceManager automatic destory
> ---------------------------------
>
> Key: UIMA-5156
> URL: https://issues.apache.org/jira/browse/UIMA-5156
> Project: UIMA
> Issue Type: Improvement
> Reporter: Marshall Schor
> Priority: Minor
>
> UIMA-2977 adds a destory() method to the ResourceManager (RM), that forwards
> this call to external resources managed by that RM.
> The destroy() method was not called by the framework, because in general the
> RM may be shared by the user (or framework) among multiple pipelines.
> This Jira is to enable RMs created by the framework to call destroy()
> internally at the appropriate time.
> This assumes that the right time can be figured out for the various cases.
> These include: MultiprocessingAnalysisEngine_impl, and fixing other
> associated frameworks which may use a pattern where they
> * let the framework create a RM, but then
> * use that in other contexts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
