Kepler: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362010-02-05T04:56:18ZEcoinformatics Redmine
Redmine Bug #4740 (New): Create Ontology_Catalog sql table in the CORE persistent databasehttps://projects.ecoinformatics.org/ecoinfo/issues/47402010-02-05T04:56:18ZAaron Aaronaschultz@nceas.ucsb.edu
<p>I ran into our old friend, the "Cannot Find Ontology" error. After much time trying to debug through the OntologyConfiguration and OntologyCatalog classes I discovered that the way the owl files are being accessed is very fragile and thus causes this error (which I was finally able to reproduce by ant clean-cache). The issue is how the absolute paths are being created to find the owl files. I would suggest we create a database table in the persistent core database that has four columns: ID, NAME, PATH, and LIBRARY. The PATH is the fully qualified absolute path to the OWL file on the system that Kepler is running on (so we don't have to keep trying to figure out what the absolute path is in the Java code every time we want to get to the owl file).</p>
<p>The new catalog system would work like this:<br />1.) Default owl files (that are shipped with Kepler) are defined in Java code and inserted into the table the first time Kepler is started using the fully qualified absolute path for whatever system Kepler is running on<br />2.) Tagging (or other modules) can then add ontologies to the sql table (thus not having to overwrite the ontology_catalog.xml file directly as is done now)<br />3.) The user can then edit the the catalog through a gui interface (as opposed to editing the ontology_catalog.xml file as is done now)</p> Bug #4584 (New): CacheManager.getObject(KeplerLSID lsid) returns an object with the wrong LSIDhttps://projects.ecoinformatics.org/ecoinfo/issues/45842009-11-25T21:03:15ZAaron Aaronaschultz@nceas.ucsb.edu
<p>It seems that objects returned by the CacheManager.getObject(KeplerLSID lsid) method do not always have the right LSID... There is a lot of funny translation and things going on with the CacheObjects. This mechanism of storing a serialized CacheObject that contains metadata about the object in addition to the object itself is inherently fragile. I would propose that we do away with CacheObjects and use the SQL database to store metadata about objects and serialize them directly to files (instead of serializing their CacheObject counterparts). This would greatly reduce the complexity of the system.</p> Bug #4153 (In Progress): report-overrideshttps://projects.ecoinformatics.org/ecoinfo/issues/41532009-06-12T21:04:56ZAaron Aaronaschultz@nceas.ucsb.edu
<p>"ant report-overrides" build target does not include xml files (such as config.xml or configuration.xml).</p>