Metacat: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362010-03-23T18:09:49ZEcoinformatics Redmine
Redmine Bug #4900 (Resolved): LDAP referral connection timeouthttps://projects.ecoinformatics.org/ecoinfo/issues/49002010-03-23T18:09:49Zben leinfelderleinfelder@nceas.ucsb.edu
<p>When trying to authenticate with a SANParks username from Metacat hosts that point to ldap.ecoinformatics.org, the authentication fails (localhost, saeonocean, knb, dev). When authenticating through the sanparks.org ldap with a SANParks username, the authentication is successful.<br />This points to an issue in the referral handling.</p>
<p>Upon further investigation, it appears that the AMNH referral (ldap.biodiversityinformatics.amnh.org:636) is causing the problem:<br />-------------<br />knb 20100323-11:01:11: [WARN]: AuthLdap.ldapAuthenticate - Trying to authenticate: uid=test,o=SANParks,dc=ecoinformatics,dc=org Using server: ldap://ldap.ecoinformatics.org:389/ [edu.ucsb.nceas.metacat.AuthLdap]<br />knb 20100323-11:01:11: [WARN]: Authentication exception: [LDAP: error code 49 - Invalid Credentials] [edu.ucsb.nceas.metacat.AuthLdap]<br />knb 20100323-11:01:11: [WARN]: AuthLdap.getIdentifyingName - Searching for DNs with following filter: (&(uid=test)(o=SANParks)) [edu.ucsb.nceas.metacat.AuthLdap]<br />knb 20100323-11:02:26: [ERROR]: AuthLdap.getIdentifyingName - Naming exception while getting dn: javax.naming.CommunicationException: ldap.biodiversityinformatics.amnh.org:636 [Root exception is java.net.ConnectException: Operation timed out] [edu.ucsb.nceas.metacat.AuthLdap]<br />knb 20100323-11:02:26: [ERROR]: AuthLdap.authenticate - Naming exception while authenticating in AuthLdap.authenticate: javax.naming.NamingException: Naming exception in AuthLdap.getIdentifyingName: javax.naming.CommunicationException: ldap.biodiversityinformatics.amnh.org:636 [Root exception is java.net.ConnectException: Operation timed out] [edu.ucsb.nceas.metacat.AuthLdap]<br />javax.naming.NamingException: Naming exception in AuthLdap.getIdentifyingName: javax.naming.CommunicationException: ldap.biodiversityinformatics.amnh.org:636 [Root exception is java.net.ConnectException: Operation timed out]<br /> at edu.ucsb.nceas.metacat.AuthLdap.getIdentifyingName(AuthLdap.java:411)<br /> at edu.ucsb.nceas.metacat.AuthLdap.authenticate(AuthLdap.java:158)<br /> at edu.ucsb.nceas.metacat.AuthSession.authenticate(AuthSession.java:84)<br /> at edu.ucsb.nceas.metacat.MetacatHandler.handleLoginAction(MetacatHandler.java:345)<br /> at edu.ucsb.nceas.metacat.MetaCatServlet.handleGetOrPost(MetaCatServlet.java:776)<br /> at edu.ucsb.nceas.metacat.MetaCatServlet.doPost(MetaCatServlet.java:489)<br /> at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)<br />......................</p> Bug #4871 (Resolved): Need a new tag for utilities module on Metacat 1.9.2 releasehttps://projects.ecoinformatics.org/ecoinfo/issues/48712010-03-05T01:02:05ZJing Taotao@nceas.ucsb.edu
<p>I just fixed bug 4866. <a class="external" href="http://bugzilla.ecoinformatics.org/show_bug.cgi?id=4866">http://bugzilla.ecoinformatics.org/show_bug.cgi?id=4866</a></p>
<p>This fix involves the change on DateUtil class of utilities module. Currently the fix is the trunk. So we should create a new tag on utitlities and use this tag on our metacat build process.</p> Bug #4866 (Resolved): The date displaying on Workflow Run Schedule is incorrecthttps://projects.ecoinformatics.org/ecoinfo/issues/48662010-03-03T23:33:51ZJing Taotao@nceas.ucsb.edu
<p>I tried to schedule a workflow run on the scheduler interface. The start time is 03/03/2010 15:30:00 and end time is 03/03/2010 17:00:00. After clicking Schedule button, the result shows:</p>
<p>Start Time End Time<br />30/03/10 15:30:00 PST 00/03/10 17:00:00 PST</p>
<p>So the date displaying is incorrect. However, on 03/03/2010 15:30:00 the workflow did a run. So it is just displaying problem.</p> Bug #4850 (Resolved): Get the new TPC scheduler working with the new changes in Kepler from the K...https://projects.ecoinformatics.org/ecoinfo/issues/48502010-02-26T18:36:31ZJing Taotao@nceas.ucsb.edu
<p>On kepler side, the metadata format to describe the workflow kar file and workflow run files was changed. So TPC scheduler should be changed accordingly.</p> Bug #4841 (Resolved): Review page for new data registration omits spatial/temporal infohttps://projects.ecoinformatics.org/ecoinfo/issues/48412010-02-24T23:57:55ZJim Regetzregetz@nceas.ucsb.edu
<p>Both for the ESA and NCEAS data registries, information entered in the temporal coverage and spatial coverage sections does <strong>not</strong> appear on the review page that appears after submitting the initial registration form. This seems like an oversight, as all other fields on the form are presented for review.</p> Bug #4839 (Resolved): Fix URL in "revision notification" email sent to ESA moderatorshttps://projects.ecoinformatics.org/ecoinfo/issues/48392010-02-24T22:33:40ZJim Regetzregetz@nceas.ucsb.edu
<p>The "revise document" notification that gets sent to ESA moderators after requesting a revision contains a URL like this:</p>
<p><a class="external" href="http://esa-dev.nceas.ucsb.edu/esa/cgi-bin/register-dataset.cgi?stage=modify&cfg=esa&docid=esa.65">http://esa-dev.nceas.ucsb.edu/esa/cgi-bin/register-dataset.cgi?stage=modify&cfg=esa&docid=esa.65</a></p>
<p>It probably shouldn't specify stage=modify, because the moderator is unlikely to want to modify the document at this point. A simple view action for the document would be more appropriate.</p>
<p>Alternatively, it would probably be sufficient to omit the URL altogether, and instead just indicate the docid and include a link to the ESA registry home page as a convenience.</p> Bug #4838 (Resolved): Permissions error for link contained in Data Set Citation sectionhttps://projects.ecoinformatics.org/ecoinfo/issues/48382010-02-24T22:24:33ZJim Regetzregetz@nceas.ucsb.edu
<p>It's easiest to describe this by documenting the steps to reproduce. This involves ESA, but I haven't checked whether it happens with non-public documents viewed using other registries.</p>
<p>After logging into ESA, click My Submissions (or View Submissions if logged in as a moderator), then click to view any one of the listed documents. Note that these are all documents that are <strong>not</strong> publicly readable, but should be readable by the logged-in user. The Data Set Citation section near the top of the document contains a link that refers to the document itself, e.g.: <a class="external" href="http://esa-dev.nceas.ucsb.edu/esa/metacat/esa.65.3/esa">http://esa-dev.nceas.ucsb.edu/esa/metacat/esa.65.3/esa</a></p>
<p>Clicking on the link produces an error:</p>
<p>--------------------------------<br />This XML file does not appear to have any style information associated with it. The document tree is shown below.</p>
<p><error><br />User public does not have permission to read the document with the docid esa.65.3<br /></error><br />--------------------------------</p>
<p>The underlying URL for the example above is:<br /><a class="external" href="http://esa-dev.nceas.ucsb.edu/esa/metacat?action=read&qformat=esa&sessionid=&docid=esa.65.3">http://esa-dev.nceas.ucsb.edu/esa/metacat?action=read&qformat=esa&sessionid=&docid=esa.65.3</a></p>
<p>Perhaps the issue is the missing session variable?</p> Bug #4837 (Resolved): Permission error when ESA moderator attempts to modify a documenthttps://projects.ecoinformatics.org/ecoinfo/issues/48372010-02-24T22:11:12ZJim Regetzregetz@nceas.ucsb.edu
<p>The "Revise document" notification emailed to moderators currently contains a URL that looks something like this:</p>
<p><a class="external" href="http://esa-dev.nceas.ucsb.edu/esa/cgi-bin/register-dataset.cgi?stage=modify&cfg=esa&docid=esa.65">http://esa-dev.nceas.ucsb.edu/esa/cgi-bin/register-dataset.cgi?stage=modify&cfg=esa&docid=esa.65</a></p>
<p>If already logged in as a moderator (and not the owner of this document), clicking this link produces the following:</p>
<p>---------------------------<br />Failure<br />An error occurred. Please check the list of errors below:</p>
<ul>
<li>You don't have permission to edit this document, which is owned by uid=test,o=NCEAS,dc=ecoinformatics,dc=org. (Access Error <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: some required elements should be optional (Resolved)" href="https://projects.ecoinformatics.org/ecoinfo/issues/3">#3</a>)<br />---------------------------</li>
</ul>
<p>ESA moderators, i.e. members of cn=esa-moderators,dc=ecoinformatics,dc=org, should have ALL permissions by default, so presumably they should be able to modify this document (and there may be times when they need to be able to do so).</p> Bug #4835 (Resolved): ESA review comments don't appear to users when viewing their documentshttps://projects.ecoinformatics.org/ecoinfo/issues/48352010-02-24T21:48:54ZJim Regetzregetz@nceas.ucsb.edu
<p>After the moderator enters review comments and sends a document back for revision, those comments are visible to the moderator in the left panel when viewing the document. However, when the original document submitter logs in and views that same document, the panel on the left reports "No reviews found".</p>
<p>I would imagine the submitter <strong>should</strong> be able to see the reviews, but in any case it certainly shouldn't say "No reviews found".</p> Bug #4834 (Resolved): Request to modify document redirects to registry home after loginhttps://projects.ecoinformatics.org/ecoinfo/issues/48342010-02-24T21:39:24ZJim Regetzregetz@nceas.ucsb.edu
<p>The "Revise document" notification emailed to document submitters currently contains a URL that looks something like this:</p>
<p><a class="external" href="http://esa-dev.nceas.ucsb.edu/esa/cgi-bin/register-dataset.cgi?stage=modify&cfg=esa&docid=esa.65">http://esa-dev.nceas.ucsb.edu/esa/cgi-bin/register-dataset.cgi?stage=modify&cfg=esa&docid=esa.65</a></p>
<p>This redirects to the login page if the user is not already logged in, which makes sense. However, after logging in, the user gets dumped back at the home page rather being presented with the requested page.</p>
<p>Not sure if this issue is specific to ESA.</p> Bug #4818 (Resolved): ESA does not send an email to moderators when new document is added via reg...https://projects.ecoinformatics.org/ecoinfo/issues/48182010-02-22T17:50:42ZMichael Daigledaigle@nceas.ucsb.edu
<p>The register-dataset.cgi does not send an email when a new document is created via the ESA skin. It used to, and still should.</p> Bug #4645 (Resolved): handleGetRevisionAndDocTypeAction should search both xml_documents and xml_...https://projects.ecoinformatics.org/ecoinfo/issues/46452010-01-04T22:30:28ZJing Taotao@nceas.ucsb.edu
<p>handleGetRevisionAndDocTypeAction API will return both revision and doctype for a given docid. Currently, it only searchs the xml_documents. It may gives clients a wrong message in this case:</p>
<p>There is no record in xml_documents, but it did have records in xml_revision table.</p>
<p>Here is the solution:</p>
<p>1. Search xml_documents table first. If metacat finds a result, returns it back to client.<br />2. If couldn't find result in xml_documents, then search xml_revisions table.</p> Bug #4641 (Resolved): must support java 1.6https://projects.ecoinformatics.org/ecoinfo/issues/46412009-12-19T01:57:22ZMatt Jonesjones@nceas.ucsb.edu
<p>Metacat currently runds under java 1.5.x, which is now at end-of-life for support. We must support JDK 1.6.x in the next release, and deprecate 1.5.x. This most likely involves changes to how we handle JDBC connections, and maybe a few other issues. If you know of additional compatibility issues, please list them here.</p> Bug #4637 (Resolved): Metacat Harvester fails to catch some insert and update failureshttps://projects.ecoinformatics.org/ecoinfo/issues/46372009-12-17T19:34:31ZDuane Costadcosta@lternet.edu
<p>Metacat Harvester is not catching all insert and update errors.</p>
<p>Recently at LTER, there have been a handful of documents that have been reported by Metacat Harvester as successful inserts or updates, but in fact the documents are not being successfully inserted or updated into Metacat. <br />The logical error is in method HarvesterDocument.putMetacatDocument(). The problem is that Harvester treats the absence of an exception as a success condition, when it should instead require hard confirmation of success from the Metacat client that the insert or update operation succeeded:</p>
<pre><code>if (harvester.connectToMetacat()) {<br /> try {<br /> if (insert) {<br /> metacatReturnString = metacat.insert(docidFull, stringReader, null);<br /> inserted = true;<br /> harvester.addLogEntry(0, docidFull + " : " + metacatReturnString, <br /> "harvester.InsertDocSuccess", <br /> harvestSiteSchedule.siteScheduleID, <br /> null, "");<br /> }<br /> else if (update) {<br /> metacatReturnString = metacat.update(docidFull, stringReader, null);<br /> updated = true;<br /> harvester.addLogEntry(0, docidFull + " : " + metacatReturnString, <br /> "harvester.UpdateDocSuccess", <br /> harvestSiteSchedule.siteScheduleID, <br /> null, "");<br /> }<br /> }<br /> catch (MetacatInaccessibleException e) {<br /> logMetacatError(insert, metacatReturnString, <br /> "MetacatInaccessibleException", e);<br /> }<br /> catch (InsufficientKarmaException e) {<br /> logMetacatError(insert, metacatReturnString, <br /> "InsufficientKarmaException", e);<br /> }<br /> catch (MetacatException e) {<br /> logMetacatError(insert, metacatReturnString, "MetacatException", e);<br /> }<br /> catch (IOException e) {<br /> logMetacatError(insert, metacatReturnString, "IOException", e);<br /> }</code></pre>
<p>Harvester does not check the value of the string returned by Metacat ('metacatReturnString' in the above code). In the cases where the insert/update operations have been failing, the return string is empty or null. Harvester should examine the return string to confirm that it contains the substring "<success>" or something similar.</p>
<p>The fact that no exception is thrown by Metacat could point to an additional problem in Metacat, since the insert/update operation completes without raising an exception even though the document is not inserted or updated. The documents that appear to trigger this condition are unusually large EML documents (currently there are three documents from CDR and one document from LUQ that trigger this bug).</p>
<p>After the Harvester bug is resolved, or as part of resolving it, further investigation should be done to determine whether there is also a Metacat bug involved here, and if there is, a separate bug entry should be entered for it.</p> Bug #4367 (Resolved): metacat didn't update xml_path_index table while a document was updatedhttps://projects.ecoinformatics.org/ecoinfo/issues/43672009-09-04T17:09:51ZJing Taotao@nceas.ucsb.edu
<p>Hi Jing:</p>
<pre><code>Marissa Bauer, working on the POD project, created a new data package<br /> using Morpho - she has created about 25 of them so far. The latest<br /> accession # is mbauer.42.9.</code></pre>
<pre><code>Unlike the rest of the packages, this one is not included in the results of<br /> an NCEAS Data Repository search on the string 'POD!'. KNB portal<br /> and Morpho searches both to find the package.</code></pre>
<pre><code>Initially, Marissa did not include an organizationName field with NCEAS: 12192<br /> string in it,so I added that with the Morpho editor.</code></pre>
<pre><code>In any case, can you take a look at the DP (mbauer.42.9) and let me know what might be missing?</code></pre>
<pre><code>Thanks,<br /> Rick R</code></pre>
<pre><code>Hi, Rick:</code></pre>
<pre><code>Since you can find the mbauer.42.9 by searching in knb page and morpho, I thought this is a nceas skin filter issue. I looked the<br /> mbauser.42.9 and found it has the filter - organizationName="National Center for Ecological Analysis and Synthesis". I am confused<br /> - NCEAS skin should find it.</code></pre>
<pre><code>I carefully checked the nceas skin sql query and the metacat database, it turned out that xml_path_index table hasn't been updated<br /> since mbauer.42.5. When I run "select * from xml_path_index where docid like 'mbauer.42';", I got:</code></pre>
<pre><code>4196745 | mbauer.42 | @packageId | � � � � � � � � 0 | � �304886418 | mbauer.42.5<br /> .......<br /> 4196773 | mbauer.42 | organizationName | � � � � � � � � 0 | � �304886527 | NCEAS<br /> .......</code></pre>
<pre><code>You see, in xml_path_index table, the organizationName is "NCEAS", rather than "National Center for Ecological Analysis and<br /> Synthesis", so the nceas skin query couldn't catch the docid. Also we can see the package id is still mbauer.42.5. But the package<br /> id is mbauer.42.9 in document mbauer.42.9.</code></pre>
<pre><code>So I think it is a metacat bug - the xml_path_index table wasn't updated while the document was updated. In your case, the current<br /> document is mbauser.42.9, but the in xml_path_index is still mbuaser.42.5.</code></pre>