[jira] [Commented] (UIMA-346) Declaration of multiple externalResources with the same name is not reported as an error.
[ https://issues.apache.org/jira/browse/UIMA-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15569796#comment-15569796 ] Marshall Schor commented on UIMA-346: - There is a use case where multiple definitions with the same name is used for overriding, but it's not the recommended way (see the description). Given this, I'm +0 for increasing the level of the message from warning to severe. I'm -0 for adding a (by default, off) mode (via another -D parameter or via "additional parameters" mechanism, or both) for "strict descriptor checking"; I think the complexity it adds is not worth the benefit, since it will usually be off (because people won't set it). Other opinions? > Declaration of multiple externalResources with the same name is not reported > as an error. > - > > Key: UIMA-346 > URL: https://issues.apache.org/jira/browse/UIMA-346 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.3 >Reporter: Adam Lally >Priority: Minor > Labels: Resources > > A user reports that it is difficult to debug a situation where developers > have accidentally declared two resources with the same name. UIMA currently > logs a WARNING message in this case. > The severity could be increased to SEVERE. Also we could add a "strict > descriptor checking" mode (off by default) that throws an Exception in this > case, and possibly other cases. We probably shouldn't have this on by > default since it could break existing applications that currently work. > Also our documentation should say that qualified names should be used for > resources, e.g. org.myorg.myproj.myresource, to minimize the chance of > accidental name clashes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (UIMA-2903) List resources in a ResourceManager / remove hack in uimaFIT
[ https://issues.apache.org/jira/browse/UIMA-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-2903: - Description: uimaFIT currently gets a list of resources that are registered with a ResourceManager. This is handled via accessing the "mResourceMap" field of the ResourceManager_impl class via reflection. Obviously, this is not a good solution. uimaFIT iterates over the resources in the context while initializing resources that are referenced from other external resources. There may be two options: # add a listResources() method to the ResourceManager interface # get the resources that need to be initialized in some other way. I don't know if there is one, because if there was, I'd probably have used it. Looking at the @ExternalResource annotations doesn't help, because they do not give informations about the resource bindings. The bindings are only available in the ResourceManager, which takes us back to 1). Would it be possible to add a method allowing to list the resource bindings registered in a ResourceManager to the ResourceManager interface? was: uimaFIT currently gets a list of resources that are registered with a ResourceManager. This is handled via accessing the "mResourceMap" field of the ResourceManager_impl class via reflection. Obviously, this is not a good solution. uimaFIT iterates over the resources in the context while initializing resources that are referenced form other external resources. There may be two options: # add a listResources() method to the ResourceManager interface # get the resources that need to be initialized in some other way. I don't know if there is one, because if there was, I'd probably have used it. Looking at the @ExternalResource annotations doesn't help, because they do not give informations about the resource bindings. The bindings are only available in the ResourceManager, which takes us back to 1). Would it be possible to add a method allowing to list the resource bindings registered in a ResourceManager to the ResourceManager interface? > List resources in a ResourceManager / remove hack in uimaFIT > > > Key: UIMA-2903 > URL: https://issues.apache.org/jira/browse/UIMA-2903 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework, uimaFIT >Reporter: Richard Eckart de Castilho > Labels: Resources > Fix For: 2.3.0uimaFIT > > > uimaFIT currently gets a list of resources that are registered with a > ResourceManager. This is handled via accessing the "mResourceMap" field of > the ResourceManager_impl class via reflection. Obviously, this is not a good > solution. > uimaFIT iterates over the resources in the context while initializing > resources that are referenced from other external resources. > There may be two options: > # add a listResources() method to the ResourceManager interface > # get the resources that need to be initialized in some other way. I don't > know if there is one, because if there was, I'd probably have used it. > Looking at the @ExternalResource annotations doesn't help, because they do > not give informations about the resource bindings. The bindings are only > available in the ResourceManager, which takes us back to 1). > Would it be possible to add a method allowing to list the resource bindings > registered in a ResourceManager to the ResourceManager interface? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (UIMA-5086) DUCC should consider slightly larger machines when reserving a whole machine
[ https://issues.apache.org/jira/browse/UIMA-5086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Burn Lewis resolved UIMA-5086. -- Resolution: Fixed After rounding up a reserve request consider machines up to ducc.rm.reserve_overage GB larger than this. Search machines in this range, taking the smallest empty one or the one with the least investment and no fixed work. The GB overage is rounded down to a multiple of the quantum. Once a resource has been identified the request is upgraded to match the size of that resource, and on subsequent scheduling phases only resources of that size are considered. Hovering over the Memory field on ducc-mon's Reservations page will show the size of the original request. > DUCC should consider slightly larger machines when reserving a whole machine > > > Key: UIMA-5086 > URL: https://issues.apache.org/jira/browse/UIMA-5086 > Project: UIMA > Issue Type: Improvement > Components: DUCC >Reporter: Burn Lewis >Assignee: Burn Lewis >Priority: Minor > Fix For: future-DUCC > > > DUCC should consider machines up to GB bigger than requested, where > the fudge value is a site property, -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (UIMA-5086) DUCC should consider slightly larger machines when reserving a whole machine
[ https://issues.apache.org/jira/browse/UIMA-5086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Burn Lewis updated UIMA-5086: - Fix Version/s: (was: future-DUCC) 2.2.0-Ducc > DUCC should consider slightly larger machines when reserving a whole machine > > > Key: UIMA-5086 > URL: https://issues.apache.org/jira/browse/UIMA-5086 > Project: UIMA > Issue Type: Improvement > Components: DUCC >Reporter: Burn Lewis >Assignee: Burn Lewis >Priority: Minor > Fix For: 2.2.0-Ducc > > > DUCC should consider machines up to GB bigger than requested, where > the fudge value is a site property, -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (UIMA-2903) List resources in a ResourceManager / remove hack in uimaFIT
[ https://issues.apache.org/jira/browse/UIMA-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=13707741#comment-13707741 ] Marshall Schor edited comment on UIMA-2903 at 10/12/16 8:36 PM: I think that the top level abstraction that informed the current UIMA design was something like: 0) Goal: support the effective putting-together-of-parts that are independently developed, such that they run together efficiently, and are configurable. 1) UIMA has a lifecycle in which some details are resolved at "launch-time": parameters are obtained, type systems are merged, external resources are loaded. 2) Following this, there are one or more "initialize" calls done on many of the loaded things. Note that this call could be done multiple times for the same resource; see http://uima.apache.org/d/uimaj-2.4.0/tutorials_and_users_guides.html#ugr.tug.aae.contract_for_annotator_methods 3) Some motivation for external resources managed by UIMA is given here: http://uima.apache.org/d/uimaj-2.4.0/tutorials_and_users_guides.html#ugr.tug.aae.accessing_external_resource_files . I don't believe that any thought was given to scenarios where one UIMA-managed "Resource" would directly "fetch" (does this mean "load"?) another one, as this (on the surface) would seem to not fit with the motivations for this. Is this the use case behind this request? If so, it would help me understand things if some scenarios where this is wanted are described, and why the alternative of using UIMA's external resources declarations and bindings mechanism isn't used. was (Author: schor): I think that the top level abstraction that informed the current UIMA design was something like: 0) Goal: support the effective putting-together-of-parts that are independently developed, such that they run together efficiently, and are configurable. 1) UIMA has a lifecycle in which some details are resolved at "launch-time": parameters are obtained, type systems are merged, external resources are loaded. 2) Following this, there are one or more an "initialize" call done on many of the loaded things. Note that this call could be done multiple times for the same resource; see http://uima.apache.org/d/uimaj-2.4.0/tutorials_and_users_guides.html#ugr.tug.aae.contract_for_annotator_methods 3) Some motivation for external resources managed by UIMA is given here: http://uima.apache.org/d/uimaj-2.4.0/tutorials_and_users_guides.html#ugr.tug.aae.accessing_external_resource_files . I don't believe that any thought was given to scenarios where one UIMA-managed "Resource" would directly "fetch" (does this mean "load"?) another one, as this (on the surface) would seem to not fit with the motivations for this. Is this the use case behind this request? If so, it would help me understand things if some scenarios where this is wanted are described, and why the alternative of using UIMA's external resources declarations and bindings mechanism isn't used. > List resources in a ResourceManager / remove hack in uimaFIT > > > Key: UIMA-2903 > URL: https://issues.apache.org/jira/browse/UIMA-2903 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework, uimaFIT >Reporter: Richard Eckart de Castilho > Labels: Resources > Fix For: 2.3.0uimaFIT > > > uimaFIT currently gets a list of resources that are registered with a > ResourceManager. This is handled via accessing the "mResourceMap" field of > the ResourceManager_impl class via reflection. Obviously, this is not a good > solution. > uimaFIT iterates over the resources in the context while initializing > resources that are referenced from other external resources. > There may be two options: > # add a listResources() method to the ResourceManager interface > # get the resources that need to be initialized in some other way. I don't > know if there is one, because if there was, I'd probably have used it. > Looking at the @ExternalResource annotations doesn't help, because they do > not give informations about the resource bindings. The bindings are only > available in the ResourceManager, which takes us back to 1). > Would it be possible to add a method allowing to list the resource bindings > registered in a ResourceManager to the ResourceManager interface? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (UIMA-2903) List resources in a ResourceManager / remove hack in uimaFIT
[ https://issues.apache.org/jira/browse/UIMA-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15569814#comment-15569814 ] Richard Eckart de Castilho commented on UIMA-2903: -- [~schor] looks like you edited this old comment just now. Is there anything not covered by my likewise old reply below? > List resources in a ResourceManager / remove hack in uimaFIT > > > Key: UIMA-2903 > URL: https://issues.apache.org/jira/browse/UIMA-2903 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework, uimaFIT >Reporter: Richard Eckart de Castilho > Labels: Resources > Fix For: 2.3.0uimaFIT > > > uimaFIT currently gets a list of resources that are registered with a > ResourceManager. This is handled via accessing the "mResourceMap" field of > the ResourceManager_impl class via reflection. Obviously, this is not a good > solution. > uimaFIT iterates over the resources in the context while initializing > resources that are referenced from other external resources. > There may be two options: > # add a listResources() method to the ResourceManager interface > # get the resources that need to be initialized in some other way. I don't > know if there is one, because if there was, I'd probably have used it. > Looking at the @ExternalResource annotations doesn't help, because they do > not give informations about the resource bindings. The bindings are only > available in the ResourceManager, which takes us back to 1). > Would it be possible to add a method allowing to list the resource bindings > registered in a ResourceManager to the ResourceManager interface? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (UIMA-2978) CustomResourceSpecifier has no support for resource meta data
[ https://issues.apache.org/jira/browse/UIMA-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=13678518#comment-13678518 ] Marshall Schor edited comment on UIMA-2978 at 10/12/16 9:43 PM: My guess is that this is as it was designed. UIMA has various categories of ResourceSpecifiers - one of which is the "ConfigurableDataResourceSpecifier, which adds "ResourceMetaData (which includes config param settings). But there are many other kinds (e.g. FileLanguageResourceSpecifier, FileResourceSpecifier, etc.) which don't have the ResourceMetaData field. I'm not sure why this is marked as a "bug" - is it more a request for an enhancement? What is the use case(s) for this, and how important is it to get a change here into the next release (I see it is marked "major" priority?)? was (Author: schor): My guess is that this is as it was designed. UIMA has various categories of ResourceSpecifiers - one of which is the "ConfigurableDataResrouceSpecifier, which adds "ResourceMetaData (which includes config param settings). But there are many other kinds (e.g. FileLanguageResourceSpecifier, FileResourceSpecifier, etc.) which don't have the ResourceMetaData field. I'm not sure why this is marked as a "bug" - is it more a request for an enhancement? What is the use case(s) for this, and how important is it to get a change here into the next release (I see it is marked "major" priority?)? > CustomResourceSpecifier has no support for resource meta data > - > > Key: UIMA-2978 > URL: https://issues.apache.org/jira/browse/UIMA-2978 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Richard Eckart de Castilho > Labels: Resources > > The CustomResourceSpecifier provides a way of defining new custom types of > Resources (e.g. *not* DataResources) which can be acquired via the > ResourceManager. > The CustomResourceSpecifier does not support the usual ResourceMetaData, > which includes support for the typical UIMA parameter configuration. It > supports only single-valued String parameters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (UIMA-2978) CustomResourceSpecifier has no support for resource meta data
[ https://issues.apache.org/jira/browse/UIMA-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=13678526#comment-13678526 ] Marshall Schor edited comment on UIMA-2978 at 10/12/16 9:45 PM: ConfigurableDataResourceSpecifier adds the ResourceMetaData, but it also adds the DataResource. What I'd like to have (any probably the issue should be renamed accordingly) is a ConfigurableResourceSpecifier (without data). I marked it as a bug, because the Resource interface specifies a getMetaData() method, so one should be able to assume (at least I did) that this should always filled by any specifier. Also, storing the configuration settings of a resource in the meta data should probably be preferred over having a second, less expressive parameter specification mechanism. Following that train of through one should probably be able to assume that any Resource is "configurable" and that a "ConfigurableResourceSpecified" wouldn't even be required as configurability should already be provided by "ResourceSpecifier". It's not release critical, but I thinks its major enough to think seriously about it (and it's the default). If there was a "normal", I'd have marked it as that, but the next lower level is "minor", which I think doesn't do it justice either. was (Author: rec): ConfigurableDataResourceSpecifier adds the ResourceMetaData, but it also adds the DataResource. What I'd like to have (any probably the issue should be renamed accordingly) is a ConfigurableResourceSpecifier (without data). I marked it as a bug, because the Resource interface specifies a getMetaData() method, so one should be able to assume (at least I did) that this should always filled by any specifier. Also, storing the configuration settings of a resource in the meta data should probably be preferred over having a second, less expressive parameter specification mechanism. Following that train of through one should probably be able to assume that any Resource is "configurable" and that a "ConfigurableResourceSpecified" wouldn't even be required as configurability should already be provided by "ResourceSpecifier". It's not release critical, but I thinks its major enough to thing seriously about it (and it's the default). If there was a "normal", I'd have marked it as that, but the next lower level is "minor", which I think doesn't do it justice either. > CustomResourceSpecifier has no support for resource meta data > - > > Key: UIMA-2978 > URL: https://issues.apache.org/jira/browse/UIMA-2978 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Richard Eckart de Castilho > Labels: Resources > > The CustomResourceSpecifier provides a way of defining new custom types of > Resources (e.g. *not* DataResources) which can be acquired via the > ResourceManager. > The CustomResourceSpecifier does not support the usual ResourceMetaData, > which includes support for the typical UIMA parameter configuration. It > supports only single-valued String parameters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [jira] [Commented] (UIMA-2903) List resources in a ResourceManager / remove hack in uimaFIT
Hi - I'm going thru your nice summary of open issues you posted a while back: https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20labels%20%3D%20Resources and so far, just fixing some spelling things ... and trying to reclimb learning curve on these. I think I need to draw some diagrams... -M On 10/12/2016 4:40 PM, Richard Eckart de Castilho (JIRA) wrote: > [ > https://issues.apache.org/jira/browse/UIMA-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15569814#comment-15569814 > ] > > Richard Eckart de Castilho commented on UIMA-2903: > -- > > [~schor] looks like you edited this old comment just now. Is there anything > not covered by my likewise old reply below? > >> List resources in a ResourceManager / remove hack in uimaFIT >> >> >> Key: UIMA-2903 >> URL: https://issues.apache.org/jira/browse/UIMA-2903 >> Project: UIMA >> Issue Type: Improvement >> Components: Core Java Framework, uimaFIT >>Reporter: Richard Eckart de Castilho >> Labels: Resources >> Fix For: 2.3.0uimaFIT >> >> >> uimaFIT currently gets a list of resources that are registered with a >> ResourceManager. This is handled via accessing the "mResourceMap" field of >> the ResourceManager_impl class via reflection. Obviously, this is not a good >> solution. >> uimaFIT iterates over the resources in the context while initializing >> resources that are referenced from other external resources. >> There may be two options: >> # add a listResources() method to the ResourceManager interface >> # get the resources that need to be initialized in some other way. I don't >> know if there is one, because if there was, I'd probably have used it. >> Looking at the @ExternalResource annotations doesn't help, because they do >> not give informations about the resource bindings. The bindings are only >> available in the ResourceManager, which takes us back to 1). >> Would it be possible to add a method allowing to list the resource bindings >> registered in a ResourceManager to the ResourceManager interface? > > > -- > This message was sent by Atlassian JIRA > (v6.3.4#6332) >
[jira] [Resolved] (UIMA-5127) uv3 make jcas backward compatible and no longer required
[ https://issues.apache.org/jira/browse/UIMA-5127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5127. -- Resolution: Later > uv3 make jcas backward compatible and no longer required > > > Key: UIMA-5127 > URL: https://issues.apache.org/jira/browse/UIMA-5127 > Project: UIMA > Issue Type: Task > Components: Core Java Framework >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 3.0.0SDKexp > > > JCas is now mostly (if not entirely) just a trampoline to CAS and other > objects. Complete this transform. Change the uses of jcas to work when > passed the CAS instead - and deprecate jcas use. Change jcasgen to include > new constructor that just takes the cas. update all uses of jcas to use the > cas. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (UIMA-5102) auto set missing AnnotationBase sofaRef feature
[ https://issues.apache.org/jira/browse/UIMA-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5102. -- Resolution: Won't Fix It looks like it is best to leave this as an error for now, or resolve it in some other way outside of the core framework. > auto set missing AnnotationBase sofaRef feature > --- > > Key: UIMA-5102 > URL: https://issues.apache.org/jira/browse/UIMA-5102 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Affects Versions: 2.9.0SDK >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDKexp, 2.9.1SDK > > > This Jira describes a possible approach to automatically recovering from an > error condition, which might be implemented. > Sometimes, the sofa feature of a FS which is a subtype of AnnotationBase is > missing (is null) when the FS is being added to the indexes of some > particular CAS View. One way this can happen is during (lenient) > deserialization of XMI or XCAS CASes, after some update has occurred to the > type system, which changes a type from not being a subtype of AnnotationBase, > to having that as a supertype. > In this case (where the sofa reference is null), instead of throwing an > exception, set the sofa reference to the likely proper value - the sofa that > corresponds to the view it is being indexed in. If there is no sofa for that > view (unlikely but possible), throw an exception. > If this recovery is done, output a diminishing frequency log message about > it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
