[jira] [Commented] (UIMA-6214) Method signature class in ExternalResourceFactory
[
https://issues.apache.org/jira/browse/UIMA-6214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17075268#comment-17075268
]
Mario Juric commented on UIMA-6214:
---
I agree that the best in this case is to rename the methods despite loss of
backward compatibility, but the name change will also help distinguish between
what those different methods do, since they are not just overloads for the same
thing.
> Method signature class in ExternalResourceFactory
> -
>
> Key: UIMA-6214
> URL: https://issues.apache.org/jira/browse/UIMA-6214
> Project: UIMA
> Issue Type: Bug
> Components: uimaFIT
>Affects Versions: 3.0.0uimaFIT
>Reporter: Richard Eckart de Castilho
>Assignee: Richard Eckart de Castilho
>Priority: Major
> Fix For: 3.1.0uimaFIT
>
>
> The renaming of methods in the ExternalResourceFactory between uimaFIT v2 and
> v3 was designed to remove ambiguities between the method signatures. However,
> it has introduced a new set of ambiguities...
> There are a few methods meant do bind a resource to one particular thing
> (resource manager, component, other resource)
> * {{void bindResource(ResourceCreationSpecifier aDesc, String aBindTo,
> ExternalResourceDescription aRes)}}
> * {{void bindResource(ResourceCreationSpecifier aDesc, String aBindTo, String
> aRes)}}
> * {{void bindResource(ResourceManagerConfiguration aResMgrCfg, String
> aBindTo, String aRes)}}
> * {{void bindResource(ExternalResourceDescription aRes, String aBindTo,
> ExternalResourceDescription aNestedRes)}}
> * {{void bindResource(ResourceManagerConfiguration aResMgrCfg, String
> aBindTo, ExternalResourceDescription aRes)}}
> Then, there is another bunch of methods meant to scan objects recursively and
> bind resources wherever applicable:
> * {{void bindResource(ResourceSpecifier aDesc, String aKey,
> ExternalResourceDescription aResDesc)}}
> * {{void bindResource(ResourceSpecifier aDesc, String aKey, String aUrl)}}
> * {{void bindResource(ResourceSpecifier aDesc, Class
> aRes, String... aParams)}}
> * {{void bindResource(ResourceSpecifier aDesc, Class aApi, Class Resource> aRes, String... aParams)}}
> * {{void bindResource(ResourceSpecifier aDesc, ExternalResourceDescription
> aResDesc)}}
> * {{void bindResource(ResourceSpecifier aDesc, String aKey, Class Resource> aRes, String... aParams)}}
> * {{void bindResource(ResourceSpecifier aDesc, String aKey, File aFile)}}
> * {{void bindResource(ResourceSpecifier aDesc, String aKey, URL aUrl)}}
> * {{void bindResourceUsingUrl(ResourceSpecifier aDesc, Class SharedResourceObject> aRes, String aUrl, Object... aParams)}}
> * {{void bindResourceUsingUrl(ResourceSpecifier aDesc, Class aApi, Class extends SharedResourceObject> aRes, String aUrl, Object... aParams)}}
> * {{void bindResourceUsingUrl(ResourceSpecifier aDesc, String aKey, Class extends SharedResourceObject> aRes, String aUrl, Object... aParams)}}
> There is in particular a conflict between these pairs because
> {{ResourceCreationSpecifier}} is a subclass of {{ResourceSpecifier}}
> *Pair 1*
> * bind specifically: {{void bindResource(ResourceCreationSpecifier aDesc,
> String aBindTo, ExternalResourceDescription aRes)}}
> * scan recursively: {{void bindResource(ResourceSpecifier aDesc, String aKey,
> ExternalResourceDescription aResDesc)}}
> *Pair 2*
> * bind specifically: {{void bindResource(ResourceCreationSpecifier aDesc,
> String aBindTo, String aRes)}}
> * scan recursively: {{void bindResource(ResourceSpecifier aDesc, String aKey,
> String aUrl)}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (UIMA-6214) Method signature class in ExternalResourceFactory
[
https://issues.apache.org/jira/browse/UIMA-6214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17075210#comment-17075210
]
Richard Eckart de Castilho commented on UIMA-6214:
--
I'm considering to solve this by renaming once more the methods which bind
explicitly to one thingy from {{bindResource}} to {{bindResourceOnce}} (or
something along the lines:
* {{void bindResourceOnce(ResourceCreationSpecifier aDesc, String aBindTo,
ExternalResourceDescription aRes)}}
* {{void bindResourceOnce(ResourceCreationSpecifier aDesc, String aBindTo,
String aRes)}}
* {{void bindResourceOnce(ResourceManagerConfiguration aResMgrCfg, String
aBindTo, String aRes)}} (also keep name/signature as deprecated)
* {{void bindResourceOnce(ExternalResourceDescription aRes, String aBindTo,
ExternalResourceDescription aNestedRes)}} (also keep name/signature as
deprecated)
* {{void bindResourceOnce(ResourceManagerConfiguration aResMgrCfg, String
aBindTo, ExternalResourceDescription aRes)}} (also keep name/signature as
deprecated)
For the two methods that really clash, I'm planning on not keeping the current
name/signatures - only the renamed ones.
For the other three methods that do not clash, I'm considering to keep the
current names/signatures in addition to the renamed ones but to deprecate them.
> Method signature class in ExternalResourceFactory
> -
>
> Key: UIMA-6214
> URL: https://issues.apache.org/jira/browse/UIMA-6214
> Project: UIMA
> Issue Type: Bug
> Components: uimaFIT
>Affects Versions: 3.0.0uimaFIT
>Reporter: Richard Eckart de Castilho
>Assignee: Richard Eckart de Castilho
>Priority: Major
> Fix For: 3.1.0uimaFIT
>
>
> The renaming of methods in the ExternalResourceFactory between uimaFIT v2 and
> v3 was designed to remove ambiguities between the method signatures. However,
> it has introduced a new set of ambiguities...
> There are a few methods meant do bind a resource to one particular thing
> (resource manager, component, other resource)
> * {{void bindResource(ResourceCreationSpecifier aDesc, String aBindTo,
> ExternalResourceDescription aRes)}}
> * {{void bindResource(ResourceCreationSpecifier aDesc, String aBindTo, String
> aRes)}}
> * {{void bindResource(ResourceManagerConfiguration aResMgrCfg, String
> aBindTo, String aRes)}}
> * {{void bindResource(ExternalResourceDescription aRes, String aBindTo,
> ExternalResourceDescription aNestedRes)}}
> * {{void bindResource(ResourceManagerConfiguration aResMgrCfg, String
> aBindTo, ExternalResourceDescription aRes)}}
> Then, there is another bunch of methods meant to scan objects recursively and
> bind resources wherever applicable:
> * {{void bindResource(ResourceSpecifier aDesc, String aKey,
> ExternalResourceDescription aResDesc)}}
> * {{void bindResource(ResourceSpecifier aDesc, String aKey, String aUrl)}}
> * {{void bindResource(ResourceSpecifier aDesc, Class
> aRes, String... aParams)}}
> * {{void bindResource(ResourceSpecifier aDesc, Class aApi, Class Resource> aRes, String... aParams)}}
> * {{void bindResource(ResourceSpecifier aDesc, ExternalResourceDescription
> aResDesc)}}
> * {{void bindResource(ResourceSpecifier aDesc, String aKey, Class Resource> aRes, String... aParams)}}
> * {{void bindResource(ResourceSpecifier aDesc, String aKey, File aFile)}}
> * {{void bindResource(ResourceSpecifier aDesc, String aKey, URL aUrl)}}
> * {{void bindResourceUsingUrl(ResourceSpecifier aDesc, Class SharedResourceObject> aRes, String aUrl, Object... aParams)}}
> * {{void bindResourceUsingUrl(ResourceSpecifier aDesc, Class aApi, Class extends SharedResourceObject> aRes, String aUrl, Object... aParams)}}
> * {{void bindResourceUsingUrl(ResourceSpecifier aDesc, String aKey, Class extends SharedResourceObject> aRes, String aUrl, Object... aParams)}}
> There is in particular a conflict between these pairs because
> {{ResourceCreationSpecifier}} is a subclass of {{ResourceSpecifier}}
> *Pair 1*
> * bind specifically: {{void bindResource(ResourceCreationSpecifier aDesc,
> String aBindTo, ExternalResourceDescription aRes)}}
> * scan recursively: {{void bindResource(ResourceSpecifier aDesc, String aKey,
> ExternalResourceDescription aResDesc)}}
> *Pair 2*
> * bind specifically: {{void bindResource(ResourceCreationSpecifier aDesc,
> String aBindTo, String aRes)}}
> * scan recursively: {{void bindResource(ResourceSpecifier aDesc, String aKey,
> String aUrl)}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (UIMA-6214) Method signature class in ExternalResourceFactory
[
https://issues.apache.org/jira/browse/UIMA-6214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Eckart de Castilho updated UIMA-6214:
-
Description:
The renaming of methods in the ExternalResourceFactory between uimaFIT v2 and
v3 was designed to remove ambiguities between the method signatures. However,
it has introduced a new set of ambiguities...
There are a few methods meant do bind a resource to one particular thing
(resource manager, component, other resource)
* {{void bindResource(ResourceCreationSpecifier aDesc, String aBindTo,
ExternalResourceDescription aRes)}}
* {{void bindResource(ResourceCreationSpecifier aDesc, String aBindTo, String
aRes)}}
* {{void bindResource(ResourceManagerConfiguration aResMgrCfg, String aBindTo,
String aRes)}}
* {{void bindResource(ExternalResourceDescription aRes, String aBindTo,
ExternalResourceDescription aNestedRes)}}
* {{void bindResource(ResourceManagerConfiguration aResMgrCfg, String aBindTo,
ExternalResourceDescription aRes)}}
Then, there is another bunch of methods meant to scan objects recursively and
bind resources wherever applicable:
* {{void bindResource(ResourceSpecifier aDesc, String aKey,
ExternalResourceDescription aResDesc)}}
* {{void bindResource(ResourceSpecifier aDesc, String aKey, String aUrl)}}
* {{void bindResource(ResourceSpecifier aDesc, Class aRes,
String... aParams)}}
* {{void bindResource(ResourceSpecifier aDesc, Class aApi, Class aRes, String... aParams)}}
* {{void bindResource(ResourceSpecifier aDesc, ExternalResourceDescription
aResDesc)}}
* {{void bindResource(ResourceSpecifier aDesc, String aKey, Class aRes, String... aParams)}}
* {{void bindResource(ResourceSpecifier aDesc, String aKey, File aFile)}}
* {{void bindResource(ResourceSpecifier aDesc, String aKey, URL aUrl)}}
* {{void bindResourceUsingUrl(ResourceSpecifier aDesc, Class aRes, String aUrl, Object... aParams)}}
* {{void bindResourceUsingUrl(ResourceSpecifier aDesc, Class aApi, Class aRes, String aUrl, Object... aParams)}}
* {{void bindResourceUsingUrl(ResourceSpecifier aDesc, String aKey, Class aRes, String aUrl, Object... aParams)}}
There is in particular a conflict between these pairs because
{{ResourceCreationSpecifier}} is a subclass of {{ResourceSpecifier}}
*Pair 1*
* bind specifically: {{void bindResource(ResourceCreationSpecifier aDesc,
String aBindTo, ExternalResourceDescription aRes)}}
* scan recursively: {{void bindResource(ResourceSpecifier aDesc, String aKey,
ExternalResourceDescription aResDesc)}}
*Pair 2*
* bind specifically: {{void bindResource(ResourceCreationSpecifier aDesc,
String aBindTo, String aRes)}}
* scan recursively: {{void bindResource(ResourceSpecifier aDesc, String aKey,
String aUrl)}}
was:
The renaming of methods in the ExternalResourceFactory between uimaFIT v2 and
v3 was designed to remove ambiguities between the method signatures. However,
it has introduced a new set of ambiguities...
There are a few methods meant do bind a resource to one particular thing
(resource manager, component, other resource)
* {{void bindResource(ResourceCreationSpecifier aDesc, String aBindTo,
ExternalResourceDescription aRes)}}
* {{void bindResource(ResourceManagerConfiguration aResMgrCfg, String aBindTo,
String aRes)}}
* {{void bindResource(ResourceCreationSpecifier aDesc, String aBindTo, String
aRes)}}
* {{void bindResource(ExternalResourceDescription aRes, String aBindTo,
ExternalResourceDescription aNestedRes)}}
* {{void bindResource(ResourceManagerConfiguration aResMgrCfg, String aBindTo,
ExternalResourceDescription aRes)}}
Then, there is another bunch of methods meant to scan objects recursively and
bind resources wherever applicable:
* {{void bindResource(ResourceSpecifier aDesc, Class aRes,
String... aParams)}}
* {{void bindResource(ResourceSpecifier aDesc, Class aApi, Class aRes, String... aParams)}}
* {{void bindResource(ResourceSpecifier aDesc, ExternalResourceDescription
aResDesc)}}
* {{void bindResource(ResourceSpecifier aDesc, String aKey, Class aRes, String... aParams)}}
* {{void bindResource(ResourceSpecifier aDesc, String aKey,
ExternalResourceDescription aResDesc)}}
* {{void bindResource(ResourceSpecifier aDesc, String aKey, File aFile)}}
* {{void bindResource(ResourceSpecifier aDesc, String aKey, String aUrl)}}
* {{void bindResource(ResourceSpecifier aDesc, String aKey, URL aUrl)}}
* {{void bindResourceUsingUrl(ResourceSpecifier aDesc, Class aRes, String aUrl, Object... aParams)}}
* {{void bindResourceUsingUrl(ResourceSpecifier aDesc, Class aApi, Class aRes, String aUrl, Object... aParams)}}
* {{void bindResourceUsingUrl(ResourceSpecifier aDesc, String aKey, Class aRes, String aUrl, Object... aParams)}}
*
> Method signature class in ExternalResourceFactory
> -
>
> Key: UIMA-6214
> URL: https://issues.apache.org/jira/browse/UIMA-6214
>
[jira] [Created] (UIMA-6214) Method signature class in ExternalResourceFactory
Richard Eckart de Castilho created UIMA-6214:
Summary: Method signature class in ExternalResourceFactory
Key: UIMA-6214
URL: https://issues.apache.org/jira/browse/UIMA-6214
Project: UIMA
Issue Type: Bug
Components: uimaFIT
Affects Versions: 3.0.0uimaFIT
Reporter: Richard Eckart de Castilho
Assignee: Richard Eckart de Castilho
Fix For: 3.1.0uimaFIT
The renaming of methods in the ExternalResourceFactory between uimaFIT v2 and
v3 was designed to remove ambiguities between the method signatures. However,
it has introduced a new set of ambiguities...
There are a few methods meant do bind a resource to one particular thing
(resource manager, component, other resource)
* {{void bindResource(ResourceCreationSpecifier aDesc, String aBindTo,
ExternalResourceDescription aRes)}}
* {{void bindResource(ResourceManagerConfiguration aResMgrCfg, String aBindTo,
String aRes)}}
* {{void bindResource(ResourceCreationSpecifier aDesc, String aBindTo, String
aRes)}}
* {{void bindResource(ExternalResourceDescription aRes, String aBindTo,
ExternalResourceDescription aNestedRes)}}
* {{void bindResource(ResourceManagerConfiguration aResMgrCfg, String aBindTo,
ExternalResourceDescription aRes)}}
Then, there is another bunch of methods meant to scan objects recursively and
bind resources wherever applicable:
* {{void bindResource(ResourceSpecifier aDesc, Class aRes,
String... aParams)}}
* {{void bindResource(ResourceSpecifier aDesc, Class aApi, Class aRes, String... aParams)}}
* {{void bindResource(ResourceSpecifier aDesc, ExternalResourceDescription
aResDesc)}}
* {{void bindResource(ResourceSpecifier aDesc, String aKey, Class aRes, String... aParams)}}
* {{void bindResource(ResourceSpecifier aDesc, String aKey,
ExternalResourceDescription aResDesc)}}
* {{void bindResource(ResourceSpecifier aDesc, String aKey, File aFile)}}
* {{void bindResource(ResourceSpecifier aDesc, String aKey, String aUrl)}}
* {{void bindResource(ResourceSpecifier aDesc, String aKey, URL aUrl)}}
* {{void bindResourceUsingUrl(ResourceSpecifier aDesc, Class aRes, String aUrl, Object... aParams)}}
* {{void bindResourceUsingUrl(ResourceSpecifier aDesc, Class aApi, Class aRes, String aUrl, Object... aParams)}}
* {{void bindResourceUsingUrl(ResourceSpecifier aDesc, String aKey, Class aRes, String aUrl, Object... aParams)}}
*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [VOTE] Release UIMA Ruta 2.8.1 RC1
Searching this error gives one possibly interesting hit: https://bugs.eclipse.org/bugs/show_bug.cgi?format=multiple=532490 with a work-around of making the launching JDK and the runtime JDK the same? -M On 4/3/2020 5:04 AM, Richard Eckart de Castilho wrote: > - compared SVN tag against source release (using Meld btw) - ok > - CLI build (Java 13.0.1) - ok > - Installing after installing UIMA plugins first - OK > - Importing example projects as "Existing projects" (not Maven) - OK (Imports > three projects) > - Run ExampleProject/script/uima/ruta/example/Main.ruta - FAILED - I just get > this message: > > Error occurred during initialization of boot layer: > java.lang.LayerInstantiationException: Package jdk.internal.jimage in both > module jrt.fs and java.base (Eclipse running on OpenJDK 13) > > Is this a known/expected problem? > > Cheers, > > -- Richard > > > Other issues: > - URL given in the announcement incorrect - correct is > https://dist.apache.org/repos/dist/dev/uima/ruta/ruta-2.8.1-rc1/eclipse-update-site/ruta >
[jira] [Commented] (UIMA-6200) Constructing aggregate engines is slow
[
https://issues.apache.org/jira/browse/UIMA-6200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17075177#comment-17075177
]
Richard Eckart de Castilho commented on UIMA-6200:
--
None that I know of.
> Constructing aggregate engines is slow
> --
>
> Key: UIMA-6200
> URL: https://issues.apache.org/jira/browse/UIMA-6200
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
>Reporter: Richard Eckart de Castilho
>Priority: Minor
> Fix For: 2.10.5SDK
>
> Attachments: Screenshot 2020-03-15 at 18.52.48.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Creating an aggregate engine is slow because every time a default fixed flow
> descriptor is loaded from the classpath as XML and parsed.
> *FixedFlowController*
> {code}
> public static FlowControllerDescription getDescription() {
> URL descUrl = FixedFlowController.class
> .getResource("/org/apache/uima/flow/FixedFlowController.xml");
> FlowControllerDescription desc;
> try {
> desc = (FlowControllerDescription) UIMAFramework.getXMLParser().parse(
> new XMLInputSource(descUrl));
> } catch (InvalidXMLException e) {
> throw new UIMARuntimeException(e);
> } catch (IOException e) {
> throw new UIMARuntimeException(e);
> }
> return desc;
> }
> {code}
> IMHO, this should be loaded once and then cached permanently - or be
> constructed completely programmatically (also once!) and never loaded at all.
> !Screenshot 2020-03-15 at 18.52.48.png!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (UIMA-6200) Constructing aggregate engines is slow
[
https://issues.apache.org/jira/browse/UIMA-6200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17075173#comment-17075173
]
Marshall Schor commented on UIMA-6200:
--
No reason not to apply this same change to uima v3, correct?
> Constructing aggregate engines is slow
> --
>
> Key: UIMA-6200
> URL: https://issues.apache.org/jira/browse/UIMA-6200
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
>Reporter: Richard Eckart de Castilho
>Priority: Minor
> Fix For: 2.10.5SDK
>
> Attachments: Screenshot 2020-03-15 at 18.52.48.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Creating an aggregate engine is slow because every time a default fixed flow
> descriptor is loaded from the classpath as XML and parsed.
> *FixedFlowController*
> {code}
> public static FlowControllerDescription getDescription() {
> URL descUrl = FixedFlowController.class
> .getResource("/org/apache/uima/flow/FixedFlowController.xml");
> FlowControllerDescription desc;
> try {
> desc = (FlowControllerDescription) UIMAFramework.getXMLParser().parse(
> new XMLInputSource(descUrl));
> } catch (InvalidXMLException e) {
> throw new UIMARuntimeException(e);
> } catch (IOException e) {
> throw new UIMARuntimeException(e);
> }
> return desc;
> }
> {code}
> IMHO, this should be loaded once and then cached permanently - or be
> constructed completely programmatically (also once!) and never loaded at all.
> !Screenshot 2020-03-15 at 18.52.48.png!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
