Re: generics: CasPool
Adam Lally wrote: On Mon, Aug 17, 2009 at 10:39 AM, Jörn Kottmannkottm...@gmail.com wrote: The CasPool has a constructor CasPool(int aNumInstances, Collection aComponentDescriptionsOrMetaData, Properties aPerformanceTuningSettings, ResourceManager aResourceManager) where aComponentDescriptionsOrMetaData is a collection which can contain according to javadoc AnalysisEngineDescription, CollectionReaderDescription, CasConsumerDescription or ProcessingResourceMetaData objects A reference of the Collection is passed to fillPool which passes the Collection to a CasDefinition constructor which then casts everything to ProcessingResourceMetaData, which will result in a ClassCastException in the case of AnalysisEngineDescription, CollectionReaderDescription and CasConsumerDescription objects. Well, when we use generics we get an error. Good catch, that javadoc does seem to be wrong. I wonder if it was correct at some point in the past and the code has changed? Maybe, at least it was not changed through the generics. Jörn
Re: generics: additionalParams
Jörn Kottmann wrote: The additionalParams Map has a String key and can contains all kinds of Objects, so the correct generification would be MapString, Object. In the uima code base I found one invocation where a Properties object was passed as additionalParams. Properties is a MapObject, Object which will cause compile errors in user code when they use a Properties object to pass in the additional params. I don't think its common practice to use Properties for additional params. Any opinions on this ? Jörn
Re: Ontology Annotator to the sandbox
Ahmed Abdeen Hamed wrote: Attached is the documentation to the old version and I will point you a PEAR file once I finish refactoring. You cannot send attachments to this list. http://obo-annotator.svn.sourceforge.net/viewvc/obo-annotator/obo-annotator/OBO-Annotator.pdf?view=log Is this the link to the documentation you attached ? Jörn
[jira] Created: (UIMA-1499) Potential ClassCastException in CasPool
Potential ClassCastException in CasPool --- Key: UIMA-1499 URL: https://issues.apache.org/jira/browse/UIMA-1499 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.3 Reporter: Jörn Kottmann Fix For: 2.3 The CasPool has a constructor CasPool(int aNumInstances, Collection aComponentDescriptionsOrMetaData, Properties aPerformanceTuningSettings, ResourceManager aResourceManager) where aComponentDescriptionsOrMetaData is a collection which can contain according to javadoc AnalysisEngineDescription, CollectionReaderDescription, CasConsumerDescription or ProcessingResourceMetaData objects A reference of the Collection is passed to fillPool which passes the Collection to a CasDefinition constructor which then casts everything to ProcessingResourceMetaData, which will result in a ClassCastException in the case of AnalysisEngineDescription, CollectionReaderDescription and CasConsumerDescription objects. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1499) Potential ClassCastException in CasPool
[ https://issues.apache.org/jira/browse/UIMA-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744406#action_12744406 ] Jörn Kottmann commented on UIMA-1499: - Adam Lally already commented on the dev list: Good catch, that javadoc does seem to be wrong. I wonder if it was correct at some point in the past and the code has changed? Potential ClassCastException in CasPool --- Key: UIMA-1499 URL: https://issues.apache.org/jira/browse/UIMA-1499 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.3 Reporter: Jörn Kottmann Fix For: 2.3 The CasPool has a constructor CasPool(int aNumInstances, Collection aComponentDescriptionsOrMetaData, Properties aPerformanceTuningSettings, ResourceManager aResourceManager) where aComponentDescriptionsOrMetaData is a collection which can contain according to javadoc AnalysisEngineDescription, CollectionReaderDescription, CasConsumerDescription or ProcessingResourceMetaData objects A reference of the Collection is passed to fillPool which passes the Collection to a CasDefinition constructor which then casts everything to ProcessingResourceMetaData, which will result in a ClassCastException in the case of AnalysisEngineDescription, CollectionReaderDescription and CasConsumerDescription objects. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1496) Generics for CasCreationUtils
[
https://issues.apache.org/jira/browse/UIMA-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörn Kottmann closed UIMA-1496.
---
Resolution: Fixed
UimaTypeSystem2Ecore was changed from
CasCreationUtils.mergeTypeSystems(Arrays.asList(new Object[] { aTypeSystem }))
to
CasCreationUtils.mergeTypeSystems(Arrays.asList(new TypeSystemDescription[] {
aTypeSystem }))
to fix this issue.
Generics for CasCreationUtils
-
Key: UIMA-1496
URL: https://issues.apache.org/jira/browse/UIMA-1496
Project: UIMA
Issue Type: Improvement
Components: Core Java Framework
Affects Versions: 2.3
Reporter: Jörn Kottmann
Assignee: Jörn Kottmann
Fix For: 2.3
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Ontology Annotator to the sandbox
Hi Jörn, Yes, I just remembered that the documentation was also on the website as well. Here is also the link to the demo application that we developed for ASU Embryo Project that used the tool. The tool was pointed to manually curated ontologies by domain experts in Purble Sea Urchin and annotated the each MEDLINE abstract with the Concepts, Organizations and People entities. You will see the terms highlighted when you click on the abstracts provided: http://enuvis07.fulton.asu.edu:3000/abstracts/ Please let me know if you have any further questions. Ahmed On Tue, Aug 18, 2009 at 3:41 AM, Jörn Kottmann kottm...@gmail.com wrote: Ahmed Abdeen Hamed wrote: Attached is the documentation to the old version and I will point you a PEAR file once I finish refactoring. You cannot send attachments to this list. http://obo-annotator.svn.sourceforge.net/viewvc/obo-annotator/obo-annotator/OBO-Annotator.pdf?view=log Is this the link to the documentation you attached ? Jörn
Re: generics: additionalParams
Jörn Kottmann wrote: The additionalParams Map has a String key and can contains all kinds of Objects, so the correct generification would be MapString, Object. In the uima code base I found one invocation where a Properties object was passed as additionalParams. Properties is a MapObject, Object which will cause compile errors in user code when they use a Properties object to pass in the additional params. I don't think its common practice to use Properties for additional params. If we fix the one found use cited above, are there any other cases where instances of Properties are passed as additionalParams in our own code? What do we think is the likelyhood that users will use Properties as instances of additional params? Our documentation says See the Javadocs for info on the additional parameters. The Javadocs say this is a Map ... Valid parameter names are defined as constants on the XYZ Interface ... and in that interface, these constants are Strings. But users might decide to represent these parameters in a properties file. Here are some considerations (apologies if I get this wrong - please correct): - If we declare as Object, Object, then you cannot assign a MapString, Object to the parameter. - Having the key of the map be an Object is more general, and would accommodate Properties. - declaring as String, Object - cannot assign new Properties() to it any more, unless you do the double-fisted cast (MapString,Object)(Object) If that is the trade off, I think I would rather have it be String, Object. -Marshall Should we change it anyway and add a known issue to our release notes ? Jörn
ACTION NEEDED: PearPackagingMavenPlugin moved in SVN per Jira UIMA-1497
If you have it checked out, please switch to the new location: https://svn.apache.org/repos/asf/incubator/uima/uimaj/trunk/PearPackagingMavenPlugin -Marshall
Re: generics: additionalParams
Marshall Schor wrote: Jörn Kottmann wrote: The additionalParams Map has a String key and can contains all kinds of Objects, so the correct generification would be MapString, Object. In the uima code base I found one invocation where a Properties object was passed as additionalParams. Properties is a MapObject, Object which will cause compile errors in user code when they use a Properties object to pass in the additional params. I don't think its common practice to use Properties for additional params. If we fix the one found use cited above, are there any other cases where instances of Properties are passed as additionalParams in our own code? There was only one case in the uimaj code base (I did not check sandbox). What do we think is the likelyhood that users will use Properties as instances of additional params? Our documentation says See the Javadocs for info on the additional parameters. The Javadocs say this is a Map ... Valid parameter names are defined as constants on the XYZ Interface ... and in that interface, these constants are Strings. But users might decide to represent these parameters in a properties file. Here are some considerations (apologies if I get this wrong - please correct): - If we declare as Object, Object, then you cannot assign a MapString, Object to the parameter. - Having the key of the map be an Object is more general, and would accommodate Properties. If you prefer the option to have an Object as key the map could be declared as Map?, ?. Having a map which contains objects of an unkown type has the disadvantage that it is not possible to insert new objects, which is something we do frequently in our implementations. Jörn
[jira] Reopened: (UIMA-1292) Uima AS Jms Listener Should Support Retry When Establishing Connection To a Broker
[ https://issues.apache.org/jira/browse/UIMA-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik reopened UIMA-1292: - Spring listener does not detect Broker failures and subsequent Broker restart. If the broker dies, spring does not notify the uima AS service of the failure. Broker restart is not recognized by spring leading to a dead service. Investigate if there is a way in spring to detect broker failure and subsequent restart. Uima AS Jms Listener Should Support Retry When Establishing Connection To a Broker -- Key: UIMA-1292 URL: https://issues.apache.org/jira/browse/UIMA-1292 Project: UIMA Issue Type: Bug Components: Async Scaleout Reporter: Jerry Cwiklik Assignee: Jerry Cwiklik UIMA AS service should support retry when a listener on the service input queue fails due to a broker not being available. The listener should log a message stating the fact that the broker is not available and it should enter a loop attempting to reconnect. When a broker becomes available the listener should reconnect, log a message that the connection was made, and proceed to complete initialization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: generics: additionalParams
Jörn Kottmann wrote: Marshall Schor wrote: Jörn Kottmann wrote: The additionalParams Map has a String key and can contains all kinds of Objects, so the correct generification would be MapString, Object. In the uima code base I found one invocation where a Properties object was passed as additionalParams. Properties is a MapObject, Object which will cause compile errors in user code when they use a Properties object to pass in the additional params. I don't think its common practice to use Properties for additional params. If we fix the one found use cited above, are there any other cases where instances of Properties are passed as additionalParams in our own code? There was only one case in the uimaj code base (I did not check sandbox). What do we think is the likelyhood that users will use Properties as instances of additional params? Our documentation says See the Javadocs for info on the additional parameters. The Javadocs say this is a Map ... Valid parameter names are defined as constants on the XYZ Interface ... and in that interface, these constants are Strings. But users might decide to represent these parameters in a properties file. Here are some considerations (apologies if I get this wrong - please correct): - If we declare as Object, Object, then you cannot assign a MapString, Object to the parameter. - Having the key of the map be an Object is more general, and would accommodate Properties. If you prefer the option to have an Object as key the map could be declared as Map?, ?. Having a map which contains objects of an unkown type has the disadvantage that it is not possible to insert new objects, which is something we do frequently in our implementations. hmmm, yes, that would seem to be a pretty strong reason not to use that form ;-) -Marshall Jörn
Re: generics: additionalParams
Marshall Schor wrote: Jörn Kottmann wrote: The additionalParams Map has a String key and can contains all kinds of Objects, so the correct generification would be MapString, Object. In the uima code base I found one invocation where a Properties object was passed as additionalParams. Properties is a MapObject, Object which will cause compile errors in user code when they use a Properties object to pass in the additional params. I don't think its common practice to use Properties for additional params. If we fix the one found use cited above, are there any other cases where instances of Properties are passed as additionalParams in our own code? What do we think is the likelyhood that users will use Properties as instances of additional params? Our documentation says See the Javadocs for info on the additional parameters. The Javadocs say this is a Map ... Valid parameter names are defined as constants on the XYZ Interface ... and in that interface, these constants are Strings. But users might decide to represent these parameters in a properties file. Here are some considerations (apologies if I get this wrong - please correct): - If we declare as Object, Object, then you cannot assign a MapString, Object to the parameter. - Having the key of the map be an Object is more general, and would accommodate Properties. - declaring as String, Object - cannot assign new Properties() to it any more, unless you do the double-fisted cast (MapString,Object)(Object) If that is the trade off, I think I would rather have it be String, Object. +1 from me for MapString, Object Jörn
pear packaging maven plugin documentation question
The current docs for the pear packaging maven plugin say that you need to make your project depend on the plugin, by adding it to the dependency set of your project that is using it. I don't think this is correct. I think that the maven plugin tools are specified separately from the project dependencies. So, it should not be required to add anything to a project's dependency set for this. Instead, you would just need to include it in the build ... plugins plugin section. Is this right? -Marshall
