You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oodt.apache.org by "Mattmann, Chris A (3980)" <ch...@jpl.nasa.gov> on 2014/08/03 20:05:38 UTC

Re: trunk filemgr busted

Guys I finally figured out what was wrong here! There was a patch
sitting all along to fix it!! ahhh!

It was trunk RADIX that was broken and it was OODT-690, evil bug
where a metadata end tag was missing from the product metadata
tag in GenericFile! Ahhh!!

https://issues.apache.org/jira/browse/OODT-690


Committed it finally. Thanks for checking!

Cheers,
Chris


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattmann@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++






-----Original Message-----
From: Lewis John Mcgibbney <le...@gmail.com>
Reply-To: "dev@oodt.apache.org" <de...@oodt.apache.org>
Date: Saturday, June 28, 2014 10:57 AM
To: "dev@oodt.apache.org" <de...@oodt.apache.org>
Subject: Re: trunk filemgr busted

>Hi Chris,
>
>On Sat, Jun 28, 2014 at 8:08 AM, Mattmann, Chris A (3980) <
>chris.a.mattmann@jpl.nasa.gov> wrote:
>
>>
>> On DARPA XDATA, I built a new RADIX-based system for processing an
>> employment dataset using 0.7-radix (trunk). I then created a set of
>> policy for the File Manager for employment datasets containing ~4
>> product types, etc. I then tried to start file manager. It was up and
>> running, but would keep giving me NPEs when trying to get ProductTypes
>> (look them up), and then wouldn't ingest, etc.
>>
>
>Can this be related to Rishi's issue here?
>https://issues.apache.org/jira/browse/OODT-686
>
>
>>   So there seems to be something in
>> 0.7 filemgr that wouldn't read my policy correctly and I was wondering
>>if
>> it had to do with the updates you were making (maybe it didn't).
>>
>
>OK lets go deeper.
>CHANGES TO FILEMGR/SRC/MAIN/JAVA
>
>http://svn.apache.org/viewvc/oodt/trunk/filemgr/src/main/java/org/apache/o
>odt/cas/filemgr/catalog/DataSourceCatalog.java?r1=1603049&r2=1604981&diff_
>format=h
>
>http://svn.apache.org/viewvc/oodt/trunk/filemgr/src/main/java/org/apache/o
>odt/cas/filemgr/datatransfer/LocalDataTransferer.java?r1=1603049&r2=160498
>1
>
>http://svn.apache.org/viewvc/oodt/trunk/filemgr/src/main/java/org/apache/o
>odt/cas/filemgr/ingest/CmdLineIngester.java?r1=1603049&r2=1604981&diff_for
>mat=h
>
>http://svn.apache.org/viewvc/oodt/trunk/filemgr/src/main/java/org/apache/o
>odt/cas/filemgr/repository/XMLRepositoryManager.java?r1=1603049&r2=1604981
>
>http://svn.apache.org/viewvc/oodt/trunk/filemgr/src/main/java/org/apache/o
>odt/cas/filemgr/structs/exceptions/RepositoryManagerException.java?r1=1603
>049&r2=1604981&diff_format=h
>
>http://svn.apache.org/viewvc/oodt/trunk/filemgr/src/main/java/org/apache/o
>odt/cas/filemgr/system/XmlRpcFileManager.java?r1=1603049&r2=1604981
>
>http://svn.apache.org/viewvc/oodt/trunk/filemgr/src/main/java/org/apache/o
>odt/cas/filemgr/system/XmlRpcFileManagerClient.java?r1=1603049&r2=1604981&
>diff_format=h
>
>http://svn.apache.org/viewvc/oodt/trunk/filemgr/src/main/java/org/apache/o
>odt/cas/filemgr/util/GenericFileManagerObjectFactory.java?r1=1603049&r2=16
>04981&diff_format=h
>
>http://svn.apache.org/viewvc/oodt/trunk/filemgr/src/main/java/org/apache/o
>odt/cas/filemgr/util/XmlRpcStructFactory.java?r1=1603049&r2=1604981&diff_f
>ormat=h
>
>http://svn.apache.org/viewvc/oodt/trunk/filemgr/src/main/java/org/apache/o
>odt/cas/filemgr/util/XmlStructFactory.java?r1=1603049&r2=1604981&diff_form
>at=h
>
>if you have the time to look at the above diffs, you will see that nothing
>has been changed with respect to semantics of the code. All the commit
>addressed was javac warnings and some Javadoc substantiation.
>
>
>
>>
>> One thing I did wonder though is that does the trunk filemgr still
>>produce
>> a tgz when running mvn install?
>
>
>I was under the impression that .zip files were the only concrete
>distributable source artifacts from OODT.
>This would be reflected in what was published in 0.6 release
>http://apache.mirrors.pair.com/oodt/
>This being said, I still get one generated when I run mvn install
>
>lmcgibbn@LMC-032857 /usr/local/oodt/filemgr(master) $ cd target/
>.plxarc                               classes/
>site/
>archive-tmp/                          generated-sources/
>surefire/
>cas-filemgr-0.7-SNAPSHOT-dist.tar.gz  javadoc-bundle-options/
>surefire-reports/
>cas-filemgr-0.7-SNAPSHOT-dist.zip     maven-archiver/
>test-classes/
>cas-filemgr-0.7-SNAPSHOT.jar          maven-shared-archive-resources/
>
>
>
>> It didn't seem to anymore for me and if it
>> doesn't (per the test updates) that should be fixed/reverted since we
>>need
>> to produce a tgz on mvn install (so those get published to the Central
>> repo).
>> Are you seeing this too?
>>
>>
>No, I'm not able to reproduce Chris... I think we need to look more
>closely
>at this to converge on whats wrong here.