[jira] [Commented] (UIMA-5961) InternationalizedException getLocalizedMessage fails in pear
[ https://issues.apache.org/jira/browse/UIMA-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866771#comment-16866771 ] Marshall Schor commented on UIMA-5961: -- It seems to run fine. it randomly says either an init or process error, the init says This is an error of init, 'ARGUMENTLALALALA', and the process one says This is an error of process, 'ARGUMENTLOLOLOLO'. What should I do to show the problem? > InternationalizedException getLocalizedMessage fails in pear > > > Key: UIMA-5961 > URL: https://issues.apache.org/jira/browse/UIMA-5961 > Project: UIMA > Issue Type: Bug >Affects Versions: 2.10.3SDK >Reporter: Matthias Koch >Assignee: Marshall Schor >Priority: Major > Fix For: 2.10.4SDK > > Attachments: UIMA-5961.diff, kochomat.zip, > pearWithInterWithKeyHappy.pear, stackTrace.txt, stacktraceOfKochomat.png > > > localized message does not work in the case of pears. The classloader stored > in the internationalizedException is wrong. The bundle cant be found in this > classloader. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (UIMA-5961) InternationalizedException getLocalizedMessage fails in pear
[ https://issues.apache.org/jira/browse/UIMA-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866671#comment-16866671 ] Marshall Schor edited comment on UIMA-5961 at 6/18/19 3:34 PM: --- -do you have a small Eclipse test project that launches the pear and gets the error?\- Nevermind - I used the latest zip to create a maven project, packaged it, and then used the created PEAR in as the input to the INSTALL PEAR launcher. was (Author: schor): do you have a small Eclipse test project that launches the pear and gets the error? > InternationalizedException getLocalizedMessage fails in pear > > > Key: UIMA-5961 > URL: https://issues.apache.org/jira/browse/UIMA-5961 > Project: UIMA > Issue Type: Bug >Affects Versions: 2.10.3SDK >Reporter: Matthias Koch >Assignee: Marshall Schor >Priority: Major > Fix For: 2.10.4SDK > > Attachments: UIMA-5961.diff, kochomat.zip, > pearWithInterWithKeyHappy.pear, stackTrace.txt, stacktraceOfKochomat.png > > > localized message does not work in the case of pears. The classloader stored > in the internationalizedException is wrong. The bundle cant be found in this > classloader. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-5961) InternationalizedException getLocalizedMessage fails in pear
[ https://issues.apache.org/jira/browse/UIMA-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866671#comment-16866671 ] Marshall Schor commented on UIMA-5961: -- do you have a small Eclipse test project that launches the pear and gets the error? > InternationalizedException getLocalizedMessage fails in pear > > > Key: UIMA-5961 > URL: https://issues.apache.org/jira/browse/UIMA-5961 > Project: UIMA > Issue Type: Bug >Affects Versions: 2.10.3SDK >Reporter: Matthias Koch >Assignee: Marshall Schor >Priority: Major > Fix For: 2.10.4SDK > > Attachments: UIMA-5961.diff, kochomat.zip, > pearWithInterWithKeyHappy.pear, stackTrace.txt, stacktraceOfKochomat.png > > > localized message does not work in the case of pears. The classloader stored > in the internationalizedException is wrong. The bundle cant be found in this > classloader. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (UIMA-5961) InternationalizedException getLocalizedMessage fails in pear
[ https://issues.apache.org/jira/browse/UIMA-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866624#comment-16866624 ] Marshall Schor edited comment on UIMA-5961 at 6/18/19 2:46 PM: --- -did you see my previous comment - it looks like you're using the wrong constructor for ResourceInitializationException- I see in your latest zip you did change the constructor call to include a message bundle arg. I'll take a look was (Author: schor): did you see my previous comment - it looks like you're using the wrong constructor for ResourceInitializationException > InternationalizedException getLocalizedMessage fails in pear > > > Key: UIMA-5961 > URL: https://issues.apache.org/jira/browse/UIMA-5961 > Project: UIMA > Issue Type: Bug >Affects Versions: 2.10.3SDK >Reporter: Matthias Koch >Assignee: Marshall Schor >Priority: Major > Fix For: 2.10.4SDK > > Attachments: UIMA-5961.diff, kochomat.zip, > pearWithInterWithKeyHappy.pear, stackTrace.txt, stacktraceOfKochomat.png > > > localized message does not work in the case of pears. The classloader stored > in the internationalizedException is wrong. The bundle cant be found in this > classloader. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-5961) InternationalizedException getLocalizedMessage fails in pear
[ https://issues.apache.org/jira/browse/UIMA-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866624#comment-16866624 ] Marshall Schor commented on UIMA-5961: -- did you see my previous comment - it looks like you're using the wrong constructor for ResourceInitializationException > InternationalizedException getLocalizedMessage fails in pear > > > Key: UIMA-5961 > URL: https://issues.apache.org/jira/browse/UIMA-5961 > Project: UIMA > Issue Type: Bug >Affects Versions: 2.10.3SDK >Reporter: Matthias Koch >Assignee: Marshall Schor >Priority: Major > Fix For: 2.10.4SDK > > Attachments: UIMA-5961.diff, kochomat.zip, > pearWithInterWithKeyHappy.pear, stackTrace.txt, stacktraceOfKochomat.png > > > localized message does not work in the case of pears. The classloader stored > in the internationalizedException is wrong. The bundle cant be found in this > classloader. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-5961) InternationalizedException getLocalizedMessage fails in pear
[ https://issues.apache.org/jira/browse/UIMA-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866018#comment-16866018 ] Marshall Schor commented on UIMA-5961: -- I looked at the pear, and see it has the bit of code that throws an exception with a resource key name of "INIT_KEY". ResourceInitializationException has several constructors. The one used in this code is the one that uses the message digest "org.apache.uima.UIMAException_Messages" (the so-called standard-message-catelog). Did you mean to use one where you specified a particular message catalog, say, for example the one in the Jar named pear_de.properties? See the docs for this here: [http://uima.apache.org/d/uimaj-current/tutorials_and_users_guides.html#ugr.tug.aae.throwing_exceptions_from_annotators] > InternationalizedException getLocalizedMessage fails in pear > > > Key: UIMA-5961 > URL: https://issues.apache.org/jira/browse/UIMA-5961 > Project: UIMA > Issue Type: Bug >Affects Versions: 2.10.3SDK >Reporter: Matthias Koch >Assignee: Marshall Schor >Priority: Major > Fix For: 2.10.4SDK > > Attachments: UIMA-5961.diff, pearWithInterWithKeyHappy.pear, > stackTrace.txt > > > localized message does not work in the case of pears. The classloader stored > in the internationalizedException is wrong. The bundle cant be found in this > classloader. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-5961) InternationalizedException getLocalizedMessage fails in pear
[ https://issues.apache.org/jira/browse/UIMA-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865915#comment-16865915 ] Marshall Schor commented on UIMA-5961: -- Thanks. Can you post simple instructions for how to run this? > InternationalizedException getLocalizedMessage fails in pear > > > Key: UIMA-5961 > URL: https://issues.apache.org/jira/browse/UIMA-5961 > Project: UIMA > Issue Type: Bug >Affects Versions: 2.10.3SDK >Reporter: Matthias Koch >Assignee: Marshall Schor >Priority: Major > Fix For: 2.10.4SDK > > Attachments: UIMA-5961.diff, pearWithInterWithKeyHappy.pear, > stackTrace.txt > > > localized message does not work in the case of pears. The classloader stored > in the internationalizedException is wrong. The bundle cant be found in this > classloader. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-6064) External DTD usage in XML descriptors disabled during build revision upgrade
[ https://issues.apache.org/jira/browse/UIMA-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865896#comment-16865896 ] Marshall Schor commented on UIMA-6064: -- Not sure what the range of reasonable use-cases are, here. Is just a switch/flag for DISALLOW_DOCTYPE_DECL all that's needed in your use case? If so, I think I would rather implement that (only) until we get more evidence of what other use cases are needed. > External DTD usage in XML descriptors disabled during build revision upgrade > > > Key: UIMA-6064 > URL: https://issues.apache.org/jira/browse/UIMA-6064 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.10.2SDK >Reporter: Timo Boehme >Priority: Major > > Between version 2.10.1 and 2.10.2 the XMLParser configuration was changed > (fixed, without the possibility to adjust it) to not allow for DTD and its > loading from external file. > This is done in XMLUtils.createSAXParserFactory() which sets the > DISALLOW_DOCTYPE_DECL and LOAD_EXTERNAL_DTD feature. Before the > SAXParserFactory was created without adjusting these features. > While I understand that this was done to prevent malicious XML from doing > nasty things, the kind how it was done is problematic: > * the change happened in a revision build, no major or minor number change > * it was not documented > * one cannot simply change it back like using an environment variable, > method call etc. - the only workaround is to do a problematic sub-classing of > XMLParser_impl with additional configuration etc. > We use the DTDs for CPE descriptors quite a lot to have the descriptor in > modular chunks using entities etc. Thus it is important (for the time being) > to use DTD there - and we know that the XML is not problematic. > Because this feature (DTD) is crucial I have marked this as a BUG since such > changes should not occur in a build upgrade or it should at least be possible > to get the old behavior easily back. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-6064) External DTD usage in XML descriptors disabled during build revision upgrade
[ https://issues.apache.org/jira/browse/UIMA-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865721#comment-16865721 ] Marshall Schor commented on UIMA-6064: -- Thanks; good catch on ACCESS_EXTERNAL_SCHEMA - we'll add that. It seems reasonable to add 1 switch to restrict all/ none (default restrict all). I'll work on coming up with a spec for the true/false and "protocols" or all or "". I'm thinking of making all of these -D kind of parameters, because that allows env vars (as the value of the -D parameter) as an alternative. > External DTD usage in XML descriptors disabled during build revision upgrade > > > Key: UIMA-6064 > URL: https://issues.apache.org/jira/browse/UIMA-6064 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.10.2SDK >Reporter: Timo Boehme >Priority: Major > > Between version 2.10.1 and 2.10.2 the XMLParser configuration was changed > (fixed, without the possibility to adjust it) to not allow for DTD and its > loading from external file. > This is done in XMLUtils.createSAXParserFactory() which sets the > DISALLOW_DOCTYPE_DECL and LOAD_EXTERNAL_DTD feature. Before the > SAXParserFactory was created without adjusting these features. > While I understand that this was done to prevent malicious XML from doing > nasty things, the kind how it was done is problematic: > * the change happened in a revision build, no major or minor number change > * it was not documented > * one cannot simply change it back like using an environment variable, > method call etc. - the only workaround is to do a problematic sub-classing of > XMLParser_impl with additional configuration etc. > We use the DTDs for CPE descriptors quite a lot to have the descriptor in > modular chunks using entities etc. Thus it is important (for the time being) > to use DTD there - and we know that the XML is not problematic. > Because this feature (DTD) is crucial I have marked this as a BUG since such > changes should not occur in a build upgrade or it should at least be possible > to get the old behavior easily back. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-6058) Pear destroy does not destroy the resourceManagers
[ https://issues.apache.org/jira/browse/UIMA-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865698#comment-16865698 ] Marshall Schor commented on UIMA-6058: -- Thanks. Is this Jira now a request to diagnose / fix why the mMetaDataList in CasManager_impl got so large? If so, I think this might be due to a bug in the fix for UIMA-1249. I suspect that the code added for UIMA-1249 is missing some things. To diagnose this, it would be helpful to see what the value of the mMetaDataList is when it grows large in your application. Can you do this and attach it to this Jira? (Doesn't have to be big amount, but something that shows some duplication which ought not to be happening...) Also, let me know if I'm going down the wrong path, and this Jira is about fixing something else :) . > Pear destroy does not destroy the resourceManagers > -- > > Key: UIMA-6058 > URL: https://issues.apache.org/jira/browse/UIMA-6058 > Project: UIMA > Issue Type: Bug >Reporter: Matthias Koch >Priority: Major > Attachments: Screenshot_20190614_095220.png, UIMA-6058.diff > > > the pear wrapper is caching resourceManagers which are not getting destroyed > on destroy of the pear wrapper. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-6057) Avoid falsely switching classloader
[ https://issues.apache.org/jira/browse/UIMA-6057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864402#comment-16864402 ] Marshall Schor commented on UIMA-6057: -- is this the case of "nested Pears" - that is a pear context invoking another pear? (not currently supported, but if there's a use case, perhaps we can figure out a better fix for this?) > Avoid falsely switching classloader > --- > > Key: UIMA-6057 > URL: https://issues.apache.org/jira/browse/UIMA-6057 > Project: UIMA > Issue Type: Bug >Reporter: Matthias Koch >Priority: Major > Attachments: UIMA-6057.diff > > > In some cases the classloader is switched back, although it hasn't be > switched before processing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-6058) Pear destroy does not destroy the resourceManagers
[ https://issues.apache.org/jira/browse/UIMA-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864400#comment-16864400 ] Marshall Schor commented on UIMA-6058: -- hmm, I think it could be pretty easy to have a shared implicitly - created one: * create a ResourceManager, call its getCasManager() - creates an implicit one. * create another resource manager, call its setCasManager() which would then have that cas manager shared by two resource managers. > Pear destroy does not destroy the resourceManagers > -- > > Key: UIMA-6058 > URL: https://issues.apache.org/jira/browse/UIMA-6058 > Project: UIMA > Issue Type: Bug >Reporter: Matthias Koch >Priority: Major > Attachments: Screenshot_20190614_095220.png, UIMA-6058.diff > > > the pear wrapper is caching resourceManagers which are not getting destroyed > on destroy of the pear wrapper. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-6057) Avoid falsely switching classloader
[ https://issues.apache.org/jira/browse/UIMA-6057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864381#comment-16864381 ] Marshall Schor commented on UIMA-6057: -- I looked at the patch. It changes the switcher to return a boolean saying if it was switched. The switch back is augmented to test a passed-in parameter (was_switched) - if that's set, then the switch back works like before - testing to see if the previous loader is different, etc. If the parameter is false, then the switch back won't happen (even if the previous loader is different). In the framework code, as you've pointed out, this parameter is not needed, and is redundant. I presume in some Ruta context, it is set false to block the switching back. Is that correct? I'd like to document this as clearly as possible for future maintainers. > Avoid falsely switching classloader > --- > > Key: UIMA-6057 > URL: https://issues.apache.org/jira/browse/UIMA-6057 > Project: UIMA > Issue Type: Bug >Reporter: Matthias Koch >Priority: Major > Attachments: UIMA-6057.diff > > > In some cases the classloader is switched back, although it hasn't be > switched before processing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (UIMA-6058) Pear destroy does not destroy the resourceManagers
[ https://issues.apache.org/jira/browse/UIMA-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864345#comment-16864345 ] Marshall Schor edited comment on UIMA-6058 at 6/14/19 6:42 PM: --- Rather than work on the mMetaDataList, perhaps a better thing is to let the garbage collector collect the entire CasManager_impl. The ResourceManager_impl has a reference to a CasManager_impl. When the ResourceManger destroy() method is called, it doesn't do anything to the referenced CasManager, because that instance could be shared with other (non-destroyed) ResourceManagers. But, if you know (in your particular application instance) when calling a ResourceManager instance's destroy(), that the referenced CasManager is not shared, and won't be used again, you could null out the reference: e.g. my_resource_mgr.setCasManager(null); This ought to allow the garbage collector to collect the CasManager (and therefore, it's mMetaDataList). Would this method work for your use case? was (Author: schor): The ResourceManager_impl has a reference to a CasManager_impl. When the ResourceManger destroy() method is called, it doesn't do anything to the referenced CasManager, because that instance could be shared with other (non-destroyed) ResourceManagers. If, in your application, you know when calling a ResourceManager instance's destroy(), that the referenced CasManager is not shared, and won't be used again, you could null out the reference: e.g. my_resource_mgr.setCasManager(null); This ought to allow the garbage collector to collect the CasManager (and therefore, it's mMetaDataList). Would this method work for your use case? > Pear destroy does not destroy the resourceManagers > -- > > Key: UIMA-6058 > URL: https://issues.apache.org/jira/browse/UIMA-6058 > Project: UIMA > Issue Type: Bug >Reporter: Matthias Koch >Priority: Major > Attachments: Screenshot_20190614_095220.png, UIMA-6058.diff > > > the pear wrapper is caching resourceManagers which are not getting destroyed > on destroy of the pear wrapper. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-6058) Pear destroy does not destroy the resourceManagers
[ https://issues.apache.org/jira/browse/UIMA-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864345#comment-16864345 ] Marshall Schor commented on UIMA-6058: -- The ResourceManager_impl has a reference to a CasManager_impl. When the ResourceManger destroy() method is called, it doesn't do anything to the referenced CasManager, because that instance could be shared with other (non-destroyed) ResourceManagers. If, in your application, you know when calling a ResourceManager instance's destroy(), that the referenced CasManager is not shared, and won't be used again, you could null out the reference: e.g. my_resource_mgr.setCasManager(null); This ought to allow the garbage collector to collect the CasManager (and therefore, it's mMetaDataList). Would this method work for your use case? > Pear destroy does not destroy the resourceManagers > -- > > Key: UIMA-6058 > URL: https://issues.apache.org/jira/browse/UIMA-6058 > Project: UIMA > Issue Type: Bug >Reporter: Matthias Koch >Priority: Major > Attachments: Screenshot_20190614_095220.png, UIMA-6058.diff > > > the pear wrapper is caching resourceManagers which are not getting destroyed > on destroy of the pear wrapper. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-6058) Pear destroy does not destroy the resourceManagers
[
https://issues.apache.org/jira/browse/UIMA-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864299#comment-16864299
]
Marshall Schor commented on UIMA-6058:
--
Thanks for clarifying. It looks from your trace that the part not getting
cleaned is mMetaDataList, which has the comment:
{code:java}
/**
* accumulates the metadata needed for shared CASes for this resource manager
* Starts out "empty" when this is created; is added to (but never removed)
* Duplicates may be in the list.
*
* Threading: This list is always accessed under the class instance lock.
*/
private final List mMetaDataList = new
ArrayList();
{code}
I'll have to investigate why the design was such that things are never
removed...
> Pear destroy does not destroy the resourceManagers
> --
>
> Key: UIMA-6058
> URL: https://issues.apache.org/jira/browse/UIMA-6058
> Project: UIMA
> Issue Type: Bug
>Reporter: Matthias Koch
>Priority: Major
> Attachments: Screenshot_20190614_095220.png, UIMA-6058.diff
>
>
> the pear wrapper is caching resourceManagers which are not getting destroyed
> on destroy of the pear wrapper.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (UIMA-6056) JCasGen for producing FSArray is a raw type warning
[
https://issues.apache.org/jira/browse/UIMA-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863494#comment-16863494
]
Marshall Schor commented on UIMA-6056:
--
Thanks for volunteering :) to improve the test cases. There are some tests in
the project "jcasgen-maven-plugin". These run the jcasgen over some type
descriptors. The type descriptors are in the /src/test/resources, and the test
class is in src/test/java (JCasGenMojoTest).
> JCasGen for producing FSArray is a raw type warning
> ---
>
> Key: UIMA-6056
> URL: https://issues.apache.org/jira/browse/UIMA-6056
> Project: UIMA
> Issue Type: Bug
> Components: UIMA
>Affects Versions: 3.0.2SDK
>Reporter: Hai-Son Nguyen
>Priority: Minor
> Attachments: patch-uima-6056v1.txt, typeSystemDescriptorTest.xml
>
>
> With the conversion of FSArray into Generic FSArray<> the JCasGen process
> does not handle the Generic type properly and will cause extensive warnings
> in application code.
> The 4 methods generating warnings are:
> xXXX - Feature name, Generic - generic type
> * *public* FSArray getXXX() { *...* }
> * *public* *void* setXXX(FSArray v) \{ ... }
> * *public* Generic getXXX(*int* i) \{ ... }
> * *public* *void* setXXX(*int* i, Generic v) \{ ... }
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (UIMA-6064) External DTD usage in XML descriptors disabled during build revision upgrade
[ https://issues.apache.org/jira/browse/UIMA-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863490#comment-16863490 ] Marshall Schor edited comment on UIMA-6064 at 6/13/19 9:50 PM: --- There are 6 xml / sax feature strings in XMLUtils. Should one switch/flag be use to disable/enable all of these? Or just some? or do we need multiple flags? Thanks for clarifying. was (Author: schor): There are 6 xml / sax feature strings in XMLUtils. Should one switch/flag be use to disable/endable all of these? Or just some? or do we need multiple flags? Thanks for clarifying. > External DTD usage in XML descriptors disabled during build revision upgrade > > > Key: UIMA-6064 > URL: https://issues.apache.org/jira/browse/UIMA-6064 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.10.2SDK >Reporter: Timo Boehme >Priority: Major > > Between version 2.10.1 and 2.10.2 the XMLParser configuration was changed > (fixed, without the possibility to adjust it) to not allow for DTD and its > loading from external file. > This is done in XMLUtils.createSAXParserFactory() which sets the > DISALLOW_DOCTYPE_DECL and LOAD_EXTERNAL_DTD feature. Before the > SAXParserFactory was created without adjusting these features. > While I understand that this was done to prevent malicious XML from doing > nasty things, the kind how it was done is problematic: > * the change happened in a revision build, no major or minor number change > * it was not documented > * one cannot simply change it back like using an environment variable, > method call etc. - the only workaround is to do a problematic sub-classing of > XMLParser_impl with additional configuration etc. > We use the DTDs for CPE descriptors quite a lot to have the descriptor in > modular chunks using entities etc. Thus it is important (for the time being) > to use DTD there - and we know that the XML is not problematic. > Because this feature (DTD) is crucial I have marked this as a BUG since such > changes should not occur in a build upgrade or it should at least be possible > to get the old behavior easily back. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-6064) External DTD usage in XML descriptors disabled during build revision upgrade
[ https://issues.apache.org/jira/browse/UIMA-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863490#comment-16863490 ] Marshall Schor commented on UIMA-6064: -- There are 6 xml / sax feature strings in XMLUtils. Should one switch/flag be use to disable/endable all of these? Or just some? or do we need multiple flags? Thanks for clarifying. > External DTD usage in XML descriptors disabled during build revision upgrade > > > Key: UIMA-6064 > URL: https://issues.apache.org/jira/browse/UIMA-6064 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.10.2SDK >Reporter: Timo Boehme >Priority: Major > > Between version 2.10.1 and 2.10.2 the XMLParser configuration was changed > (fixed, without the possibility to adjust it) to not allow for DTD and its > loading from external file. > This is done in XMLUtils.createSAXParserFactory() which sets the > DISALLOW_DOCTYPE_DECL and LOAD_EXTERNAL_DTD feature. Before the > SAXParserFactory was created without adjusting these features. > While I understand that this was done to prevent malicious XML from doing > nasty things, the kind how it was done is problematic: > * the change happened in a revision build, no major or minor number change > * it was not documented > * one cannot simply change it back like using an environment variable, > method call etc. - the only workaround is to do a problematic sub-classing of > XMLParser_impl with additional configuration etc. > We use the DTDs for CPE descriptors quite a lot to have the descriptor in > modular chunks using entities etc. Thus it is important (for the time being) > to use DTD there - and we know that the XML is not problematic. > Because this feature (DTD) is crucial I have marked this as a BUG since such > changes should not occur in a build upgrade or it should at least be possible > to get the old behavior easily back. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-6056) JCasGen for producing FSArray is a raw type warning
[
https://issues.apache.org/jira/browse/UIMA-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862457#comment-16862457
]
Marshall Schor commented on UIMA-6056:
--
Hi, In looking at the patch, the special treatment is invoked for both FSArrays
and FSLists.
The new code in Jg calls getJavaRangeArrayElementType even if the feature
descriptor isn't an array. But this looks like it might be OK, for FSList, if
the value was available, but if it wasn't, might throw an exception?
It would be good to have some test cases to confirm / test these things :)
> JCasGen for producing FSArray is a raw type warning
> ---
>
> Key: UIMA-6056
> URL: https://issues.apache.org/jira/browse/UIMA-6056
> Project: UIMA
> Issue Type: Bug
> Components: UIMA
>Affects Versions: 3.0.2SDK
>Reporter: Hai-Son Nguyen
>Priority: Minor
> Attachments: patch-uima-6056v1.txt
>
>
> With the conversion of FSArray into Generic FSArray<> the JCasGen process
> does not handle the Generic type properly and will cause extensive warnings
> in application code.
> The 4 methods generating warnings are:
> xXXX - Feature name, Generic - generic type
> * *public* FSArray getXXX() { *...* }
> * *public* *void* setXXX(FSArray v) \{ ... }
> * *public* Generic getXXX(*int* i) \{ ... }
> * *public* *void* setXXX(*int* i, Generic v) \{ ... }
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (UIMA-6057) Avoid falsely switching classloader
[ https://issues.apache.org/jira/browse/UIMA-6057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862427#comment-16862427 ] Marshall Schor commented on UIMA-6057: -- Can you say more why this is needed? If the class loader wasn't switch, the switch-back is supposed to be a no-op. Is there a case where this isn't working? > Avoid falsely switching classloader > --- > > Key: UIMA-6057 > URL: https://issues.apache.org/jira/browse/UIMA-6057 > Project: UIMA > Issue Type: Bug >Reporter: Matthias Koch >Priority: Major > Attachments: UIMA-6057.diff > > > In some cases the classloader is switched back, although it hasn't be > switched before processing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-6058) Pear destroy does not destroy the resourceManagers
[ https://issues.apache.org/jira/browse/UIMA-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862396#comment-16862396 ] Marshall Schor commented on UIMA-6058: -- This seems closely related to UIMA-5935. Did that Jira resolve this issue already, or is there something missed? > Pear destroy does not destroy the resourceManagers > -- > > Key: UIMA-6058 > URL: https://issues.apache.org/jira/browse/UIMA-6058 > Project: UIMA > Issue Type: Bug >Reporter: Matthias Koch >Priority: Major > Attachments: UIMA-6058.diff > > > the pear wrapper is caching resourceManagers which are not getting destroyed > on destroy of the pear wrapper. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (UIMA-6063) DUCC: Add utility to run arbitrary commands as a Job process
[ https://issues.apache.org/jira/browse/UIMA-6063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-6063: - Summary: DUCC: Add utility to run arbitrary commands as a Job process (was: Add utility to run arbitrary commands as a Job process) > DUCC: Add utility to run arbitrary commands as a Job process > > > Key: UIMA-6063 > URL: https://issues.apache.org/jira/browse/UIMA-6063 > Project: UIMA > Issue Type: Improvement > Components: DUCC >Reporter: Eddie Epstein >Assignee: Eddie Epstein >Priority: Major > > This utility consists of > # a simple collection reader that runs in the Job Driver which reads a > specified input file and sends each line as a work item to be processed by a > Job Process > # a simple annotator that runs in a Job Process and does Runtime.exec on the > line > # a utility script that kicks off a job given the path to the input file, > the scheduling class to run in, the amount of RAM to allocate to each Job > Process, and any additional DUCC job parameters as needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-6064) External DTD usage in XML descriptors disabled during build revision upgrade
[ https://issues.apache.org/jira/browse/UIMA-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862384#comment-16862384 ] Marshall Schor commented on UIMA-6064: -- Hi, would putting the disable of the LOAD_EXTERNAL_DTD (only) under the control of a JVM - D uima. kind of argument be suitable for your use case? Or do you need also the other flag? > External DTD usage in XML descriptors disabled during build revision upgrade > > > Key: UIMA-6064 > URL: https://issues.apache.org/jira/browse/UIMA-6064 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.10.2SDK >Reporter: Timo Boehme >Priority: Major > > Between version 2.10.1 and 2.10.2 the XMLParser configuration was changed > (fixed, without the possibility to adjust it) to not allow for DTD and its > loading from external file. > This is done in XMLUtils.createSAXParserFactory() which sets the > DISALLOW_DOCTYPE_DECL and LOAD_EXTERNAL_DTD feature. Before the > SAXParserFactory was created without adjusting these features. > While I understand that this was done to prevent malicious XML from doing > nasty things, the kind how it was done is problematic: > * the change happened in a revision build, no major or minor number change > * it was not documented > * one cannot simply change it back like using an environment variable, > method call etc. - the only workaround is to do a problematic sub-classing of > XMLParser_impl with additional configuration etc. > We use the DTDs for CPE descriptors quite a lot to have the descriptor in > modular chunks using entities etc. Thus it is important (for the time being) > to use DTD there - and we know that the XML is not problematic. > Because this feature (DTD) is crucial I have marked this as a BUG since such > changes should not occur in a build upgrade or it should at least be possible > to get the old behavior easily back. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-5936) PearSpecifier should be able to store every parametertype that analysisEngines support
[ https://issues.apache.org/jira/browse/UIMA-5936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862087#comment-16862087 ] Marshall Schor commented on UIMA-5936: -- hi, thanks for this - I've been a bit swamped, but will try to get to this soon (and also your other Jiras :) ) > PearSpecifier should be able to store every parametertype that > analysisEngines support > -- > > Key: UIMA-5936 > URL: https://issues.apache.org/jira/browse/UIMA-5936 > Project: UIMA > Issue Type: Improvement >Affects Versions: 2.10.3SDK >Reporter: Matthias Koch >Priority: Major > Attachments: UIMA-5936.diff > > > > The pearSpecifier currently holds a Parameter_impl(String, String). This > limits the fields of application. Therefore we changed the specifier to store > an array of nameValuePairs, so all possible analysisEngine parameters are > supported. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-6055) JCasGen adds unused imports if class has no new features
[ https://issues.apache.org/jira/browse/UIMA-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16860034#comment-16860034 ] Marshall Schor commented on UIMA-6055: -- hmmm, it looks like the patch I uploaded (patch-uima-6055v2.txt) was for the wrong file - I meant to upload the one for the JCasType.javajet. I see you created that, it looks good. The JCasTypeTemplate looks like it might have been diffed from the uima v2 version. Instead of that, I plan to use the JCasType.javajet and regenerate the JCasTypeTemplate for the uima v3 version of the code. Thanks for your help :) > JCasGen adds unused imports if class has no new features > > > Key: UIMA-6055 > URL: https://issues.apache.org/jira/browse/UIMA-6055 > Project: UIMA > Issue Type: Bug > Components: UIMA >Affects Versions: 3.0.2SDK >Reporter: Hai-Son Nguyen >Priority: Minor > Attachments: patch-uima-6055v1.txt, patch-uima-6055v2.txt, > patch-uima-6055v3.txt > > > In the JCasTypeTemplate class, the need for the following 3 imports: > * *import* java.lang.invoke.CallSite; > * *import* java.lang.invoke.MethodHandle; > * *import* org.apache.uima.cas.impl.TypeSystemImpl; > were added to enable code added when new features are coded into the class. > > In classes without new features will cause these import statements to > generate unused import warnings: > like "The import XXX is never used" > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-6054) JCasGen generating warnings by creating deprecated constructors
[ https://issues.apache.org/jira/browse/UIMA-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16860009#comment-16860009 ] Marshall Schor commented on UIMA-6054: -- ok, it looks like the main idea is to mark the 0-arg constructor as deprecated, except when the superclass's constructor is not deprecated. I think it may be better to mark *all* generated 0-arg constructors as deprecated, because they should not be used, and it would be good to note that with the deprecation annotation. Users should never have made use of these, so it's not really a question of suggesting to users to "migrate away" from these. It's more a way to remind users if they accidentally code this, that they should rethink what they're doing. I don't think there's any negative consequence or Eclipse warnings, etc. from this, but please let me know if this is not right. > JCasGen generating warnings by creating deprecated constructors > --- > > Key: UIMA-6054 > URL: https://issues.apache.org/jira/browse/UIMA-6054 > Project: UIMA > Issue Type: Bug > Components: UIMA >Affects Versions: 3.0.2SDK >Reporter: Hai-Son Nguyen >Priority: Trivial > Attachments: patch-uima-6054v1.txt, patch-uima-6054v2.txt, > patch-uima-6054v3.txt, patch-uima-6054v4.txt > > > The JCasGen process produces classes with a protected empty no parameter > constructor. > Base classes that have extended the Annotation class > (org.apache.uima.jcas.tcas.Annotation) are now getting warnings that the > constructor Annotation() is deprecated. > The constructor documentation states, "Never called. Disable default > constructor" but the presence of other constructors already serve this > purpose. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (UIMA-6060) uv3 support shared, typed, 0-length FSArrays
[ https://issues.apache.org/jira/browse/UIMA-6060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-6060: - Description: Extend the support for lazily-created shared immutable Feature Structures to FSArrays having a particular subtype. (The current support assumes there's no subtype). Make the creation of typed arrays optional for compatibility with UIMA v2, and earlier versions of v3. Control this with a -Duima. parameter was: Extend the support for lazily-created shared immutable Feature Structures to FSArrays having a particular subtype. (The current support assumes there's no subtype). > uv3 support shared, typed, 0-length FSArrays > > > Key: UIMA-6060 > URL: https://issues.apache.org/jira/browse/UIMA-6060 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Affects Versions: 3.0.2SDK >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.3SDK > > > Extend the support for lazily-created shared immutable Feature Structures to > FSArrays having a particular subtype. (The current support assumes there's > no subtype). > Make the creation of typed arrays optional for compatibility with UIMA v2, > and earlier versions of v3. Control this with a -Duima. parameter > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (UIMA-6060) uv3 support shared, typed, 0-length FSArrays
Marshall Schor created UIMA-6060: Summary: uv3 support shared, typed, 0-length FSArrays Key: UIMA-6060 URL: https://issues.apache.org/jira/browse/UIMA-6060 Project: UIMA Issue Type: Improvement Components: Core Java Framework Affects Versions: 3.0.2SDK Reporter: Marshall Schor Assignee: Marshall Schor Fix For: 3.0.3SDK Extend the support for lazily-created shared immutable Feature Structures to FSArrays having a particular subtype. (The current support assumes there's no subtype). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (UIMA-6059) update uima-wide build pom to use more https
[ https://issues.apache.org/jira/browse/UIMA-6059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-6059. Resolution: Fixed > update uima-wide build pom to use more https > > > Key: UIMA-6059 > URL: https://issues.apache.org/jira/browse/UIMA-6059 > Project: UIMA > Issue Type: Improvement > Components: Build, Packaging and Test >Affects Versions: parent-pom-12 >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: parent-pom-13 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (UIMA-6059) update uima-wide build pom to use more https
Marshall Schor created UIMA-6059: Summary: update uima-wide build pom to use more https Key: UIMA-6059 URL: https://issues.apache.org/jira/browse/UIMA-6059 Project: UIMA Issue Type: Improvement Components: Build, Packaging and Test Affects Versions: parent-pom-12 Reporter: Marshall Schor Assignee: Marshall Schor Fix For: parent-pom-13 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-6054) JCasGen generating warnings by creating deprecated constructors
[ https://issues.apache.org/jira/browse/UIMA-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858682#comment-16858682 ] Marshall Schor commented on UIMA-6054: -- hmmm, I don't think this will work in many cases (that I can think of...). Here's one: A user has converted to uima version 3 and is running with some type system hierarchy. They then regenerate one of their types, TTT, whose supertype is TTTSSS, whose supertype is Annotation. The hasDeprecatedDefaultConstructor(TTTSSS) would return false, but in fact, because it was generated before this change went in, it would need to return true. Did I miss something? > JCasGen generating warnings by creating deprecated constructors > --- > > Key: UIMA-6054 > URL: https://issues.apache.org/jira/browse/UIMA-6054 > Project: UIMA > Issue Type: Bug > Components: UIMA >Affects Versions: 3.0.2SDK >Reporter: Hai-Son Nguyen >Priority: Trivial > Attachments: patch-uima-6054v1.txt, patch-uima-6054v2.txt, > patch-uima-6054v3.txt > > > The JCasGen process produces classes with a protected empty no parameter > constructor. > Base classes that have extended the Annotation class > (org.apache.uima.jcas.tcas.Annotation) are now getting warnings that the > constructor Annotation() is deprecated. > The constructor documentation states, "Never called. Disable default > constructor" but the presence of other constructors already serve this > purpose. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-6055) JCasGen adds unused imports if class has no new features
[ https://issues.apache.org/jira/browse/UIMA-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858676#comment-16858676 ] Marshall Schor commented on UIMA-6055: -- hi - I attached a patch to the template, copying your patch. To run the jet generator, add the uimaj-jet-expander project to your workspace: To get it into your Eclipse workspace, use the SVN Repo view, and do an eclipse SVN checkout as uimaj-jet-expander Or, if it is already checked out, do a File -- import -- Projects from Folder or Archive then select the uimaj-jet-expander folder It has launchers already configured to do the generation - do a Run -> JetExpander (not JetExpander_type - is only for uima version 2). Then do an eclipse refresh on uimaj-tools, and you should see the JCasTypeTemplate.java class changed... > JCasGen adds unused imports if class has no new features > > > Key: UIMA-6055 > URL: https://issues.apache.org/jira/browse/UIMA-6055 > Project: UIMA > Issue Type: Bug > Components: UIMA >Affects Versions: 3.0.2SDK >Reporter: Hai-Son Nguyen >Priority: Minor > Attachments: patch-uima-6055v1.txt, patch-uima-6055v2.txt > > > In the JCasTypeTemplate class, the need for the following 3 imports: > * *import* java.lang.invoke.CallSite; > * *import* java.lang.invoke.MethodHandle; > * *import* org.apache.uima.cas.impl.TypeSystemImpl; > were added to enable code added when new features are coded into the class. > > In classes without new features will cause these import statements to > generate unused import warnings: > like "The import XXX is never used" > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (UIMA-6055) JCasGen adds unused imports if class has no new features
[ https://issues.apache.org/jira/browse/UIMA-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-6055: - Attachment: patch-uima-6055v2.txt > JCasGen adds unused imports if class has no new features > > > Key: UIMA-6055 > URL: https://issues.apache.org/jira/browse/UIMA-6055 > Project: UIMA > Issue Type: Bug > Components: UIMA >Affects Versions: 3.0.2SDK >Reporter: Hai-Son Nguyen >Priority: Minor > Attachments: patch-uima-6055v1.txt, patch-uima-6055v2.txt > > > In the JCasTypeTemplate class, the need for the following 3 imports: > * *import* java.lang.invoke.CallSite; > * *import* java.lang.invoke.MethodHandle; > * *import* org.apache.uima.cas.impl.TypeSystemImpl; > were added to enable code added when new features are coded into the class. > > In classes without new features will cause these import statements to > generate unused import warnings: > like "The import XXX is never used" > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-6055) JCasGen adds unused imports if class has no new features
[ https://issues.apache.org/jira/browse/UIMA-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857987#comment-16857987 ] Marshall Schor commented on UIMA-6055: -- looks like a good patch. The right file to patch is in the uimaj-tools project, /src/main/javajet/jcasget/templates/JCasType.javajet. I'll take a crack at adding the patch you did to that file, and then regenerating the other class. I think the generated class should include a header comment stating it is generated, base on the javajet class :) . > JCasGen adds unused imports if class has no new features > > > Key: UIMA-6055 > URL: https://issues.apache.org/jira/browse/UIMA-6055 > Project: UIMA > Issue Type: Bug > Components: UIMA >Affects Versions: 3.0.2SDK >Reporter: Hai-Son Nguyen >Priority: Minor > Attachments: patch-uima-6055v1.txt > > > In the JCasTypeTemplate class, the need for the following 3 imports: > * *import* java.lang.invoke.CallSite; > * *import* java.lang.invoke.MethodHandle; > * *import* org.apache.uima.cas.impl.TypeSystemImpl; > were added to enable code added when new features are coded into the class. > > In classes without new features will cause these import statements to > generate unused import warnings: > like "The import XXX is never used" > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-6054) JCasGen generating warnings by creating deprecated constructors
[
https://issues.apache.org/jira/browse/UIMA-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857976#comment-16857976
]
Marshall Schor commented on UIMA-6054:
--
The need for supress warning can't be limited to just Annotation type. I think
all types (both built-in and user-defined) except for TOP have the 0-argument
constructor marked Deprecated.
If the goal is to not have the warning "unnessary
SupressWarnings("deprecation")" appear in Eclipse, perhaps the right way to do
this is to have the logic always add the SupressWarnings except when the
supertype is TOP.
> JCasGen generating warnings by creating deprecated constructors
> ---
>
> Key: UIMA-6054
> URL: https://issues.apache.org/jira/browse/UIMA-6054
> Project: UIMA
> Issue Type: Bug
> Components: UIMA
>Affects Versions: 3.0.2SDK
>Reporter: Hai-Son Nguyen
>Priority: Trivial
> Attachments: patch-uima-6054v1.txt, patch-uima-6054v2.txt
>
>
> The JCasGen process produces classes with a protected empty no parameter
> constructor.
> Base classes that have extended the Annotation class
> (org.apache.uima.jcas.tcas.Annotation) are now getting warnings that the
> constructor Annotation() is deprecated.
> The constructor documentation states, "Never called. Disable default
> constructor" but the presence of other constructors already serve this
> purpose.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (UIMA-6054) JCasGen generating warnings by creating deprecated constructors
[ https://issues.apache.org/jira/browse/UIMA-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857968#comment-16857968 ] Marshall Schor commented on UIMA-6054: -- all user-defined types always have a supertype. The most basic supertype (doesn't define any features) is the built-in type TOP. If your types have no need for "begin" and "end" features, you probably want their supertype to be TOP, not Annotation. > JCasGen generating warnings by creating deprecated constructors > --- > > Key: UIMA-6054 > URL: https://issues.apache.org/jira/browse/UIMA-6054 > Project: UIMA > Issue Type: Bug > Components: UIMA >Affects Versions: 3.0.2SDK >Reporter: Hai-Son Nguyen >Priority: Trivial > Attachments: patch-uima-6054v1.txt, patch-uima-6054v2.txt > > > The JCasGen process produces classes with a protected empty no parameter > constructor. > Base classes that have extended the Annotation class > (org.apache.uima.jcas.tcas.Annotation) are now getting warnings that the > constructor Annotation() is deprecated. > The constructor documentation states, "Never called. Disable default > constructor" but the presence of other constructors already serve this > purpose. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-6054) JCasGen generating warnings by creating deprecated constructors
[
https://issues.apache.org/jira/browse/UIMA-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857672#comment-16857672
]
Marshall Schor commented on UIMA-6054:
--
I'm thinking this may cause backwards compatibility issues, for this use case:
The default empty constructor is removed for Type XXX. But there exists
somewhere else, in a separate compilation unit or project, a type XXX_S whose
parent is XXX. Then when XXX_S is loaded to run or compile, you get an error.
Perhaps a better fix would be to add an annotation
@SupressWarnings("deprecation") to these?
> JCasGen generating warnings by creating deprecated constructors
> ---
>
> Key: UIMA-6054
> URL: https://issues.apache.org/jira/browse/UIMA-6054
> Project: UIMA
> Issue Type: Bug
> Components: UIMA
>Affects Versions: 3.0.2SDK
>Reporter: Hai-Son Nguyen
>Priority: Trivial
> Attachments: patch-uima-6054v1.txt
>
>
> The JCasGen process produces classes with a protected empty no parameter
> constructor.
> Base classes that have extended the Annotation class
> (org.apache.uima.jcas.tcas.Annotation) are now getting warnings that the
> constructor Annotation() is deprecated.
> The constructor documentation states, "Never called. Disable default
> constructor" but the presence of other constructors already serve this
> purpose.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (UIMA-6047) uv3 deserialization of typed arrays could be faulty in edge case
[ https://issues.apache.org/jira/browse/UIMA-6047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-6047: - Summary: uv3 deserialization of typed arrays could be faulty in edge case (was: uv3 deserialization of type arrays could be faulty in edge case) > uv3 deserialization of typed arrays could be faulty in edge case > > > Key: UIMA-6047 > URL: https://issues.apache.org/jira/browse/UIMA-6047 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 3.0.2SDK >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Major > Fix For: 3.0.3SDK > > > UIMA has some limited support for typed arrays. These are declared in type > system descriptors by including an elementType specification for a feature > whose range is FSArray. > See > [http://uima.apache.org/d/uimaj-current/references.html#ugr.ref.xml.component_descriptor.type_system.features] > The XCAS and the Xmi serialization forms serialize these as FSArray. The > deserialization code, when deserializing these, looks at the feature > declaration to see if it has an elementType, and if so, changes the type of > the Feature Structure to that type. > This is fine except for two cases: > 1) backwards compatibility - this wasn't done in v2. This might be an > ignorable difference (except for utilities that compare CASs, and don't > accommodate this). > 2) (more important) Sometimes feature structures are "shared" - that is, > multiple different features might reference the same one. These features > might not have the same element type. A not unusual use case is the one > where the item being referenced is a 0-length Feature Structure, and the code > is sharing one common (immutable) instance of this. > For #2, one possible fix is to examine the "multipleReferencesAllowed" > property of the feature, and only do this narrowing of the type if this is > false, and the rest of the code hasn't accidentally shared this feature > structure with other references. > For #1, perhaps the right approach is to have a backwards compatibility -D > flag that (if set) avoids doing this type update when deserializing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (UIMA-6047) uv3 deserialization of type arrays could be faulty in edge case
Marshall Schor created UIMA-6047: Summary: uv3 deserialization of type arrays could be faulty in edge case Key: UIMA-6047 URL: https://issues.apache.org/jira/browse/UIMA-6047 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 3.0.2SDK Reporter: Marshall Schor Assignee: Marshall Schor Fix For: 3.0.3SDK UIMA has some limited support for typed arrays. These are declared in type system descriptors by including an elementType specification for a feature whose range is FSArray. See [http://uima.apache.org/d/uimaj-current/references.html#ugr.ref.xml.component_descriptor.type_system.features] The XCAS and the Xmi serialization forms serialize these as FSArray. The deserialization code, when deserializing these, looks at the feature declaration to see if it has an elementType, and if so, changes the type of the Feature Structure to that type. This is fine except for two cases: 1) backwards compatibility - this wasn't done in v2. This might be an ignorable difference (except for utilities that compare CASs, and don't accommodate this). 2) (more important) Sometimes feature structures are "shared" - that is, multiple different features might reference the same one. These features might not have the same element type. A not unusual use case is the one where the item being referenced is a 0-length Feature Structure, and the code is sharing one common (immutable) instance of this. For #2, one possible fix is to examine the "multipleReferencesAllowed" property of the feature, and only do this narrowing of the type if this is false, and the rest of the code hasn't accidentally shared this feature structure with other references. For #1, perhaps the right approach is to have a backwards compatibility -D flag that (if set) avoids doing this type update when deserializing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (UIMA-6043) uv3 add -D flag to report on feature structure pinning
Marshall Schor created UIMA-6043: Summary: uv3 add -D flag to report on feature structure pinning Key: UIMA-6043 URL: https://issues.apache.org/jira/browse/UIMA-6043 Project: UIMA Issue Type: Improvement Components: Core Java Framework Affects Versions: 3.0.2SDK Reporter: Marshall Schor Assignee: Marshall Schor Fix For: 3.0.3SDK When migrating to UIMA v3, code might inadvertently cause some feature structures (FSs) to be pinned in memory, typically by producing some int value that could be used to retrieve the FS. If pinned, a FS cannot be garbage collected. Turning on this -D flag will produce a report of where code is pinning FSs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (UIMA-6042) casCompare: add showProgress mode, and a sort fs array with dedup
Marshall Schor created UIMA-6042: Summary: casCompare: add showProgress mode, and a sort fs array with dedup Key: UIMA-6042 URL: https://issues.apache.org/jira/browse/UIMA-6042 Project: UIMA Issue Type: Improvement Components: Core Java Framework Affects Versions: 3.0.2SDK Reporter: Marshall Schor Assignee: Marshall Schor Fix For: 3.0.3SDK When running cas compares with large CASs (e.g. 200 MB xmi serialized size), it can take a while to do many operations. Allow setting a global static value in the CasCompare to turn on various progress indicators. Also, add a pre-compare operation to sort and dedup (remove duplicates) for FSArrays. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (UIMA-6038) uv3 scaffolding for readonly, no-access modes: improve cas reset
Marshall Schor created UIMA-6038: Summary: uv3 scaffolding for readonly, no-access modes: improve cas reset Key: UIMA-6038 URL: https://issues.apache.org/jira/browse/UIMA-6038 Project: UIMA Issue Type: Improvement Components: Core Java Framework Affects Versions: 3.0.2SDK Reporter: Marshall Schor Assignee: Marshall Schor The cas reset does an "expensive" operation to reset a method handle. guard this code to only do this if needed (it won't be needed usually, unless read-only mode is set). The expensive operation showed up in some profiling in a big application. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (UIMA-6025) uv3 extend migration tool to work on a single Java source file
Marshall Schor created UIMA-6025: Summary: uv3 extend migration tool to work on a single Java source file Key: UIMA-6025 URL: https://issues.apache.org/jira/browse/UIMA-6025 Project: UIMA Issue Type: Improvement Components: Core Java Framework Affects Versions: 3.0.2SDK Reporter: Marshall Schor Assignee: Marshall Schor Fix For: 3.0.3SDK A use case that arises when migrating a large project to v3: 1) you migrate all the JCas classes 2) you run for a while to gain confidence in a mode where you can switch between v2 and v3. During this time, some incremental changes happen to the v2 JCas classes, and you want to migrate just the changed class. Extend the meaning of the -sourcesRoots argument to allow it to point to a single JCas source file, and have the migration tool migrate just that one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (UIMA-6023) change String.replaceAll() to replace() if the replaced one is plain string.
[
https://issues.apache.org/jira/browse/UIMA-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor updated UIMA-6023:
-
Component/s: (was: Ruta)
DUCC
> change String.replaceAll() to replace() if the replaced one is plain string.
>
>
> Key: UIMA-6023
> URL: https://issues.apache.org/jira/browse/UIMA-6023
> Project: UIMA
> Issue Type: Bug
> Components: DUCC
>Reporter: bd2019us
>Priority: Major
> Labels: pull-request-available
> Attachments: 1.patch
>
>
> Location:
> uima-ducc-user/src/main/java/org/apache/uima/ducc/user/common/UimaUtils.java
> The replaced string ("/") is a plain string, which need not to be compiled a
> head of time. Therefore, use the replaceAll() API may damage the performance
> since replaceAll() will compile the given string. The replace() method is
> recommended to improve performance.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (UIMA-6023) change String.replaceAll() to replace() if the replaced one is plain string.
[
https://issues.apache.org/jira/browse/UIMA-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor updated UIMA-6023:
-
Component/s: Ruta
> change String.replaceAll() to replace() if the replaced one is plain string.
>
>
> Key: UIMA-6023
> URL: https://issues.apache.org/jira/browse/UIMA-6023
> Project: UIMA
> Issue Type: Bug
> Components: Ruta
>Reporter: bd2019us
>Priority: Major
> Labels: pull-request-available
> Attachments: 1.patch
>
>
> Location:
> uima-ducc-user/src/main/java/org/apache/uima/ducc/user/common/UimaUtils.java
> The replaced string ("/") is a plain string, which need not to be compiled a
> head of time. Therefore, use the replaceAll() API may damage the performance
> since replaceAll() will compile the given string. The replace() method is
> recommended to improve performance.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (UIMA-6018) uv3 change release number 3.0.2 to 3.1.0
[ https://issues.apache.org/jira/browse/UIMA-6018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-6018. -- Resolution: Fixed > uv3 change release number 3.0.2 to 3.1.0 > > > Key: UIMA-6018 > URL: https://issues.apache.org/jira/browse/UIMA-6018 > Project: UIMA > Issue Type: Task > Components: Core Java Framework >Affects Versions: 3.0.1SDK >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.1.0SDK > > > because of some api changes that can affect some users -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (UIMA-5869) The JCas getView method throws CasRuntimeException not CasException
[ https://issues.apache.org/jira/browse/UIMA-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5869: - Fix Version/s: (was: 2.10.4SDK) (was: 3.1.0SDK) > The JCas getView method throws CasRuntimeException not CasException > --- > > Key: UIMA-5869 > URL: https://issues.apache.org/jira/browse/UIMA-5869 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.10.2SDK, 3.0.0SDK >Reporter: Burn Lewis >Assignee: Marshall Schor >Priority: Minor > > Code that uses JCas getView expects CasException to be thrown if a view is > missing, but instead the underlying CAS.getView method throws > CasRuntimeException. > Either the code or the Javadocs should be fixed. Since a missing view is not > uncommon, throwing an unchecked exception is not very useful. Making the > framework code match the Javadocs should have tminimal impact on existing > user code. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (UIMA-5869) The JCas getView method throws CasRuntimeException not CasException
[ https://issues.apache.org/jira/browse/UIMA-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806800#comment-16806800 ] Marshall Schor edited comment on UIMA-5869 at 4/1/19 2:54 PM: -- This fix has broken existing implementations which test for particular exception classes to be thrown. I'm going to defer fixing this for now. It probably should eventually be fixed, because both the JCas and JCasImpl classes state (and have for a long time) that the getView method throws CASException - so anyone relying on this will be mislead. Will revisit when we have other reasons to bump the version number by the 2nd digit. was (Author: schor): This fix has broken existing implementations, for little or no added benefit. Reverse it, and instead update the javadocs (which I think will not break anything). > The JCas getView method throws CasRuntimeException not CasException > --- > > Key: UIMA-5869 > URL: https://issues.apache.org/jira/browse/UIMA-5869 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.10.2SDK, 3.0.0SDK >Reporter: Burn Lewis >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.1.0SDK, 2.10.4SDK > > > Code that uses JCas getView expects CasException to be thrown if a view is > missing, but instead the underlying CAS.getView method throws > CasRuntimeException. > Either the code or the Javadocs should be fixed. Since a missing view is not > uncommon, throwing an unchecked exception is not very useful. Making the > framework code match the Javadocs should have tminimal impact on existing > user code. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (UIMA-6018) uv3 change release number 3.0.2 to 3.1.0
[ https://issues.apache.org/jira/browse/UIMA-6018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reopened UIMA-6018: -- after reversing UIMA-5869 the reason for moving the version to 3.1.0 instead of 3.0.2 went away. Reset the version back to 3.0.2 > uv3 change release number 3.0.2 to 3.1.0 > > > Key: UIMA-6018 > URL: https://issues.apache.org/jira/browse/UIMA-6018 > Project: UIMA > Issue Type: Task > Components: Core Java Framework >Affects Versions: 3.0.1SDK >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.1.0SDK > > > because of some api changes that can affect some users -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (UIMA-5869) The JCas getView method throws CasRuntimeException not CasException
[ https://issues.apache.org/jira/browse/UIMA-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reopened UIMA-5869: -- Assignee: Marshall Schor This fix has broken existing implementations, for little or no added benefit. Reverse it, and instead update the javadocs (which I think will not break anything). > The JCas getView method throws CasRuntimeException not CasException > --- > > Key: UIMA-5869 > URL: https://issues.apache.org/jira/browse/UIMA-5869 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.10.2SDK, 3.0.0SDK >Reporter: Burn Lewis >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.1.0SDK, 2.10.4SDK > > > Code that uses JCas getView expects CasException to be thrown if a view is > missing, but instead the underlying CAS.getView method throws > CasRuntimeException. > Either the code or the Javadocs should be fixed. Since a missing view is not > uncommon, throwing an unchecked exception is not very useful. Making the > framework code match the Javadocs should have tminimal impact on existing > user code. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (UIMA-6018) uv3 change release number 3.0.2 to 3.1.0
[ https://issues.apache.org/jira/browse/UIMA-6018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-6018. -- Resolution: Fixed > uv3 change release number 3.0.2 to 3.1.0 > > > Key: UIMA-6018 > URL: https://issues.apache.org/jira/browse/UIMA-6018 > Project: UIMA > Issue Type: Task > Components: Core Java Framework >Affects Versions: 3.0.1SDK >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.1.0SDK > > > because of some api changes that can affect some users -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (UIMA-6018) uv3 change release number 3.0.2 to 3.1.0
Marshall Schor created UIMA-6018: Summary: uv3 change release number 3.0.2 to 3.1.0 Key: UIMA-6018 URL: https://issues.apache.org/jira/browse/UIMA-6018 Project: UIMA Issue Type: Task Components: Core Java Framework Affects Versions: 3.0.1SDK Reporter: Marshall Schor Assignee: Marshall Schor Fix For: 3.1.0SDK because of some api changes that can affect some users -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (UIMA-6017) uv3 make cascompare more useful by eliminating duplicate reporting
[ https://issues.apache.org/jira/browse/UIMA-6017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-6017. -- Resolution: Fixed > uv3 make cascompare more useful by eliminating duplicate reporting > -- > > Key: UIMA-6017 > URL: https://issues.apache.org/jira/browse/UIMA-6017 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework, Tools >Affects Versions: 3.0.1SDK >Reporter: Marshall Schor >Priority: Minor > Fix For: 3.0.2SDK > > > When using the cas compare to discover the root cause of two CASs > miscomparing, it is helpful to exclude showing miscompares that are caused by > already reported miscompares. > For example, if you have some collection of Feature Structures, and one of > them miscompares and you report that, it is helpful to not also report the > two collections are miscomparing. > If you don't exclude these "upper level" miscompares from reporting, there > are typically so many reported miscompares, that it's hard to focus on the > root cause. > Also, remove code that was conditionally sorting some collections during > compare - this broke other code and isn't needed - any sorting should be done > before this routine is called. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (UIMA-6017) uv3 make cascompare more useful by eliminating duplicate reporting
[ https://issues.apache.org/jira/browse/UIMA-6017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-6017: - Description: When using the cas compare to discover the root cause of two CASs miscomparing, it is helpful to exclude showing miscompares that are caused by already reported miscompares. For example, if you have some collection of Feature Structures, and one of them miscompares and you report that, it is helpful to not also report the two collections are miscomparing. If you don't exclude these "upper level" miscompares from reporting, there are typically so many reported miscompares, that it's hard to focus on the root cause. Also, remove code that was conditionally sorting some collections during compare - this broke other code and isn't needed - any sorting should be done before this routine is called. was: When using the cas compare to discover the root cause of two CASs miscomparing, it is helpful to exclude showing miscompares that are caused by already reported miscompares. For example, if you have some collection of Feature Structures, and one of them miscompares and you report that, it is helpful to not also report the two collections are miscomparing. If you don't exclude these "upper level" miscompares from reporting, there are typically so many reported miscompares, that it's hard to focus on the root cause. > uv3 make cascompare more useful by eliminating duplicate reporting > -- > > Key: UIMA-6017 > URL: https://issues.apache.org/jira/browse/UIMA-6017 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework, Tools >Affects Versions: 3.0.1SDK >Reporter: Marshall Schor >Priority: Minor > Fix For: 3.0.2SDK > > > When using the cas compare to discover the root cause of two CASs > miscomparing, it is helpful to exclude showing miscompares that are caused by > already reported miscompares. > For example, if you have some collection of Feature Structures, and one of > them miscompares and you report that, it is helpful to not also report the > two collections are miscomparing. > If you don't exclude these "upper level" miscompares from reporting, there > are typically so many reported miscompares, that it's hard to focus on the > root cause. > Also, remove code that was conditionally sorting some collections during > compare - this broke other code and isn't needed - any sorting should be done > before this routine is called. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (UIMA-6017) uv3 make cascompare more useful by eliminating duplicate reporting
Marshall Schor created UIMA-6017: Summary: uv3 make cascompare more useful by eliminating duplicate reporting Key: UIMA-6017 URL: https://issues.apache.org/jira/browse/UIMA-6017 Project: UIMA Issue Type: Improvement Components: Core Java Framework, Tools Affects Versions: 3.0.1SDK Reporter: Marshall Schor Fix For: 3.0.2SDK When using the cas compare to discover the root cause of two CASs miscomparing, it is helpful to exclude showing miscompares that are caused by already reported miscompares. For example, if you have some collection of Feature Structures, and one of them miscompares and you report that, it is helpful to not also report the two collections are miscomparing. If you don't exclude these "upper level" miscompares from reporting, there are typically so many reported miscompares, that it's hard to focus on the root cause. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (UIMA-6016) uv3 subiterator handling of some edge cases incorrect
[ https://issues.apache.org/jira/browse/UIMA-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-6016. -- Resolution: Fixed > uv3 subiterator handling of some edge cases incorrect > - > > Key: UIMA-6016 > URL: https://issues.apache.org/jira/browse/UIMA-6016 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 3.0.1SDK >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Major > Fix For: 3.0.2SDK > > > A user found a subiterator was marked not-valid, when there were annotations > present, due to some wrong logic around test checking for if the found > annotation was equal to the bounding one. > A careful review of the subiterator implementation revealed many other edge > cases needing fixing. Do a refactoring to simplify the implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (UIMA-6016) uv3 subiterator handling of some edge cases incorrect
Marshall Schor created UIMA-6016: Summary: uv3 subiterator handling of some edge cases incorrect Key: UIMA-6016 URL: https://issues.apache.org/jira/browse/UIMA-6016 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 3.0.1SDK Reporter: Marshall Schor Assignee: Marshall Schor Fix For: 3.0.2SDK A user found a subiterator was marked not-valid, when there were annotations present, due to some wrong logic around test checking for if the found annotation was equal to the bounding one. A careful review of the subiterator implementation revealed many other edge cases needing fixing. Do a refactoring to simplify the implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (UIMA-5930) use StandardCharsets constants if possible
[ https://issues.apache.org/jira/browse/UIMA-5930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5930: - Summary: use StandardCharsets constants if possible (was: use StandardChartsets constants if possible) > use StandardCharsets constants if possible > -- > > Key: UIMA-5930 > URL: https://issues.apache.org/jira/browse/UIMA-5930 > Project: UIMA > Issue Type: Improvement >Reporter: Joern Kottmann >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.2SDK > > Attachments: uimaj-5930.patch > > > In some cases it is possible to replace charset strings with charset > constants. > There are two advantages in doing this: > - If somebody introduces a typo in the constant name that will result in a > compiler error > - Error handling for the UnsupportedEncodingException can be removed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (UIMA-5930) use StandardCharsets constants if possible
[ https://issues.apache.org/jira/browse/UIMA-5930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-5930. Resolution: Fixed > use StandardCharsets constants if possible > -- > > Key: UIMA-5930 > URL: https://issues.apache.org/jira/browse/UIMA-5930 > Project: UIMA > Issue Type: Improvement >Reporter: Joern Kottmann >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.2SDK > > Attachments: uimaj-5930.patch > > > In some cases it is possible to replace charset strings with charset > constants. > There are two advantages in doing this: > - If somebody introduces a typo in the constant name that will result in a > compiler error > - Error handling for the UnsupportedEncodingException can be removed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (UIMA-5991) uv3 augment Cas Compare to allow for a series of accomodations
[ https://issues.apache.org/jira/browse/UIMA-5991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5991. -- Resolution: Fixed > uv3 augment Cas Compare to allow for a series of accomodations > -- > > Key: UIMA-5991 > URL: https://issues.apache.org/jira/browse/UIMA-5991 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Affects Versions: 3.0.1SDK >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.2SDK > > > The Cas Compare class supports a small range of accomodations. Document > these better, and extend them to include more variations, including having > specific String/FS/Arrays be sorted if needed for particular type/feature > pairs. > This allows running the compare between CASs produced by different runs where > perhaps it is desired to ignore the ordering of elements in particular arrays > (because, for instance, they might have been produced by iterating over hash > maps/sets, and the order is unimportant) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (UIMA-5991) uv3 augment Cas Compare to allow for a series of accomodations
Marshall Schor created UIMA-5991: Summary: uv3 augment Cas Compare to allow for a series of accomodations Key: UIMA-5991 URL: https://issues.apache.org/jira/browse/UIMA-5991 Project: UIMA Issue Type: Improvement Components: Core Java Framework Affects Versions: 3.0.1SDK Reporter: Marshall Schor Assignee: Marshall Schor Fix For: 3.0.2SDK The Cas Compare class supports a small range of accomodations. Document these better, and extend them to include more variations, including having specific String/FS/Arrays be sorted if needed for particular type/feature pairs. This allows running the compare between CASs produced by different runs where perhaps it is desired to ignore the ordering of elements in particular arrays (because, for instance, they might have been produced by iterating over hash maps/sets, and the order is unimportant) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (UIMA-5990) Wrong URL on UIMA "Get involved" page
[
https://issues.apache.org/jira/browse/UIMA-5990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor closed UIMA-5990.
Resolution: Fixed
Thanks, Mandy! I changed this link to point to the UIMA project in the Apache
Jira.
> Wrong URL on UIMA "Get involved" page
> -
>
> Key: UIMA-5990
> URL: https://issues.apache.org/jira/browse/UIMA-5990
> Project: UIMA
> Issue Type: Bug
> Components: Website
>Reporter: Mandy Neumann
>Assignee: Marshall Schor
>Priority: Minor
> Labels: easyfix
>
> The URL pointing to this Jira at the Apache UIMA "Get involved" website is
> incorrect and leads to this error message:
> {color:#33}"This project isn't available{color}
> {color:#33}It may have been deleted or your permissions may have
> changed.{color}
> {color:#33}[View a list of all
> projects|https://issues.apache.org/jira/projects]"{color}
>
> This is the current URL:
> [https://issues.apache.org/jira/secure/BrowseProject.jspa?id=0]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (UIMA-5990) Wrong URL on UIMA "Get involved" page
[
https://issues.apache.org/jira/browse/UIMA-5990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor reassigned UIMA-5990:
Assignee: Marshall Schor
> Wrong URL on UIMA "Get involved" page
> -
>
> Key: UIMA-5990
> URL: https://issues.apache.org/jira/browse/UIMA-5990
> Project: UIMA
> Issue Type: Bug
> Components: Website
>Reporter: Mandy Neumann
>Assignee: Marshall Schor
>Priority: Minor
> Labels: easyfix
>
> The URL pointing to this Jira at the Apache UIMA "Get involved" website is
> incorrect and leads to this error message:
> {color:#33}"This project isn't available{color}
> {color:#33}It may have been deleted or your permissions may have
> changed.{color}
> {color:#33}[View a list of all
> projects|https://issues.apache.org/jira/projects]"{color}
>
> This is the current URL:
> [https://issues.apache.org/jira/secure/BrowseProject.jspa?id=0]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (UIMA-5961) InternationalizedException getLocalizedMessage fails in pear
[ https://issues.apache.org/jira/browse/UIMA-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761913#comment-16761913 ] Marshall Schor commented on UIMA-5961: -- postponing from 3.0.2 release, awaiting response from reporters. > InternationalizedException getLocalizedMessage fails in pear > > > Key: UIMA-5961 > URL: https://issues.apache.org/jira/browse/UIMA-5961 > Project: UIMA > Issue Type: Bug >Affects Versions: 2.10.3SDK >Reporter: Matthias Koch >Assignee: Marshall Schor >Priority: Major > Fix For: 2.10.4SDK > > Attachments: UIMA-5961.diff > > > localized message does not work in the case of pears. The classloader stored > in the internationalizedException is wrong. The bundle cant be found in this > classloader. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (UIMA-5961) InternationalizedException getLocalizedMessage fails in pear
[ https://issues.apache.org/jira/browse/UIMA-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5961: - Fix Version/s: (was: 3.0.2SDK) > InternationalizedException getLocalizedMessage fails in pear > > > Key: UIMA-5961 > URL: https://issues.apache.org/jira/browse/UIMA-5961 > Project: UIMA > Issue Type: Bug >Affects Versions: 2.10.3SDK >Reporter: Matthias Koch >Assignee: Marshall Schor >Priority: Major > Fix For: 2.10.4SDK > > Attachments: UIMA-5961.diff > > > localized message does not work in the case of pears. The classloader stored > in the internationalizedException is wrong. The bundle cant be found in this > classloader. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (UIMA-5926) Remove IBM UIMA to Apache UIMA migration tool
[ https://issues.apache.org/jira/browse/UIMA-5926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5926. -- Resolution: Fixed > Remove IBM UIMA to Apache UIMA migration tool > - > > Key: UIMA-5926 > URL: https://issues.apache.org/jira/browse/UIMA-5926 > Project: UIMA > Issue Type: Improvement > Components: Tools >Affects Versions: 3.0.1SDK >Reporter: Joern Kottmann >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.2SDK > > > UIMA moved to Apache roughly 12 years ago. There should be no need to keep > the IBM to Apache migration tool. The users who still need to migrate can > migrate to UIMA 2 and then migrate to UIMA 3. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (UIMA-5931) Use try-with-resources where possible
[ https://issues.apache.org/jira/browse/UIMA-5931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5931. -- Resolution: Fixed > Use try-with-resources where possible > - > > Key: UIMA-5931 > URL: https://issues.apache.org/jira/browse/UIMA-5931 > Project: UIMA > Issue Type: Improvement >Reporter: Joern Kottmann >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.2SDK > > Attachments: uima-try-with-resources.patch > > > The try-with-resources statement allows writing code dealing with resources > in a more compact way. It is no longer necessary to write finally blocks by > hand. > This patch replaces as many as possible try statements with the > try-with-resources statement. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-5926) Remove IBM UIMA to Apache UIMA migration tool
[ https://issues.apache.org/jira/browse/UIMA-5926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16759969#comment-16759969 ] Marshall Schor commented on UIMA-5926: -- Yes, I will remove, and also remove the out-of-date refs to semantic search engine located at IBM's alphaworks. > Remove IBM UIMA to Apache UIMA migration tool > - > > Key: UIMA-5926 > URL: https://issues.apache.org/jira/browse/UIMA-5926 > Project: UIMA > Issue Type: Improvement > Components: Tools >Affects Versions: 3.0.1SDK >Reporter: Joern Kottmann >Assignee: Joern Kottmann >Priority: Minor > Fix For: 3.0.2SDK > > > UIMA moved to Apache roughly 12 years ago. There should be no need to keep > the IBM to Apache migration tool. The users who still need to migrate can > migrate to UIMA 2 and then migrate to UIMA 3. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-5961) InternationalizedException getLocalizedMessage fails in pear
[ https://issues.apache.org/jira/browse/UIMA-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16759995#comment-16759995 ] Marshall Schor commented on UIMA-5961: -- My suggestion above is probably not right. The climbing class loader would naturally find some class in the call chain that was in the PEAR bundle (if the error occurred in some class loaded from the PEAR), and from there, would make use of that class's classloader, which whould include the the PEAR's classpath. In your use case, was the message bundle you were hoping to use, in the PEAR's classloader? Could you please post a stack trace, to debug this further? > InternationalizedException getLocalizedMessage fails in pear > > > Key: UIMA-5961 > URL: https://issues.apache.org/jira/browse/UIMA-5961 > Project: UIMA > Issue Type: Bug >Affects Versions: 2.10.3SDK >Reporter: Matthias Koch >Assignee: Marshall Schor >Priority: Major > Fix For: 3.0.2SDK, 2.10.4SDK > > Attachments: UIMA-5961.diff > > > localized message does not work in the case of pears. The classloader stored > in the internationalizedException is wrong. The bundle cant be found in this > classloader. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (UIMA-5926) Remove IBM UIMA to Apache UIMA migration tool
[ https://issues.apache.org/jira/browse/UIMA-5926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reassigned UIMA-5926: Assignee: Marshall Schor (was: Joern Kottmann) > Remove IBM UIMA to Apache UIMA migration tool > - > > Key: UIMA-5926 > URL: https://issues.apache.org/jira/browse/UIMA-5926 > Project: UIMA > Issue Type: Improvement > Components: Tools >Affects Versions: 3.0.1SDK >Reporter: Joern Kottmann >Assignee: Marshall Schor >Priority: Minor > Fix For: 3.0.2SDK > > > UIMA moved to Apache roughly 12 years ago. There should be no need to keep > the IBM to Apache migration tool. The users who still need to migrate can > migrate to UIMA 2 and then migrate to UIMA 3. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (UIMA-5976) uv3 support additional JCas / type system use case
[ https://issues.apache.org/jira/browse/UIMA-5976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5976. -- Resolution: Fixed > uv3 support additional JCas / type system use case > -- > > Key: UIMA-5976 > URL: https://issues.apache.org/jira/browse/UIMA-5976 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 3.0.1SDK >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Major > Fix For: 3.0.2SDK > > > UIMA allows multiple pipelines having multiple type systems to be run under > one single class loader. Sometimes these type systems have somewhat > different versions. When JCas is used (within one class loader) there can > only be one instance of the JCas class definition. The implementation > attempts to make variations work, but missed one: > The following use case is throwing an exception, but should be supported: > Given: > * JCas class S defining feature F > * JCas class T having S as its super class > * Type system defining Uima Type S with feature F > When this is committed, the JCas classes are loaded; and the "slot" for > feature F is allocated in S. > Now have another type system defined with UIMA Type T having feature F, and > supertype S. > This was throwing an exception. This might occur in practice when a slot is > migrated from a subtype to a supertype in some (but not all) instances of > type system definitions being run (typically in different UIMA pipelines, > running together in one JVM within one class loader). > Have this work, by setting the slot offset for this type be the slot for F > defined in the SuperType S. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (UIMA-5974) uv3 unnecessary API change from v2 breaking binary compatibility
[ https://issues.apache.org/jira/browse/UIMA-5974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5974. -- Resolution: Fixed > uv3 unnecessary API change from v2 breaking binary compatibility > > > Key: UIMA-5974 > URL: https://issues.apache.org/jira/browse/UIMA-5974 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 3.0.1SDK >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Major > Fix For: 3.0.2SDK > > > Uima v3 strives to be binary compatible with v2, with the exception of > needing new JCas classes. This allows a simpler migration because (the goal > is) you don't need to recompile JARs - the same Jars can be used with either > v2 or v3. > Found a few spots where v3 changed the signature of a public API, usually to > a more specific type, which, while correct, breaks binary compatibility. > Reverse these changes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (UIMA-5976) uv3 support additional JCas / type system use case
Marshall Schor created UIMA-5976: Summary: uv3 support additional JCas / type system use case Key: UIMA-5976 URL: https://issues.apache.org/jira/browse/UIMA-5976 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 3.0.1SDK Reporter: Marshall Schor Assignee: Marshall Schor Fix For: 3.0.2SDK UIMA allows multiple pipelines having multiple type systems to be run under one single class loader. Sometimes these type systems have somewhat different versions. When JCas is used (within one class loader) there can only be one instance of the JCas class definition. The implementation attempts to make variations work, but missed one: The following use case is throwing an exception, but should be supported: Given: * JCas class S defining feature F * JCas class T having S as its super class * Type system defining Uima Type S with feature F When this is committed, the JCas classes are loaded; and the "slot" for feature F is allocated in S. Now have another type system defined with UIMA Type T having feature F, and supertype S. This was throwing an exception. This might occur in practice when a slot is migrated from a subtype to a supertype in some (but not all) instances of type system definitions being run (typically in different UIMA pipelines, running together in one JVM within one class loader). Have this work, by setting the slot offset for this type be the slot for F defined in the SuperType S. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (UIMA-5974) uv3 unnecessary API change from v2 breaking binary compatibility
Marshall Schor created UIMA-5974: Summary: uv3 unnecessary API change from v2 breaking binary compatibility Key: UIMA-5974 URL: https://issues.apache.org/jira/browse/UIMA-5974 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 3.0.1SDK Reporter: Marshall Schor Assignee: Marshall Schor Fix For: 3.0.2SDK Uima v3 strives to be binary compatible with v2, with the exception of needing new JCas classes. This allows a simpler migration because (the goal is) you don't need to recompile JARs - the same Jars can be used with either v2 or v3. Found a few spots where v3 changed the signature of a public API, usually to a more specific type, which, while correct, breaks binary compatibility. Reverse these changes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (UIMA-5935) Destroy the ResourceManager on destroy of a pear
[ https://issues.apache.org/jira/browse/UIMA-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5935. -- Resolution: Fixed any testing would be appreciated :) > Destroy the ResourceManager on destroy of a pear > - > > Key: UIMA-5935 > URL: https://issues.apache.org/jira/browse/UIMA-5935 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.10.3SDK >Reporter: Philipp Butz >Assignee: Marshall Schor >Priority: Major > Fix For: 3.0.2SDK, 2.10.4SDK > > Attachments: Screenshot from 2018-12-18 08-34-10.png, UIMA-5935.diff > > > This bug is related to bug UIMA-5799 . The bug seems not completely fixed, > since the files are still being accessed after trying to delete them. This > behavior can be shown by the tool 'lsof' (see screenshot). There seems still > access to the resources of a pear on the file system, which denies the > complete deletion on the file system after uninstalling it (they are marked > as deleted but are not actually removed). > > Potential cause: > The class PearAnalysisEngineWrapper creates and caches resource managers. The > elements in that Cache (Java map) are never explicitly removed, not even in > the destroy method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (UIMA-5913) Nullpointer Exception when closing a UIMAAnnotationViewer window
[ https://issues.apache.org/jira/browse/UIMA-5913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5913: - Fix Version/s: 2.10.4SDK 3.0.2SDK > Nullpointer Exception when closing a UIMAAnnotationViewer window > > > Key: UIMA-5913 > URL: https://issues.apache.org/jira/browse/UIMA-5913 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework, Eclipse plugins, Ruta >Affects Versions: 2.7.0ruta > Environment: *OS:* > Distributor ID: Ubuntu > Description: Ubuntu 18.04.1 LTS > Release: 18.04 > Codename: bionic > *ECLIPSE & JAVA:* > !SESSION 2018-11-28 17:11:26.789 > --- > eclipse.buildId=4.9.0.I20180906-0745 > java.version=1.8.0_191 > java.vendor=Oracle Corporation > BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US > Framework arguments: -product org.eclipse.epp.package.java.product > Command-line arguments: -os linux -ws gtk -arch x86_64 -product > org.eclipse.epp.package.java.product > Created Time: 2018-11-29 08:47:09.695 > !ENTRY org.eclipse.e4.ui.workbench 4 0 2018-11-29 08:47:09.695 >Reporter: Erdan Genc >Assignee: Peter Klügl >Priority: Minor > Labels: usability > Fix For: 3.0.2SDK, 2.10.4SDK > > Attachments: error.log, uima-5913.patch > > > When closing a UIMAAnnotationViewer window in eclipse under linux, an > unexpected Nullpointer is thrown which renders the UIMA perspectives > (AnnotationBrowser, SelectionView, etc.) unusable. > Current workaround: Restart eclipse and don't close UIMAAnnotationViewer > windows. > You can find the error.log in the attachments. > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-5964) null matchedText value in ConceptMapper when OrderIndependentLookup is false.
[ https://issues.apache.org/jira/browse/UIMA-5964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16756524#comment-16756524 ] Marshall Schor commented on UIMA-5964: -- This would also increase the size of the dictionary entries when "sorted" was being used. > null matchedText value in ConceptMapper when OrderIndependentLookup is false. > - > > Key: UIMA-5964 > URL: https://issues.apache.org/jira/browse/UIMA-5964 > Project: UIMA > Issue Type: Bug > Components: addons >Affects Versions: ConceptMapper-2.10.2 >Reporter: Francisco Abad >Assignee: Michael Tanenblatt >Priority: Minor > Labels: easyfix > Attachments: image-2019-01-17-09-30-51-818.png > > Original Estimate: 1h > Remaining Estimate: 1h > > I'm trying the concept mapper and I noted that the field relative to > ResultingAnnotationMatchedTextFeature in the generated annotations was always > null: > !image-2019-01-17-09-30-51-818.png! > I checked the source code and I figured out that this feature is loaded from > a "unsorted" property from DictionaryResource_impl class, which is only > initialized when the parameter "OrderIndependentLookup" is true. In this > case, the matched text field is not null. I think "unsorted" should be > initialized always to avoid this behavior. > Greetings, > Francisco Abad. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (UIMA-5790) ConceptMapper (addon) use of FileXXStream should do appropriate buffering
[ https://issues.apache.org/jira/browse/UIMA-5790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5790: - Fix Version/s: ConceptMapper-2.10.2 > ConceptMapper (addon) use of FileXXStream should do appropriate buffering > - > > Key: UIMA-5790 > URL: https://issues.apache.org/jira/browse/UIMA-5790 > Project: UIMA > Issue Type: Improvement >Affects Versions: ConceptMapper-2.10.2 >Reporter: Marshall Schor >Priority: Minor > Fix For: ConceptMapper-2.10.2 > > > Methods in concept mapper like serializeEntries(FileOutputStream output) > should be changed to just OutputStream, and should check to see if buffering > is being done, and if not, wrap in a BufferedOutputStream (same for input). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (UIMA-5790) ConceptMapper (addon) use of FileXXStream should do appropriate buffering
[ https://issues.apache.org/jira/browse/UIMA-5790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5790. -- Resolution: Fixed > ConceptMapper (addon) use of FileXXStream should do appropriate buffering > - > > Key: UIMA-5790 > URL: https://issues.apache.org/jira/browse/UIMA-5790 > Project: UIMA > Issue Type: Improvement >Affects Versions: ConceptMapper-2.10.2 >Reporter: Marshall Schor >Priority: Minor > Fix For: ConceptMapper-2.10.2 > > > Methods in concept mapper like serializeEntries(FileOutputStream output) > should be changed to just OutputStream, and should check to see if buffering > is being done, and if not, wrap in a BufferedOutputStream (same for input). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (UIMA-5913) Nullpointer Exception when closing a UIMAAnnotationViewer window
[ https://issues.apache.org/jira/browse/UIMA-5913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5913. -- Resolution: Fixed > Nullpointer Exception when closing a UIMAAnnotationViewer window > > > Key: UIMA-5913 > URL: https://issues.apache.org/jira/browse/UIMA-5913 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework, Eclipse plugins, Ruta >Affects Versions: 2.7.0ruta > Environment: *OS:* > Distributor ID: Ubuntu > Description: Ubuntu 18.04.1 LTS > Release: 18.04 > Codename: bionic > *ECLIPSE & JAVA:* > !SESSION 2018-11-28 17:11:26.789 > --- > eclipse.buildId=4.9.0.I20180906-0745 > java.version=1.8.0_191 > java.vendor=Oracle Corporation > BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US > Framework arguments: -product org.eclipse.epp.package.java.product > Command-line arguments: -os linux -ws gtk -arch x86_64 -product > org.eclipse.epp.package.java.product > Created Time: 2018-11-29 08:47:09.695 > !ENTRY org.eclipse.e4.ui.workbench 4 0 2018-11-29 08:47:09.695 >Reporter: Erdan Genc >Assignee: Peter Klügl >Priority: Minor > Labels: usability > Fix For: 3.0.2SDK, 2.10.4SDK > > Attachments: error.log, uima-5913.patch > > > When closing a UIMAAnnotationViewer window in eclipse under linux, an > unexpected Nullpointer is thrown which renders the UIMA perspectives > (AnnotationBrowser, SelectionView, etc.) unusable. > Current workaround: Restart eclipse and don't close UIMAAnnotationViewer > windows. > You can find the error.log in the attachments. > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (UIMA-5908) deprecate ResourceManagerPearWrapper - no longer used
[ https://issues.apache.org/jira/browse/UIMA-5908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5908: - Fix Version/s: 2.10.3SDK 3.0.2SDK > deprecate ResourceManagerPearWrapper - no longer used > - > > Key: UIMA-5908 > URL: https://issues.apache.org/jira/browse/UIMA-5908 > Project: UIMA > Issue Type: Task > Components: Core Java Framework >Affects Versions: 3.0.1SDK, 2.10.3SDK >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Trivial > Fix For: 2.10.3SDK, 3.0.2SDK > > > Deprecate no-longer used method and its factory methods -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (UIMA-5869) The JCas getView method throws CasRuntimeException not CasException
[ https://issues.apache.org/jira/browse/UIMA-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5869. -- Resolution: Fixed > The JCas getView method throws CasRuntimeException not CasException > --- > > Key: UIMA-5869 > URL: https://issues.apache.org/jira/browse/UIMA-5869 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.10.2SDK, 3.0.0SDK >Reporter: Burn Lewis >Priority: Minor > Fix For: 3.0.2SDK, 2.10.4SDK > > > Code that uses JCas getView expects CasException to be thrown if a view is > missing, but instead the underlying CAS.getView method throws > CasRuntimeException. > Either the code or the Javadocs should be fixed. Since a missing view is not > uncommon, throwing an unchecked exception is not very useful. Making the > framework code match the Javadocs should have tminimal impact on existing > user code. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (UIMA-5908) deprecate ResourceManagerPearWrapper - no longer used
[ https://issues.apache.org/jira/browse/UIMA-5908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-5908. -- Resolution: Fixed > deprecate ResourceManagerPearWrapper - no longer used > - > > Key: UIMA-5908 > URL: https://issues.apache.org/jira/browse/UIMA-5908 > Project: UIMA > Issue Type: Task > Components: Core Java Framework >Affects Versions: 3.0.1SDK, 2.10.3SDK >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Trivial > Fix For: 3.0.2SDK, 2.10.3SDK > > > Deprecate no-longer used method and its factory methods -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (UIMA-5869) The JCas getView method throws CasRuntimeException not CasException
[ https://issues.apache.org/jira/browse/UIMA-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5869: - Fix Version/s: 2.10.4SDK 3.0.2SDK > The JCas getView method throws CasRuntimeException not CasException > --- > > Key: UIMA-5869 > URL: https://issues.apache.org/jira/browse/UIMA-5869 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.10.2SDK, 3.0.0SDK >Reporter: Burn Lewis >Priority: Minor > Fix For: 3.0.2SDK, 2.10.4SDK > > > Code that uses JCas getView expects CasException to be thrown if a view is > missing, but instead the underlying CAS.getView method throws > CasRuntimeException. > Either the code or the Javadocs should be fixed. Since a missing view is not > uncommon, throwing an unchecked exception is not very useful. Making the > framework code match the Javadocs should have tminimal impact on existing > user code. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-5964) null matchedText value in ConceptMapper when OrderIndependentLookup is false.
[ https://issues.apache.org/jira/browse/UIMA-5964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755310#comment-16755310 ] Marshall Schor commented on UIMA-5964: -- Hi Francisco, this fix may cost a performance hit; do you have any suggestions on how to mitigate that for users who do not need this? Would it be reasonable to add some kind of configuration parameter for this Annotator to control whether this is done? > null matchedText value in ConceptMapper when OrderIndependentLookup is false. > - > > Key: UIMA-5964 > URL: https://issues.apache.org/jira/browse/UIMA-5964 > Project: UIMA > Issue Type: Bug > Components: addons >Affects Versions: ConceptMapper-2.10.2 >Reporter: Francisco Abad >Assignee: Michael Tanenblatt >Priority: Minor > Labels: easyfix > Attachments: image-2019-01-17-09-30-51-818.png > > Original Estimate: 1h > Remaining Estimate: 1h > > I'm trying the concept mapper and I noted that the field relative to > ResultingAnnotationMatchedTextFeature in the generated annotations was always > null: > !image-2019-01-17-09-30-51-818.png! > I checked the source code and I figured out that this feature is loaded from > a "unsorted" property from DictionaryResource_impl class, which is only > initialized when the parameter "OrderIndependentLookup" is true. In this > case, the matched text field is not null. I think "unsorted" should be > initialized always to avoid this behavior. > Greetings, > Francisco Abad. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-5964) null matchedText value in ConceptMapper when OrderIndependentLookup is false.
[ https://issues.apache.org/jira/browse/UIMA-5964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16748829#comment-16748829 ] Marshall Schor commented on UIMA-5964: -- Michael Tanenblatt commented on the pull request, copied here: After going through the code manually, it does appear that the proposed change should do the right thing. I’ve been trying to figure out why that was never a reported problem, but I guess it was because when not using sorting, the array of matched tokens can be consulted to compute the matched string. Making this change would therefore be a reasonable convenience. > null matchedText value in ConceptMapper when OrderIndependentLookup is false. > - > > Key: UIMA-5964 > URL: https://issues.apache.org/jira/browse/UIMA-5964 > Project: UIMA > Issue Type: Bug > Components: addons >Affects Versions: ConceptMapper-2.10.2 >Reporter: Francisco Abad >Assignee: Michael Tanenblatt >Priority: Minor > Labels: easyfix > Attachments: image-2019-01-17-09-30-51-818.png > > Original Estimate: 1h > Remaining Estimate: 1h > > I'm trying the concept mapper and I noted that the field relative to > ResultingAnnotationMatchedTextFeature in the generated annotations was always > null: > !image-2019-01-17-09-30-51-818.png! > I checked the source code and I figured out that this feature is loaded from > a "unsorted" property from DictionaryResource_impl class, which is only > initialized when the parameter "OrderIndependentLookup" is true. In this > case, the matched text field is not null. I think "unsorted" should be > initialized always to avoid this behavior. > Greetings, > Francisco Abad. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (UIMA-5964) null matchedText value in ConceptMapper when OrderIndependentLookup is false.
[ https://issues.apache.org/jira/browse/UIMA-5964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reassigned UIMA-5964: Assignee: Michael Tanenblatt > null matchedText value in ConceptMapper when OrderIndependentLookup is false. > - > > Key: UIMA-5964 > URL: https://issues.apache.org/jira/browse/UIMA-5964 > Project: UIMA > Issue Type: Bug > Components: addons >Affects Versions: ConceptMapper-2.10.2 >Reporter: Francisco Abad >Assignee: Michael Tanenblatt >Priority: Minor > Labels: easyfix > Attachments: image-2019-01-17-09-30-51-818.png > > Original Estimate: 1h > Remaining Estimate: 1h > > I'm trying the concept mapper and I noted that the field relative to > ResultingAnnotationMatchedTextFeature in the generated annotations was always > null: > !image-2019-01-17-09-30-51-818.png! > I checked the source code and I figured out that this feature is loaded from > a "unsorted" property from DictionaryResource_impl class, which is only > initialized when the parameter "OrderIndependentLookup" is true. In this > case, the matched text field is not null. I think "unsorted" should be > initialized always to avoid this behavior. > Greetings, > Francisco Abad. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (UIMA-5935) Destroy the ResourceManager on destroy of a pear
[ https://issues.apache.org/jira/browse/UIMA-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744231#comment-16744231 ] Marshall Schor edited comment on UIMA-5935 at 1/16/19 6:41 PM: --- sorry to be slow in responding - kind of was distracted by the holidays. hmmm - I don't think this is the cause. We definitely don't want to clear this cache - as it is global for the whole JVM + classloader context, which might have many pipelines running, not related to a particular PEAR. Can you say how you arrange to call the "destroy" method of the resource manager used for the PEAR? The framework (I believe) never calls this method, expecting those users who want to, to call it themselves. Perhaps the "bug" is that when the "outer" resource manager's destroy method is called, the framework should add code to call destroy on any PEAR resource managers for which it is the parent.? It appears this might be easy to do - using the cache, which has for each outer resource manager all of the PEAR resource managers it is the parent for. was (Author: schor): sorry to be slow in responding - kind of was distracted by the holidays. hmmm - I don't think this is the cause. We definitely don't want to clear this cache - as it is global for the whole JVM + classloader context, which might have many pipelines running, not related to a particular PEAR. Can you say how you arrange to call the "destroy" method of the resource manager used for the PEAR? The framework (I believe) never calls this method, expecting those users who want to, to call it themselves. Perhaps the "bug" is that when the "outer" resource manager's destroy method is called, the framework should add code to call destroy on any PEAR resource managers for which it is the parent.? > Destroy the ResourceManager on destroy of a pear > - > > Key: UIMA-5935 > URL: https://issues.apache.org/jira/browse/UIMA-5935 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.10.3SDK >Reporter: Philipp Butz >Assignee: Marshall Schor >Priority: Major > Fix For: 3.0.2SDK, 2.10.4SDK > > Attachments: Screenshot from 2018-12-18 08-34-10.png, UIMA-5935.diff > > > This bug is related to bug UIMA-5799 . The bug seems not completely fixed, > since the files are still being accessed after trying to delete them. This > behavior can be shown by the tool 'lsof' (see screenshot). There seems still > access to the resources of a pear on the file system, which denies the > complete deletion on the file system after uninstalling it (they are marked > as deleted but are not actually removed). > > Potential cause: > The class PearAnalysisEngineWrapper creates and caches resource managers. The > elements in that Cache (Java map) are never explicitly removed, not even in > the destroy method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (UIMA-5935) Destroy the ResourceManager on destroy of a pear
[ https://issues.apache.org/jira/browse/UIMA-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744231#comment-16744231 ] Marshall Schor edited comment on UIMA-5935 at 1/16/19 4:35 PM: --- sorry to be slow in responding - kind of was distracted by the holidays. hmmm - I don't think this is the cause. We definitely don't want to clear this cache - as it is global for the whole JVM + classloader context, which might have many pipelines running, not related to a particular PEAR. Can you say how you arrange to call the "destroy" method of the resource manager used for the PEAR? The framework (I believe) never calls this method, expecting those users who want to, to call it themselves. Perhaps the "bug" is that when the "outer" resource manager's destroy method is called, the framework should add code to call destroy on any PEAR resource managers for which it is the parent.? was (Author: schor): hmmm - I don't think this is the cause. We definitely don't want to clear this cache - as it is global for the whole JVM + classloader context, which might have many pipelines running, not related to a particular PEAR. Can you say how you arrange to call the "destroy" method of the resource manager used for the PEAR? The framework (I believe) never calls this method, expecting those users who want to, to call it themselves. Perhaps the "bug" is that when the "outer" resource manager's destroy method is called, the framework should add code to call destroy on any PEAR resource managers for which it is the parent.? > Destroy the ResourceManager on destroy of a pear > - > > Key: UIMA-5935 > URL: https://issues.apache.org/jira/browse/UIMA-5935 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.10.3SDK >Reporter: Philipp Butz >Assignee: Marshall Schor >Priority: Major > Fix For: 3.0.2SDK, 2.10.4SDK > > Attachments: Screenshot from 2018-12-18 08-34-10.png, UIMA-5935.diff > > > This bug is related to bug UIMA-5799 . The bug seems not completely fixed, > since the files are still being accessed after trying to delete them. This > behavior can be shown by the tool 'lsof' (see screenshot). There seems still > access to the resources of a pear on the file system, which denies the > complete deletion on the file system after uninstalling it (they are marked > as deleted but are not actually removed). > > Potential cause: > The class PearAnalysisEngineWrapper creates and caches resource managers. The > elements in that Cache (Java map) are never explicitly removed, not even in > the destroy method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-5935) Destroy the ResourceManager on destroy of a pear
[ https://issues.apache.org/jira/browse/UIMA-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744231#comment-16744231 ] Marshall Schor commented on UIMA-5935: -- hmmm - I don't think this is the cause. We definitely don't want to clear this cache - as it is global for the whole JVM + classloader context, which might have many pipelines running, not related to a particular PEAR. Can you say how you arrange to call the "destroy" method of the resource manager used for the PEAR? The framework (I believe) never calls this method, expecting those users who want to, to call it themselves. Perhaps the "bug" is that when the "outer" resource manager's destroy method is called, the framework should add code to call destroy on any PEAR resource managers for which it is the parent.? > Destroy the ResourceManager on destroy of a pear > - > > Key: UIMA-5935 > URL: https://issues.apache.org/jira/browse/UIMA-5935 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.10.3SDK >Reporter: Philipp Butz >Assignee: Marshall Schor >Priority: Major > Fix For: 3.0.2SDK, 2.10.4SDK > > Attachments: Screenshot from 2018-12-18 08-34-10.png, UIMA-5935.diff > > > This bug is related to bug UIMA-5799 . The bug seems not completely fixed, > since the files are still being accessed after trying to delete them. This > behavior can be shown by the tool 'lsof' (see screenshot). There seems still > access to the resources of a pear on the file system, which denies the > complete deletion on the file system after uninstalling it (they are marked > as deleted but are not actually removed). > > Potential cause: > The class PearAnalysisEngineWrapper creates and caches resource managers. The > elements in that Cache (Java map) are never explicitly removed, not even in > the destroy method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (UIMA-5935) Destroy the ResourceManager on destroy of a pear
[ https://issues.apache.org/jira/browse/UIMA-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reassigned UIMA-5935: Assignee: Marshall Schor > Destroy the ResourceManager on destroy of a pear > - > > Key: UIMA-5935 > URL: https://issues.apache.org/jira/browse/UIMA-5935 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.10.3SDK >Reporter: Philipp Butz >Assignee: Marshall Schor >Priority: Major > Attachments: Screenshot from 2018-12-18 08-34-10.png, UIMA-5935.diff > > > This bug is related to bug UIMA-5799 . The bug seems not completely fixed, > since the files are still being accessed after trying to delete them. This > behavior can be shown by the tool 'lsof' (see screenshot). There seems still > access to the resources of a pear on the file system, which denies the > complete deletion on the file system after uninstalling it (they are marked > as deleted but are not actually removed). > > Potential cause: > The class PearAnalysisEngineWrapper creates and caches resource managers. The > elements in that Cache (Java map) are never explicitly removed, not even in > the destroy method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (UIMA-5935) Destroy the ResourceManager on destroy of a pear
[ https://issues.apache.org/jira/browse/UIMA-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5935: - Fix Version/s: 2.10.4SDK 3.0.2SDK > Destroy the ResourceManager on destroy of a pear > - > > Key: UIMA-5935 > URL: https://issues.apache.org/jira/browse/UIMA-5935 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.10.3SDK >Reporter: Philipp Butz >Assignee: Marshall Schor >Priority: Major > Fix For: 3.0.2SDK, 2.10.4SDK > > Attachments: Screenshot from 2018-12-18 08-34-10.png, UIMA-5935.diff > > > This bug is related to bug UIMA-5799 . The bug seems not completely fixed, > since the files are still being accessed after trying to delete them. This > behavior can be shown by the tool 'lsof' (see screenshot). There seems still > access to the resources of a pear on the file system, which denies the > complete deletion on the file system after uninstalling it (they are marked > as deleted but are not actually removed). > > Potential cause: > The class PearAnalysisEngineWrapper creates and caches resource managers. The > elements in that Cache (Java map) are never explicitly removed, not even in > the destroy method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UIMA-5961) InternationalizedException getLocalizedMessage fails in pear
[ https://issues.apache.org/jira/browse/UIMA-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744204#comment-16744204 ] Marshall Schor commented on UIMA-5961: -- In the general case, the class loader used to find the message bundle is a "climbing" class-loader. This is one that behaves like this: 1) it starts with some class loader, looks for the resource in that (and in its "parent" chain). if not found, 2) it gets the classloader for the "caller" (from the call stack), and if different from a loader already used, looks for the resource in that (and it its parent chain). If not found, repeat step 2 until you reach the top 3) if not found, use the saved "thread context class loader". It sounds like the problem as reported is that the Pear's classpath contains the message bundle, but the pear's classpath isn't being used when inside the Pear. Would a more general fix be to arrange things so that the Pear's classpath is used, when inside a PEAR context? That way, users would not need to alter their code to call these (new) APIs with explicit classloaders. I'm wondering if a better fix might be to set the threadLocalContextClass loader to the Pear's classloader, while within the PEAR and restore it when leaving the PEAR boundary? > InternationalizedException getLocalizedMessage fails in pear > > > Key: UIMA-5961 > URL: https://issues.apache.org/jira/browse/UIMA-5961 > Project: UIMA > Issue Type: Bug >Affects Versions: 2.10.3SDK >Reporter: Matthias Koch >Assignee: Marshall Schor >Priority: Major > Fix For: 3.0.2SDK, 2.10.4SDK > > Attachments: UIMA-5961.diff > > > localized message does not work in the case of pears. The classloader stored > in the internationalizedException is wrong. The bundle cant be found in this > classloader. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (UIMA-5961) InternationalizedException getLocalizedMessage fails in pear
[ https://issues.apache.org/jira/browse/UIMA-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5961: - Fix Version/s: 2.10.4SDK 3.0.2SDK > InternationalizedException getLocalizedMessage fails in pear > > > Key: UIMA-5961 > URL: https://issues.apache.org/jira/browse/UIMA-5961 > Project: UIMA > Issue Type: Bug >Affects Versions: 2.10.3SDK >Reporter: Matthias Koch >Assignee: Marshall Schor >Priority: Major > Fix For: 3.0.2SDK, 2.10.4SDK > > Attachments: UIMA-5961.diff > > > localized message does not work in the case of pears. The classloader stored > in the internationalizedException is wrong. The bundle cant be found in this > classloader. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (UIMA-5961) InternationalizedException getLocalizedMessage fails in pear
[ https://issues.apache.org/jira/browse/UIMA-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reassigned UIMA-5961: Assignee: Marshall Schor > InternationalizedException getLocalizedMessage fails in pear > > > Key: UIMA-5961 > URL: https://issues.apache.org/jira/browse/UIMA-5961 > Project: UIMA > Issue Type: Bug >Affects Versions: 2.10.3SDK >Reporter: Matthias Koch >Assignee: Marshall Schor >Priority: Major > Attachments: UIMA-5961.diff > > > localized message does not work in the case of pears. The classloader stored > in the internationalizedException is wrong. The bundle cant be found in this > classloader. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (UIMA-5944) uima-as: make Java 8 minimum level
[ https://issues.apache.org/jira/browse/UIMA-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5944: - Description: base uima now requires java 8. (was: base uima now require java 8.) > uima-as: make Java 8 minimum level > -- > > Key: UIMA-5944 > URL: https://issues.apache.org/jira/browse/UIMA-5944 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout >Reporter: Marshall Schor >Priority: Minor > Fix For: 3.0.1AS, 2.10.4AS > > > base uima now requires java 8. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (UIMA-5944) uima-as: make Java 8 minimum level
Marshall Schor created UIMA-5944: Summary: uima-as: make Java 8 minimum level Key: UIMA-5944 URL: https://issues.apache.org/jira/browse/UIMA-5944 Project: UIMA Issue Type: Bug Components: Async Scaleout Reporter: Marshall Schor Fix For: 3.0.1AS, 2.10.4AS base uima now require java 8. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (UIMA-5943) uima-as deploy editor dropped when publishing
[ https://issues.apache.org/jira/browse/UIMA-5943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5943: - Description: Same problem as UIMA-5658, causing deploy editor to not get published. Fix by reordering the * to be at the end of the import-package directive. Was fixed in v2 in revision 1818164, but never merged to v3. (was: Same problem as UIMA-5658, causing deploy editor to not get published. Fix by reordering the * to be at the end of the import-package directive. Was fixed in v2 in revision but never merged to v3.) > uima-as deploy editor dropped when publishing > - > > Key: UIMA-5943 > URL: https://issues.apache.org/jira/browse/UIMA-5943 > Project: UIMA > Issue Type: Bug > Components: Eclipse plugins >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Major > Fix For: 3.0.1AS > > > Same problem as UIMA-5658, causing deploy editor to not get published. Fix > by reordering the * to be at the end of the import-package directive. Was > fixed in v2 in revision 1818164, but never merged to v3. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (UIMA-5943) uima-as deploy editor dropped when publishing
[ https://issues.apache.org/jira/browse/UIMA-5943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5943: - Description: Same problem as UIMA-5658, causing deploy editor to not get published. Fix by reordering the * to be at the end of the import-package directive. Was fixed in v2 in revision but never merged to v3. (was: Same problem as UIMA-5658, causing deploy editor to not get published. Fix by reordering the * to be at the end of the import-package directive.) > uima-as deploy editor dropped when publishing > - > > Key: UIMA-5943 > URL: https://issues.apache.org/jira/browse/UIMA-5943 > Project: UIMA > Issue Type: Bug > Components: Eclipse plugins >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Major > Fix For: 3.0.1AS > > > Same problem as UIMA-5658, causing deploy editor to not get published. Fix > by reordering the * to be at the end of the import-package directive. Was > fixed in v2 in revision but never merged to v3. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
