NS

Nate Solas

Fri, Mar 23, 2012 3:59 PM

I'm totally stuck. I've been working with our customized codebase trying to
run imports and have had some extremely weird and frustrating behavior.
I'll run an import of 10 collection objects, everything looks right, but
nothing shows up in the cspace admin. Incredibly, sometimes I will see the
objects in the nuxeo database, but un-recognized by cspace services
apparently. Other times nothing will show up but another import of the same
data will work. I've restarted tomcat between attempts, wped the database,
and tried both the old and new curl import commands (
http://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home).
I seemed to have more success with the old, deprecated one, but that was
running into the "fail silently" bug all the time.

I finally installed the patched ImportsResource.java from
http://issues.collectionspace.org/browse/CSPACE-4866 to see if that helps,
and it's the same behavior. I reverted all of our changes and am running a
vanilla Collectionspace 2.0 (with Aron's patch), and now it's failing every
time. Per that ticket I'm trying the dirt-simplest xml import I can think
of, the objectexit one, and... nothing. I've even tried it with the old
syntax and without Aron's patch which didn't work the first time, then I
restarted tomcat, tried the new (2.1 and below) syntax: fail. Tried the old
one again (curl -X) and it worked! Seeing that things were behaving I tried
my 10 objects again (which HAVE worked at times in the past) and it failed
(silently).

I guess this relates to the recent thread about testing imports. I've been
going nuts for a few days on this, trying to eliminate all the variables on
my end, tweaking xml generators, etc, and now as I read more it seems like
there are just a bunch of known "random glitches" with the imports?

Any tips? More info below:

curl http://localhost:8180/cspace-services/imports?type=xml -i -u
admin@core.collectionspace.org:Administrator -F
"file=@objectexit-utf8.xml;type=application/xml"

catalina.out looks like:
Created ThreadLocal instance: java.lang.ThreadLocal - null
Setting ThreadLocal instance: java.lang.ThreadLocal -
javax.security.auth.login.LoginContext@1f5173f
Preamble type is:
Media type is:application/xml
############## TEMPLATE_DIR:
/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/cspace/config/services/resources/templates
##############
OUTPUT_DIR:/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca
====Path============
/imports/import[0]
====Context=========

====Fragment========

<schema xmlns:objectexit_common="

http://collectionspace.org/services/objectexit" name="objectexit_common">
<exitNote>This OBJECT has been declared a World Heritage Nuisance and
must be disposed of forthwith - Sebastián</exitNote>
<exitNumber>OE2010.2</exitNumber>
</schema>

===================

Making directory:
/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9
====TemplateExpander DONE============

<imports> <import service="ObjectExit" type="ObjectExit"/> </imports> ================ importTree reading file: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca exists? true ~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml ~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml :: DONE

I'm totally stuck. I've been working with our customized codebase trying to run imports and have had some extremely weird and frustrating behavior. I'll run an import of 10 collection objects, everything looks right, but nothing shows up in the cspace admin. Incredibly, sometimes I will see the objects in the nuxeo database, but un-recognized by cspace services apparently. Other times nothing will show up but another import of the same data will work. I've restarted tomcat between attempts, wped the database, and tried both the old and new curl import commands ( http://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home). I seemed to have more success with the old, deprecated one, but that was running into the "fail silently" bug all the time. I finally installed the patched ImportsResource.java from http://issues.collectionspace.org/browse/CSPACE-4866 to see if that helps, and it's the same behavior. I reverted all of our changes and am running a vanilla Collectionspace 2.0 (with Aron's patch), and now it's failing every time. Per that ticket I'm trying the dirt-simplest xml import I can think of, the objectexit one, and... nothing. I've even tried it with the old syntax and without Aron's patch which didn't work the first time, then I restarted tomcat, tried the new (2.1 and below) syntax: fail. Tried the old one again (curl -X) and it worked! Seeing that things were behaving I tried my 10 objects again (which HAVE worked at times in the past) and it failed (silently). I guess this relates to the recent thread about testing imports. I've been going nuts for a few days on this, trying to eliminate all the variables on my end, tweaking xml generators, etc, and now as I read more it seems like there are just a bunch of known "random glitches" with the imports? Any tips? More info below: curl http://localhost:8180/cspace-services/imports?type=xml -i -u admin@core.collectionspace.org:Administrator -F "file=@objectexit-utf8.xml;type=application/xml" catalina.out looks like: Created ThreadLocal instance: java.lang.ThreadLocal - null Setting ThreadLocal instance: java.lang.ThreadLocal - javax.security.auth.login.LoginContext@1f5173f Preamble type is: Media type is:application/xml ############## TEMPLATE_DIR: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/cspace/config/services/resources/templates ############## OUTPUT_DIR:/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca ====Path============ /imports/import[0] ====Context========= <imports> <import service="ObjectExit" type="ObjectExit"/> </imports> ====Fragment======== <schema xmlns:objectexit_common=" http://collectionspace.org/services/objectexit" name="objectexit_common"> <exitNote>This OBJECT has been declared a World Heritage Nuisance and must be disposed of forthwith - Sebastián</exitNote> <exitNumber>OE2010.2</exitNumber> </schema> =================== Making directory: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9 ====TemplateExpander DONE============ <imports> <import service="ObjectExit" type="ObjectExit"/> </imports> ================ importTree reading file: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca exists? true ~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml ~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml :: DONE

CH

Chris Hoffman

Fri, Mar 23, 2012 4:21 PM

Hi Nate,

I have been there too, so I completely sympathize. I see in your object exit fragment that you have an accented character, which should be fine but has been the cause of some problems elsewhere. Have you tried importing that same record but without the accented character? Could you send your import file to us, and we'll try loading on one of our stacks?

Thanks,
Chris

On Mar 23, 2012, at 8:59 AM, Nate Solas wrote:

I'm totally stuck. I've been working with our customized codebase trying to run imports and have had some extremely weird and frustrating behavior. I'll run an import of 10 collection objects, everything looks right, but nothing shows up in the cspace admin. Incredibly, sometimes I will see the objects in the nuxeo database, but un-recognized by cspace services apparently. Other times nothing will show up but another import of the same data will work. I've restarted tomcat between attempts, wped the database, and tried both the old and new curl import commands (http://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home). I seemed to have more success with the old, deprecated one, but that was running into the "fail silently" bug all the time.

I finally installed the patched ImportsResource.java from http://issues.collectionspace.org/browse/CSPACE-4866 to see if that helps, and it's the same behavior. I reverted all of our changes and am running a vanilla Collectionspace 2.0 (with Aron's patch), and now it's failing every time. Per that ticket I'm trying the dirt-simplest xml import I can think of, the objectexit one, and... nothing. I've even tried it with the old syntax and without Aron's patch which didn't work the first time, then I restarted tomcat, tried the new (2.1 and below) syntax: fail. Tried the old one again (curl -X) and it worked! Seeing that things were behaving I tried my 10 objects again (which HAVE worked at times in the past) and it failed (silently).

I guess this relates to the recent thread about testing imports. I've been going nuts for a few days on this, trying to eliminate all the variables on my end, tweaking xml generators, etc, and now as I read more it seems like there are just a bunch of known "random glitches" with the imports?

Any tips? More info below:

curl http://localhost:8180/cspace-services/imports?type=xml -i -u admin@core.collectionspace.org:Administrator -F "file=@objectexit-utf8.xml;type=application/xml"

catalina.out looks like:
Created ThreadLocal instance: java.lang.ThreadLocal - null
Setting ThreadLocal instance: java.lang.ThreadLocal - javax.security.auth.login.LoginContext@1f5173f
Preamble type is:
Media type is:application/xml
############## TEMPLATE_DIR: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/cspace/config/services/resources/templates
############## OUTPUT_DIR:/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca
====Path============
/imports/import[0]
====Context=========

====Fragment========

 <schema xmlns:objectexit_common="http://collectionspace.org/services/objectexit" name="objectexit_common">
   <exitNote>This OBJECT has been declared a World Heritage Nuisance and must be disposed of forthwith - Sebastián</exitNote>
   <exitNumber>OE2010.2</exitNumber>
 </schema>

===================

Making directory: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9
====TemplateExpander DONE============

<imports> <import service="ObjectExit" type="ObjectExit"/> </imports> ================ importTree reading file: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca exists? true ~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml ~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml :: DONE

Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Hi Nate, I have been there too, so I completely sympathize. I see in your object exit fragment that you have an accented character, which should be fine but has been the cause of some problems elsewhere. Have you tried importing that same record but without the accented character? Could you send your import file to us, and we'll try loading on one of our stacks? Thanks, Chris On Mar 23, 2012, at 8:59 AM, Nate Solas wrote: > I'm totally stuck. I've been working with our customized codebase trying to run imports and have had some extremely weird and frustrating behavior. I'll run an import of 10 collection objects, everything looks right, but nothing shows up in the cspace admin. Incredibly, sometimes I will see the objects in the nuxeo database, but un-recognized by cspace services apparently. Other times nothing will show up but another import of the same data will work. I've restarted tomcat between attempts, wped the database, and tried both the old and new curl import commands (http://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home). I seemed to have more success with the old, deprecated one, but that was running into the "fail silently" bug all the time. > > I finally installed the patched ImportsResource.java from http://issues.collectionspace.org/browse/CSPACE-4866 to see if that helps, and it's the same behavior. I reverted all of our changes and am running a vanilla Collectionspace 2.0 (with Aron's patch), and now it's failing every time. Per that ticket I'm trying the dirt-simplest xml import I can think of, the objectexit one, and... nothing. I've even tried it with the old syntax and without Aron's patch which didn't work the first time, then I restarted tomcat, tried the new (2.1 and below) syntax: fail. Tried the old one again (curl -X) and it worked! Seeing that things were behaving I tried my 10 objects again (which HAVE worked at times in the past) and it failed (silently). > > I guess this relates to the recent thread about testing imports. I've been going nuts for a few days on this, trying to eliminate all the variables on my end, tweaking xml generators, etc, and now as I read more it seems like there are just a bunch of known "random glitches" with the imports? > > Any tips? More info below: > > curl http://localhost:8180/cspace-services/imports?type=xml -i -u admin@core.collectionspace.org:Administrator -F "file=@objectexit-utf8.xml;type=application/xml" > > catalina.out looks like: > Created ThreadLocal instance: java.lang.ThreadLocal - null > Setting ThreadLocal instance: java.lang.ThreadLocal - javax.security.auth.login.LoginContext@1f5173f > Preamble type is: > Media type is:application/xml > ############## TEMPLATE_DIR: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/cspace/config/services/resources/templates > ############## OUTPUT_DIR:/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca > ====Path============ > /imports/import[0] > ====Context========= > > <imports> > <import service="ObjectExit" type="ObjectExit"/> > </imports> > > ====Fragment======== > > <schema xmlns:objectexit_common="http://collectionspace.org/services/objectexit" name="objectexit_common"> > <exitNote>This OBJECT has been declared a World Heritage Nuisance and must be disposed of forthwith - Sebastián</exitNote> > <exitNumber>OE2010.2</exitNumber> > </schema> > > =================== > > Making directory: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9 > ====TemplateExpander DONE============ > > <imports> > <import service="ObjectExit" type="ObjectExit"/> > </imports> > ================ > importTree reading file: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca exists? true > ~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml > ~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml :: DONE > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

NS

Nate Solas

Fri, Mar 23, 2012 4:57 PM

Sorry, that dump was from the patched 2.0 that accepts utf-8. When working
with the unpatched clean 2.0 setup I'm using just ascii. My latest
mind-blowing scenario goes like this:

If i restart tomcat and then alternate import commands, sometimes one will
work. If it doesn't work after two tries I start over.

[restart tomcat]
curl http://localhost:8180/cspace-services/imports?type=xml -i -u
admin@core.collectionspace.org:Administrator -F
"file=@cs_import.xml;type=text/xml"
curl -X POST http://localhost:8180/cspace-services/imports -i -u
"admin@core.collectionspace.org:Administrator" -H "Content-Type:
application/xml" -T cs_import.xml
go back to 1 and eventually it will import.

Unpatched 2.0. Is this typical?

I can send you some files to test, but I've tried to eliminate every
possible variable so my base test is just this:

<?xml version="1.0" encoding="utf-8"?> <imports> <import service="ObjectExit" type="ObjectExit"> <schema xmlns:objectexit_common=" http://collectionspace.org/services/objectexit" name="objectexit_common"> <exitNote>This USASCII OBJECT has been declared a World Heritage Nuisance and must be disposed of forthwith - Sebastian</exitNote> <exitNumber>OE2010.3</exitNumber> </schema> </import> </imports>

Nate

On Fri, Mar 23, 2012 at 11:21 AM, Chris Hoffman
chris.hoffman@berkeley.eduwrote:

Hi Nate,

I have been there too, so I completely sympathize. I see in your object
exit fragment that you have an accented character, which should be fine but
has been the cause of some problems elsewhere. Have you tried importing
that same record but without the accented character? Could you send your
import file to us, and we'll try loading on one of our stacks?

Thanks,
Chris

On Mar 23, 2012, at 8:59 AM, Nate Solas wrote:

I'm totally stuck. I've been working with our customized codebase trying
to run imports and have had some extremely weird and frustrating behavior.
I'll run an import of 10 collection objects, everything looks right, but
nothing shows up in the cspace admin. Incredibly, sometimes I will see the
objects in the nuxeo database, but un-recognized by cspace services
apparently. Other times nothing will show up but another import of the same
data will work. I've restarted tomcat between attempts, wped the database,
and tried both the old and new curl import commands (
http://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home).
I seemed to have more success with the old, deprecated one, but that was
running into the "fail silently" bug all the time.

I finally installed the patched ImportsResource.java from
http://issues.collectionspace.org/browse/CSPACE-4866 to see if that
helps, and it's the same behavior. I reverted all of our changes and am
running a vanilla Collectionspace 2.0 (with Aron's patch), and now it's
failing every time. Per that ticket I'm trying the dirt-simplest xml import
I can think of, the objectexit one, and... nothing. I've even tried it with
the old syntax and without Aron's patch which didn't work the first time,
then I restarted tomcat, tried the new (2.1 and below) syntax: fail. Tried
the old one again (curl -X) and it worked! Seeing that things were behaving
I tried my 10 objects again (which HAVE worked at times in the past) and it
failed (silently).

I guess this relates to the recent thread about testing imports. I've been
going nuts for a few days on this, trying to eliminate all the variables on
my end, tweaking xml generators, etc, and now as I read more it seems like
there are just a bunch of known "random glitches" with the imports?

Any tips? More info below:

curl http://localhost:8180/cspace-services/imports?type=xml -i -u
admin@core.collectionspace.org:Administrator -F "file=@objectexit-utf8.xml
;type=application/xml"

catalina.out looks like:
Created ThreadLocal instance: java.lang.ThreadLocal - null
Setting ThreadLocal instance: java.lang.ThreadLocal -
javax.security.auth.login.LoginContext@1f5173f
Preamble type is:
Media type is:application/xml
############## TEMPLATE_DIR:
/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/cspace/config/services/resources/templates
##############
OUTPUT_DIR:/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca
====Path============
/imports/import[0]
====Context=========

====Fragment========

 <schema xmlns:objectexit_common="

http://collectionspace.org/services/objectexit" name="objectexit_common">
<exitNote>This OBJECT has been declared a World Heritage Nuisance
and must be disposed of forthwith - Sebastián</exitNote>
<exitNumber>OE2010.2</exitNumber>
</schema>

===================

Making directory:
/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9
====TemplateExpander DONE============

<imports> <import service="ObjectExit" type="ObjectExit"/> </imports> ================ importTree reading file: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca exists? true ~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml ~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml :: DONE

Talk mailing list
Talk@lists.collectionspace.org

http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Sorry, that dump was from the patched 2.0 that accepts utf-8. When working with the unpatched clean 2.0 setup I'm using just ascii. My latest mind-blowing scenario goes like this: If i restart tomcat and then alternate import commands, sometimes one will work. If it doesn't work after two tries I start over. 1. [restart tomcat] 2. curl http://localhost:8180/cspace-services/imports?type=xml -i -u admin@core.collectionspace.org:Administrator -F "file=@cs_import.xml;type=text/xml" 3. curl -X POST http://localhost:8180/cspace-services/imports -i -u "admin@core.collectionspace.org:Administrator" -H "Content-Type: application/xml" -T cs_import.xml 4. go back to 1 and eventually it will import. Unpatched 2.0. Is this typical? I can send you some files to test, but I've tried to eliminate every possible variable so my base test is just this: <?xml version="1.0" encoding="utf-8"?> <imports> <import service="ObjectExit" type="ObjectExit"> <schema xmlns:objectexit_common=" http://collectionspace.org/services/objectexit" name="objectexit_common"> <exitNote>This USASCII OBJECT has been declared a World Heritage Nuisance and must be disposed of forthwith - Sebastian</exitNote> <exitNumber>OE2010.3</exitNumber> </schema> </import> </imports> Nate On Fri, Mar 23, 2012 at 11:21 AM, Chris Hoffman <chris.hoffman@berkeley.edu>wrote: > Hi Nate, > > I have been there too, so I completely sympathize. I see in your object > exit fragment that you have an accented character, which should be fine but > has been the cause of some problems elsewhere. Have you tried importing > that same record but without the accented character? Could you send your > import file to us, and we'll try loading on one of our stacks? > > Thanks, > Chris > > > On Mar 23, 2012, at 8:59 AM, Nate Solas wrote: > > I'm totally stuck. I've been working with our customized codebase trying > to run imports and have had some extremely weird and frustrating behavior. > I'll run an import of 10 collection objects, everything looks right, but > nothing shows up in the cspace admin. Incredibly, sometimes I will see the > objects in the nuxeo database, but un-recognized by cspace services > apparently. Other times nothing will show up but another import of the same > data will work. I've restarted tomcat between attempts, wped the database, > and tried both the old and new curl import commands ( > http://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home). > I seemed to have more success with the old, deprecated one, but that was > running into the "fail silently" bug all the time. > > I finally installed the patched ImportsResource.java from > http://issues.collectionspace.org/browse/CSPACE-4866 to see if that > helps, and it's the same behavior. I reverted all of our changes and am > running a vanilla Collectionspace 2.0 (with Aron's patch), and now it's > failing every time. Per that ticket I'm trying the dirt-simplest xml import > I can think of, the objectexit one, and... nothing. I've even tried it with > the old syntax and without Aron's patch which didn't work the first time, > then I restarted tomcat, tried the new (2.1 and below) syntax: fail. Tried > the old one again (curl -X) and it worked! Seeing that things were behaving > I tried my 10 objects again (which HAVE worked at times in the past) and it > failed (silently). > > I guess this relates to the recent thread about testing imports. I've been > going nuts for a few days on this, trying to eliminate all the variables on > my end, tweaking xml generators, etc, and now as I read more it seems like > there are just a bunch of known "random glitches" with the imports? > > Any tips? More info below: > > curl http://localhost:8180/cspace-services/imports?type=xml -i -u > admin@core.collectionspace.org:Administrator -F "file=@objectexit-utf8.xml > ;type=application/xml" > > catalina.out looks like: > Created ThreadLocal instance: java.lang.ThreadLocal - null > Setting ThreadLocal instance: java.lang.ThreadLocal - > javax.security.auth.login.LoginContext@1f5173f > Preamble type is: > Media type is:application/xml > ############## TEMPLATE_DIR: > /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/cspace/config/services/resources/templates > ############## > OUTPUT_DIR:/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca > ====Path============ > /imports/import[0] > ====Context========= > > <imports> > <import service="ObjectExit" type="ObjectExit"/> > </imports> > > ====Fragment======== > > <schema xmlns:objectexit_common=" > http://collectionspace.org/services/objectexit" name="objectexit_common"> > <exitNote>This OBJECT has been declared a World Heritage Nuisance > and must be disposed of forthwith - Sebastián</exitNote> > <exitNumber>OE2010.2</exitNumber> > </schema> > > =================== > > Making directory: > /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9 > ====TemplateExpander DONE============ > > <imports> > <import service="ObjectExit" type="ObjectExit"/> > </imports> > ================ > importTree reading file: > /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca > exists? true > ~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: > /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml > ~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: > /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml > :: DONE > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > >

RL

Ray Lee

Fri, Mar 23, 2012 5:12 PM

Hi Nate,
On 2.0 there are four bugs related to import, and two files to
patch.

CSPACE-4817 is not fixed.
CSPACE-4866 is fixed, in
ImportsResource.java
CSPACE-3911 is fixed, in
ImportsResource.java
CSPACE-4807 is fixed, in ImportsResource.java and
nuxeo/ImportCommand.java

Basically, if you replace ImportsResource.java
and nuxeo/ImportCommand.java with the latest in master, you'll have the
patches.

At that point, you should use the 2.2 syntax (not the 2.1 and
below, because now the system is patched up to 2.2, as far as imports are
concerned). The deprecated syntax won't work reliably until CSPACE-4817 is
fixed.

It sounds like you may have missed patching
nuxeo/ImportCommand.java. I'll link CSPACE-4807 to the other jiras, so it's
easier to find. Let us know if that works!

Ray

On Fri, 23 Mar 2012
10:59:34 -0500, Nate Solas wrote:

I'm totally stuck. I've been working
with our customized codebase trying to run imports and have had some
extremely weird and frustrating behavior. I'll run an import of 10
collection objects, everything looks right, but nothing shows up in the
cspace admin. Incredibly, sometimes I will see the objects in the nuxeo
database, but un-recognized by cspace services apparently. Other times
nothing will show up but another import of the same data will work. I've
restarted tomcat between attempts, wped the database, and tried both the
old and new curl import commands
(http://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home
[1]). I seemed to have more success with the old, deprecated one, but that
was running into the "fail silently" bug all the time. I finally installed
the patched ImportsResource.java from
http://issues.collectionspace.org/browse/CSPACE-4866 [2] to see if that
helps, and it's the same behavior. I reverted all of our changes and am
running a vanilla Collectionspace 2.0 (with Aron's patch), and now it's
failing every time. Per that ticket I'm trying the dirt-simplest xml import
I can think of, the objectexit one, and... nothing. I've even tried it with
the old syntax and without Aron's patch which didn't work the first time,
then I restarted tomcat, tried the new (2.1 and below) syntax: fail. Tried
the old one again (curl -X) and it worked! Seeing that things were behaving
I tried my 10 objects again (which HAVE worked at times in the past) and it
failed (silently). I guess this relates to the recent thread about testing
imports. I've been going nuts for a few days on this, trying to eliminate
all the variables on my end, tweaking xml generators, etc, and now as I
read more it seems like there are just a bunch of known "random glitches"
with the imports? Any tips? More info below: curl
http://localhost:8180/cspace-services/imports?type=xml [3] -i -u
admin@core.collectionspace.org:Administrator -F
"file=@objectexit-utf8.xml;type=application/xml" catalina.out looks
like: Created ThreadLocal instance: java.lang.ThreadLocal - null Setting
ThreadLocal instance: java.lang.ThreadLocal -
javax.security.auth.login.LoginContext@1f5173f Preamble type is: Media type
is:application/xml ############## TEMPLATE_DIR:
/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/cspace/config/services/resources/templates
##############
OUTPUT_DIR:/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca
====Path============ /imports/import[0] ====Context=========
====Fragment======== http://collectionspace.org/services/objectexit"
name="objectexit_common"> This OBJECT has been declared a World Heritage
Nuisance and must be disposed of forthwith - Sebastián OE2010.2
=================== Making directory:
/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9
====TemplateExpander DONE============ ================ importTree
reading file:
/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca
exists? true ~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader ::
/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml

/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml
:: DONE     

 

Links:
------
[1]
http://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home
[2]
http://issues.collectionspace.org/browse/CSPACE-4866
[3]
http://localhost:8180/cspace-services/imports?type=xml

Hi Nate, On 2.0 there are four bugs related to import, and two files to patch. CSPACE-4817 is not fixed. CSPACE-4866 is fixed, in ImportsResource.java CSPACE-3911 is fixed, in ImportsResource.java CSPACE-4807 is fixed, in ImportsResource.java and nuxeo/ImportCommand.java Basically, if you replace ImportsResource.java and nuxeo/ImportCommand.java with the latest in master, you'll have the patches. At that point, you should use the 2.2 syntax (not the 2.1 and below, because now the system is patched up to 2.2, as far as imports are concerned). The deprecated syntax won't work reliably until CSPACE-4817 is fixed. It sounds like you may have missed patching nuxeo/ImportCommand.java. I'll link CSPACE-4807 to the other jiras, so it's easier to find. Let us know if that works! Ray On Fri, 23 Mar 2012 10:59:34 -0500, Nate Solas wrote: I'm totally stuck. I've been working with our customized codebase trying to run imports and have had some extremely weird and frustrating behavior. I'll run an import of 10 collection objects, everything looks right, but nothing shows up in the cspace admin. Incredibly, sometimes I will see the objects in the nuxeo database, but un-recognized by cspace services apparently. Other times nothing will show up but another import of the same data will work. I've restarted tomcat between attempts, wped the database, and tried both the old and new curl import commands (http://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home [1]). I seemed to have more success with the old, deprecated one, but that was running into the "fail silently" bug all the time. I finally installed the patched ImportsResource.java from http://issues.collectionspace.org/browse/CSPACE-4866 [2] to see if that helps, and it's the same behavior. I reverted all of our changes and am running a vanilla Collectionspace 2.0 (with Aron's patch), and now it's failing every time. Per that ticket I'm trying the dirt-simplest xml import I can think of, the objectexit one, and... nothing. I've even tried it with the old syntax and without Aron's patch which didn't work the first time, then I restarted tomcat, tried the new (2.1 and below) syntax: fail. Tried the old one again (curl -X) and it worked! Seeing that things were behaving I tried my 10 objects again (which HAVE worked at times in the past) and it failed (silently). I guess this relates to the recent thread about testing imports. I've been going nuts for a few days on this, trying to eliminate all the variables on my end, tweaking xml generators, etc, and now as I read more it seems like there are just a bunch of known "random glitches" with the imports? Any tips? More info below: curl http://localhost:8180/cspace-services/imports?type=xml [3] -i -u admin@core.collectionspace.org:Administrator -F "file=@objectexit-utf8.xml;type=application/xml" catalina.out looks like: Created ThreadLocal instance: java.lang.ThreadLocal - null Setting ThreadLocal instance: java.lang.ThreadLocal - javax.security.auth.login.LoginContext@1f5173f Preamble type is: Media type is:application/xml ############## TEMPLATE_DIR: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/cspace/config/services/resources/templates ############## OUTPUT_DIR:/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca ====Path============ /imports/import[0] ====Context========= ====Fragment======== http://collectionspace.org/services/objectexit" name="objectexit_common"> This OBJECT has been declared a World Heritage Nuisance and must be disposed of forthwith - Sebastián OE2010.2 =================== Making directory: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9 ====TemplateExpander DONE============ ================ importTree reading file: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca exists? true ~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml ~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml :: DONE Links: ------ [1] http://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home [2] http://issues.collectionspace.org/browse/CSPACE-4866 [3] http://localhost:8180/cspace-services/imports?type=xml

NS

Nate Solas

Fri, Mar 23, 2012 5:41 PM

Ray, you the man. Imports seem to work like a charm now.

...Can't believe I didn't find that ticket. Should we not be working with
2.0 at all?

Nate

On Fri, Mar 23, 2012 at 12:12 PM, Ray Lee rhlee@berkeley.edu wrote:

Hi Nate,
On 2.0 there are four bugs related to import, and two files to patch.

CSPACE-4817 is not fixed.
CSPACE-4866 is fixed, in ImportsResource.java
CSPACE-3911 is fixed, in ImportsResource.java
CSPACE-4807 is fixed, in ImportsResource.java and nuxeo/ImportCommand.java

Basically, if you replace ImportsResource.java and
nuxeo/ImportCommand.java with the latest in master, you'll have the patches.

At that point, you should use the 2.2 syntax (not the 2.1 and below,
because now the system is patched up to 2.2, as far as imports are
concerned). The deprecated syntax won't work reliably until CSPACE-4817 is
fixed.

It sounds like you may have missed patching nuxeo/ImportCommand.java. I'll
link CSPACE-4807 to the other jiras, so it's easier to find. Let us know if
that works!

Ray

On Fri, 23 Mar 2012 10:59:34 -0500, Nate Solas nate.solas@walkerart.org
wrote:

I'm totally stuck. I've been working with our customized codebase trying
to run imports and have had some extremely weird and frustrating behavior.
I'll run an import of 10 collection objects, everything looks right, but
nothing shows up in the cspace admin. Incredibly, sometimes I will see the
objects in the nuxeo database, but un-recognized by cspace services
apparently. Other times nothing will show up but another import of the same
data will work. I've restarted tomcat between attempts, wped the database,
and tried both the old and new curl import commands (
http://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home).
I seemed to have more success with the old, deprecated one, but that was
running into the "fail silently" bug all the time.
I finally installed the patched ImportsResource.java from
http://issues.collectionspace.org/browse/CSPACE-4866 to see if that
helps, and it's the same behavior. I reverted all of our changes and am
running a vanilla Collectionspace 2.0 (with Aron's patch), and now it's
failing every time. Per that ticket I'm trying the dirt-simplest xml import
I can think of, the objectexit one, and... nothing. I've even tried it with
the old syntax and without Aron's patch which didn't work the first time,
then I restarted tomcat, tried the new (2.1 and below) syntax: fail. Tried
the old one again (curl -X) and it worked! Seeing that things were behaving
I tried my 10 objects again (which HAVE worked at times in the past) and it
failed (silently).
I guess this relates to the recent thread about testing imports. I've
been going nuts for a few days on this, trying to eliminate all the
variables on my end, tweaking xml generators, etc, and now as I read more
it seems like there are just a bunch of known "random glitches" with the
imports?
Any tips? More info below:
curl http://localhost:8180/cspace-services/imports?type=xml -i -u
admin@core.collectionspace.org:Administrator -F
"file=@objectexit-utf8.xml;type=application/xml"
catalina.out looks like:
Created ThreadLocal instance: java.lang.ThreadLocal - null
Setting ThreadLocal instance: java.lang.ThreadLocal -
javax.security.auth.login.LoginContext@1f5173f
Preamble type is:
Media type is:application/xml
############## TEMPLATE_DIR:
/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/cspace/config/services/resources/templates
##############
OUTPUT_DIR:/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca
====Path============
/imports/import[0]
====Context=========
====Fragment========
http://collectionspace.org/services/objectexit"
name="objectexit_common">
This OBJECT has been declared a World Heritage Nuisance and must be
disposed of forthwith - Sebastián
OE2010.2

===================
Making directory:
/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9
====TemplateExpander DONE============

importTree reading file:
/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca
exists? true
~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader ::
/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml
~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader ::
/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml
:: DONE

Ray, you the man. Imports seem to work like a charm now. ...Can't believe I didn't find that ticket. Should we not be working with 2.0 at all? Nate On Fri, Mar 23, 2012 at 12:12 PM, Ray Lee <rhlee@berkeley.edu> wrote: > Hi Nate, > On 2.0 there are four bugs related to import, and two files to patch. > > CSPACE-4817 is not fixed. > CSPACE-4866 is fixed, in ImportsResource.java > CSPACE-3911 is fixed, in ImportsResource.java > CSPACE-4807 is fixed, in ImportsResource.java and nuxeo/ImportCommand.java > > Basically, if you replace ImportsResource.java and > nuxeo/ImportCommand.java with the latest in master, you'll have the patches. > > At that point, you should use the 2.2 syntax (not the 2.1 and below, > because now the system is patched up to 2.2, as far as imports are > concerned). The deprecated syntax won't work reliably until CSPACE-4817 is > fixed. > > It sounds like you may have missed patching nuxeo/ImportCommand.java. I'll > link CSPACE-4807 to the other jiras, so it's easier to find. Let us know if > that works! > > Ray > > > > On Fri, 23 Mar 2012 10:59:34 -0500, Nate Solas <nate.solas@walkerart.org> > wrote: > > I'm totally stuck. I've been working with our customized codebase trying > to run imports and have had some extremely weird and frustrating behavior. > I'll run an import of 10 collection objects, everything looks right, but > nothing shows up in the cspace admin. Incredibly, sometimes I will see the > objects in the nuxeo database, but un-recognized by cspace services > apparently. Other times nothing will show up but another import of the same > data will work. I've restarted tomcat between attempts, wped the database, > and tried both the old and new curl import commands ( > http://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home). > I seemed to have more success with the old, deprecated one, but that was > running into the "fail silently" bug all the time. > I finally installed the patched ImportsResource.java from > http://issues.collectionspace.org/browse/CSPACE-4866 to see if that > helps, and it's the same behavior. I reverted all of our changes and am > running a vanilla Collectionspace 2.0 (with Aron's patch), and now it's > failing every time. Per that ticket I'm trying the dirt-simplest xml import > I can think of, the objectexit one, and... nothing. I've even tried it with > the old syntax and without Aron's patch which didn't work the first time, > then I restarted tomcat, tried the new (2.1 and below) syntax: fail. Tried > the old one again (curl -X) and it worked! Seeing that things were behaving > I tried my 10 objects again (which HAVE worked at times in the past) and it > failed (silently). > I guess this relates to the recent thread about testing imports. I've > been going nuts for a few days on this, trying to eliminate all the > variables on my end, tweaking xml generators, etc, and now as I read more > it seems like there are just a bunch of known "random glitches" with the > imports? > Any tips? More info below: > curl http://localhost:8180/cspace-services/imports?type=xml -i -u > admin@core.collectionspace.org:Administrator -F > "file=@objectexit-utf8.xml;type=application/xml" > catalina.out looks like: > Created ThreadLocal instance: java.lang.ThreadLocal - null > Setting ThreadLocal instance: java.lang.ThreadLocal - > javax.security.auth.login.LoginContext@1f5173f > Preamble type is: > Media type is:application/xml > ############## TEMPLATE_DIR: > /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/cspace/config/services/resources/templates > ############## > OUTPUT_DIR:/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca > ====Path============ > /imports/import[0] > ====Context========= > ====Fragment======== > http://collectionspace.org/services/objectexit" > name="objectexit_common"> > This OBJECT has been declared a World Heritage Nuisance and must be > disposed of forthwith - Sebastián > OE2010.2 > > > =================== > Making directory: > /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9 > ====TemplateExpander DONE============ > ================ > importTree reading file: > /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca > exists? true > ~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: > /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml > ~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: > /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml > :: DONE > > >

CH

Chris Hoffman

Fri, Mar 23, 2012 5:44 PM

Glad to hear it's working!! We're actually using 2.0 for several major installations right now, but we do have it patched, and patched, and patched… The demo.collectionspace.org site is not patched and has some significant bugs for instance with saving of relationships. That's a big one. You want to make sure you have that patch installed.

We will probably wait for 2.3 to do the next set of upgrades.

Chris

On Mar 23, 2012, at 10:41 AM, Nate Solas wrote:

Ray, you the man. Imports seem to work like a charm now.

...Can't believe I didn't find that ticket. Should we not be working with 2.0 at all?

Nate

On Fri, Mar 23, 2012 at 12:12 PM, Ray Lee rhlee@berkeley.edu wrote:
Hi Nate,
On 2.0 there are four bugs related to import, and two files to patch.

CSPACE-4817 is not fixed.
CSPACE-4866 is fixed, in ImportsResource.java
CSPACE-3911 is fixed, in ImportsResource.java
CSPACE-4807 is fixed, in ImportsResource.java and nuxeo/ImportCommand.java

Basically, if you replace ImportsResource.java and nuxeo/ImportCommand.java with the latest in master, you'll have the patches.

At that point, you should use the 2.2 syntax (not the 2.1 and below, because now the system is patched up to 2.2, as far as imports are concerned). The deprecated syntax won't work reliably until CSPACE-4817 is fixed.

It sounds like you may have missed patching nuxeo/ImportCommand.java. I'll link CSPACE-4807 to the other jiras, so it's easier to find. Let us know if that works!

Ray

On Fri, 23 Mar 2012 10:59:34 -0500, Nate Solas nate.solas@walkerart.org wrote:

I'm totally stuck. I've been working with our customized codebase trying to run imports and have had some extremely weird and frustrating behavior. I'll run an import of 10 collection objects, everything looks right, but nothing shows up in the cspace admin. Incredibly, sometimes I will see the objects in the nuxeo database, but un-recognized by cspace services apparently. Other times nothing will show up but another import of the same data will work. I've restarted tomcat between attempts, wped the database, and tried both the old and new curl import commands (http://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home). I seemed to have more success with the old, deprecated one, but that was running into the "fail silently" bug all the time.

I finally installed the patched ImportsResource.java from http://issues.collectionspace.org/browse/CSPACE-4866 to see if that helps, and it's the same behavior. I reverted all of our changes and am running a vanilla Collectionspace 2.0 (with Aron's patch), and now it's failing every time. Per that ticket I'm trying the dirt-simplest xml import I can think of, the objectexit one, and... nothing. I've even tried it with the old syntax and without Aron's patch which didn't work the first time, then I restarted tomcat, tried the new (2.1 and below) syntax: fail. Tried the old one again (curl -X) and it worked! Seeing that things were behaving I tried my 10 objects again (which HAVE worked at times in the past) and it failed (silently).
I guess this relates to the recent thread about testing imports. I've been going nuts for a few days on this, trying to eliminate all the variables on my end, tweaking xml generators, etc, and now as I read more it seems like there are just a bunch of known "random glitches" with the imports?
Any tips? More info below:
curl http://localhost:8180/cspace-services/imports?type=xml -i -u admin@core.collectionspace.org:Administrator -F "file=@objectexit-utf8.xml;type=application/xml"
catalina.out looks like:
Created ThreadLocal instance: java.lang.ThreadLocal - null
Setting ThreadLocal instance: java.lang.ThreadLocal - javax.security.auth.login.LoginContext@1f5173f
Preamble type is:
Media type is:application/xml
############## TEMPLATE_DIR: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/cspace/config/services/resources/templates
############## OUTPUT_DIR:/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca
====Path============
/imports/import[0]
====Context=========
====Fragment========
http://collectionspace.org/services/objectexit" name="objectexit_common">
This OBJECT has been declared a World Heritage Nuisance and must be disposed of forthwith - Sebastián
OE2010.2

===================
Making directory: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9
====TemplateExpander DONE============

importTree reading file: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca exists? true
~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml
~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml :: DONE

Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Glad to hear it's working!! We're actually using 2.0 for several major installations right now, but we do have it patched, and patched, and patched… The demo.collectionspace.org site is not patched and has some significant bugs for instance with saving of relationships. That's a big one. You want to make sure you have that patch installed. We will probably wait for 2.3 to do the next set of upgrades. Chris On Mar 23, 2012, at 10:41 AM, Nate Solas wrote: > Ray, you the man. Imports seem to work like a charm now. > > ...Can't believe I didn't find that ticket. Should we not be working with 2.0 at all? > > Nate > > On Fri, Mar 23, 2012 at 12:12 PM, Ray Lee <rhlee@berkeley.edu> wrote: > Hi Nate, > On 2.0 there are four bugs related to import, and two files to patch. > > CSPACE-4817 is not fixed. > CSPACE-4866 is fixed, in ImportsResource.java > CSPACE-3911 is fixed, in ImportsResource.java > CSPACE-4807 is fixed, in ImportsResource.java and nuxeo/ImportCommand.java > > Basically, if you replace ImportsResource.java and nuxeo/ImportCommand.java with the latest in master, you'll have the patches. > > At that point, you should use the 2.2 syntax (not the 2.1 and below, because now the system is patched up to 2.2, as far as imports are concerned). The deprecated syntax won't work reliably until CSPACE-4817 is fixed. > > It sounds like you may have missed patching nuxeo/ImportCommand.java. I'll link CSPACE-4807 to the other jiras, so it's easier to find. Let us know if that works! > > Ray > > > > On Fri, 23 Mar 2012 10:59:34 -0500, Nate Solas <nate.solas@walkerart.org> wrote: > > I'm totally stuck. I've been working with our customized codebase trying to run imports and have had some extremely weird and frustrating behavior. I'll run an import of 10 collection objects, everything looks right, but nothing shows up in the cspace admin. Incredibly, sometimes I will see the objects in the nuxeo database, but un-recognized by cspace services apparently. Other times nothing will show up but another import of the same data will work. I've restarted tomcat between attempts, wped the database, and tried both the old and new curl import commands (http://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home). I seemed to have more success with the old, deprecated one, but that was running into the "fail silently" bug all the time. > > I finally installed the patched ImportsResource.java from http://issues.collectionspace.org/browse/CSPACE-4866 to see if that helps, and it's the same behavior. I reverted all of our changes and am running a vanilla Collectionspace 2.0 (with Aron's patch), and now it's failing every time. Per that ticket I'm trying the dirt-simplest xml import I can think of, the objectexit one, and... nothing. I've even tried it with the old syntax and without Aron's patch which didn't work the first time, then I restarted tomcat, tried the new (2.1 and below) syntax: fail. Tried the old one again (curl -X) and it worked! Seeing that things were behaving I tried my 10 objects again (which HAVE worked at times in the past) and it failed (silently). > I guess this relates to the recent thread about testing imports. I've been going nuts for a few days on this, trying to eliminate all the variables on my end, tweaking xml generators, etc, and now as I read more it seems like there are just a bunch of known "random glitches" with the imports? > Any tips? More info below: > curl http://localhost:8180/cspace-services/imports?type=xml -i -u admin@core.collectionspace.org:Administrator -F "file=@objectexit-utf8.xml;type=application/xml" > catalina.out looks like: > Created ThreadLocal instance: java.lang.ThreadLocal - null > Setting ThreadLocal instance: java.lang.ThreadLocal - javax.security.auth.login.LoginContext@1f5173f > Preamble type is: > Media type is:application/xml > ############## TEMPLATE_DIR: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/cspace/config/services/resources/templates > ############## OUTPUT_DIR:/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca > ====Path============ > /imports/import[0] > ====Context========= > ====Fragment======== > http://collectionspace.org/services/objectexit" name="objectexit_common"> > This OBJECT has been declared a World Heritage Nuisance and must be disposed of forthwith - Sebastián > OE2010.2 > > > =================== > Making directory: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9 > ====TemplateExpander DONE============ > ================ > importTree reading file: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca exists? true > ~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml > ~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml :: DONE > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

RL

Ray Lee

Fri, Mar 23, 2012 6:06 PM

The relationship problem Chris mentioned is CSPACE-4783, and can be patched in 2.0/2.1 by replacing RelationDocumentModelHandler.java in the relations service with the 2.2 version.

I should also mention that while I said there were four bugs relating to import in 2.0, there are actually more. For example, CSPACE-4789 is still floating around. But those four were the ones we ran into most often.

Ray

On Mar 23, 2012, at 10:44 AM, Chris Hoffman wrote:

Glad to hear it's working!! We're actually using 2.0 for several major installations right now, but we do have it patched, and patched, and patched… The demo.collectionspace.org site is not patched and has some significant bugs for instance with saving of relationships. That's a big one. You want to make sure you have that patch installed.

We will probably wait for 2.3 to do the next set of upgrades.

Chris

On Mar 23, 2012, at 10:41 AM, Nate Solas wrote:

Ray, you the man. Imports seem to work like a charm now.

...Can't believe I didn't find that ticket. Should we not be working with 2.0 at all?

Nate

On Fri, Mar 23, 2012 at 12:12 PM, Ray Lee rhlee@berkeley.edu wrote:
Hi Nate,
On 2.0 there are four bugs related to import, and two files to patch.

CSPACE-4817 is not fixed.
CSPACE-4866 is fixed, in ImportsResource.java
CSPACE-3911 is fixed, in ImportsResource.java
CSPACE-4807 is fixed, in ImportsResource.java and nuxeo/ImportCommand.java

Basically, if you replace ImportsResource.java and nuxeo/ImportCommand.java with the latest in master, you'll have the patches.

At that point, you should use the 2.2 syntax (not the 2.1 and below, because now the system is patched up to 2.2, as far as imports are concerned). The deprecated syntax won't work reliably until CSPACE-4817 is fixed.

It sounds like you may have missed patching nuxeo/ImportCommand.java. I'll link CSPACE-4807 to the other jiras, so it's easier to find. Let us know if that works!

Ray

On Fri, 23 Mar 2012 10:59:34 -0500, Nate Solas nate.solas@walkerart.org wrote:

I'm totally stuck. I've been working with our customized codebase trying to run imports and have had some extremely weird and frustrating behavior. I'll run an import of 10 collection objects, everything looks right, but nothing shows up in the cspace admin. Incredibly, sometimes I will see the objects in the nuxeo database, but un-recognized by cspace services apparently. Other times nothing will show up but another import of the same data will work. I've restarted tomcat between attempts, wped the database, and tried both the old and new curl import commands (http://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home). I seemed to have more success with the old, deprecated one, but that was running into the "fail silently" bug all the time.

I finally installed the patched ImportsResource.java from http://issues.collectionspace.org/browse/CSPACE-4866 to see if that helps, and it's the same behavior. I reverted all of our changes and am running a vanilla Collectionspace 2.0 (with Aron's patch), and now it's failing every time. Per that ticket I'm trying the dirt-simplest xml import I can think of, the objectexit one, and... nothing. I've even tried it with the old syntax and without Aron's patch which didn't work the first time, then I restarted tomcat, tried the new (2.1 and below) syntax: fail. Tried the old one again (curl -X) and it worked! Seeing that things were behaving I tried my 10 objects again (which HAVE worked at times in the past) and it failed (silently).
I guess this relates to the recent thread about testing imports. I've been going nuts for a few days on this, trying to eliminate all the variables on my end, tweaking xml generators, etc, and now as I read more it seems like there are just a bunch of known "random glitches" with the imports?
Any tips? More info below:
curl http://localhost:8180/cspace-services/imports?type=xml -i -u admin@core.collectionspace.org:Administrator -F "file=@objectexit-utf8.xml;type=application/xml"
catalina.out looks like:
Created ThreadLocal instance: java.lang.ThreadLocal - null
Setting ThreadLocal instance: java.lang.ThreadLocal - javax.security.auth.login.LoginContext@1f5173f
Preamble type is:
Media type is:application/xml
############## TEMPLATE_DIR: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/cspace/config/services/resources/templates
############## OUTPUT_DIR:/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca
====Path============
/imports/import[0]
====Context=========
====Fragment========
http://collectionspace.org/services/objectexit" name="objectexit_common">
This OBJECT has been declared a World Heritage Nuisance and must be disposed of forthwith - Sebastián
OE2010.2

===================
Making directory: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9
====TemplateExpander DONE============

importTree reading file: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca exists? true
~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml
~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml :: DONE

Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

The relationship problem Chris mentioned is CSPACE-4783, and can be patched in 2.0/2.1 by replacing RelationDocumentModelHandler.java in the relations service with the 2.2 version. I should also mention that while I said there were four bugs relating to import in 2.0, there are actually more. For example, CSPACE-4789 is still floating around. But those four were the ones we ran into most often. Ray On Mar 23, 2012, at 10:44 AM, Chris Hoffman wrote: > Glad to hear it's working!! We're actually using 2.0 for several major installations right now, but we do have it patched, and patched, and patched… The demo.collectionspace.org site is not patched and has some significant bugs for instance with saving of relationships. That's a big one. You want to make sure you have that patch installed. > > We will probably wait for 2.3 to do the next set of upgrades. > > Chris > > On Mar 23, 2012, at 10:41 AM, Nate Solas wrote: > >> Ray, you the man. Imports seem to work like a charm now. >> >> ...Can't believe I didn't find that ticket. Should we not be working with 2.0 at all? >> >> Nate >> >> On Fri, Mar 23, 2012 at 12:12 PM, Ray Lee <rhlee@berkeley.edu> wrote: >> Hi Nate, >> On 2.0 there are four bugs related to import, and two files to patch. >> >> CSPACE-4817 is not fixed. >> CSPACE-4866 is fixed, in ImportsResource.java >> CSPACE-3911 is fixed, in ImportsResource.java >> CSPACE-4807 is fixed, in ImportsResource.java and nuxeo/ImportCommand.java >> >> Basically, if you replace ImportsResource.java and nuxeo/ImportCommand.java with the latest in master, you'll have the patches. >> >> At that point, you should use the 2.2 syntax (not the 2.1 and below, because now the system is patched up to 2.2, as far as imports are concerned). The deprecated syntax won't work reliably until CSPACE-4817 is fixed. >> >> It sounds like you may have missed patching nuxeo/ImportCommand.java. I'll link CSPACE-4807 to the other jiras, so it's easier to find. Let us know if that works! >> >> Ray >> >> >> >> On Fri, 23 Mar 2012 10:59:34 -0500, Nate Solas <nate.solas@walkerart.org> wrote: >> >> I'm totally stuck. I've been working with our customized codebase trying to run imports and have had some extremely weird and frustrating behavior. I'll run an import of 10 collection objects, everything looks right, but nothing shows up in the cspace admin. Incredibly, sometimes I will see the objects in the nuxeo database, but un-recognized by cspace services apparently. Other times nothing will show up but another import of the same data will work. I've restarted tomcat between attempts, wped the database, and tried both the old and new curl import commands (http://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home). I seemed to have more success with the old, deprecated one, but that was running into the "fail silently" bug all the time. >> >> I finally installed the patched ImportsResource.java from http://issues.collectionspace.org/browse/CSPACE-4866 to see if that helps, and it's the same behavior. I reverted all of our changes and am running a vanilla Collectionspace 2.0 (with Aron's patch), and now it's failing every time. Per that ticket I'm trying the dirt-simplest xml import I can think of, the objectexit one, and... nothing. I've even tried it with the old syntax and without Aron's patch which didn't work the first time, then I restarted tomcat, tried the new (2.1 and below) syntax: fail. Tried the old one again (curl -X) and it worked! Seeing that things were behaving I tried my 10 objects again (which HAVE worked at times in the past) and it failed (silently). >> I guess this relates to the recent thread about testing imports. I've been going nuts for a few days on this, trying to eliminate all the variables on my end, tweaking xml generators, etc, and now as I read more it seems like there are just a bunch of known "random glitches" with the imports? >> Any tips? More info below: >> curl http://localhost:8180/cspace-services/imports?type=xml -i -u admin@core.collectionspace.org:Administrator -F "file=@objectexit-utf8.xml;type=application/xml" >> catalina.out looks like: >> Created ThreadLocal instance: java.lang.ThreadLocal - null >> Setting ThreadLocal instance: java.lang.ThreadLocal - javax.security.auth.login.LoginContext@1f5173f >> Preamble type is: >> Media type is:application/xml >> ############## TEMPLATE_DIR: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/cspace/config/services/resources/templates >> ############## OUTPUT_DIR:/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca >> ====Path============ >> /imports/import[0] >> ====Context========= >> ====Fragment======== >> http://collectionspace.org/services/objectexit" name="objectexit_common"> >> This OBJECT has been declared a World Heritage Nuisance and must be disposed of forthwith - Sebastián >> OE2010.2 >> >> >> =================== >> Making directory: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9 >> ====TemplateExpander DONE============ >> ================ >> importTree reading file: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca exists? true >> ~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml >> ~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml :: DONE >> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >

NS

Nate Solas

Fri, Mar 23, 2012 6:38 PM

Thanks for tips, Ray, Chris, and Susan. I'll grab the relations service
update before that one gets me... Any other must-have patches I should add?
Thanks,
Nate

On Fri, Mar 23, 2012 at 1:06 PM, Ray Lee rhlee@berkeley.edu wrote:

The relationship problem Chris mentioned is CSPACE-4783, and can be
patched in 2.0/2.1 by replacing RelationDocumentModelHandler.java in the
relations service with the 2.2 version.

I should also mention that while I said there were four bugs relating to
import in 2.0, there are actually more. For example, CSPACE-4789 is still
floating around. But those four were the ones we ran into most often.

Ray

On Mar 23, 2012, at 10:44 AM, Chris Hoffman wrote:

Glad to hear it's working!! We're actually using 2.0 for several major
installations right now, but we do have it patched, and patched, and
patched… The demo.collectionspace.org site is not patched and has some
significant bugs for instance with saving of relationships. That's a big
one. You want to make sure you have that patch installed.

We will probably wait for 2.3 to do the next set of upgrades.

Chris

On Mar 23, 2012, at 10:41 AM, Nate Solas wrote:

Ray, you the man. Imports seem to work like a charm now.

...Can't believe I didn't find that ticket. Should we not be working with
2.0 at all?

Nate

On Fri, Mar 23, 2012 at 12:12 PM, Ray Lee rhlee@berkeley.edu wrote:

Hi Nate,
On 2.0 there are four bugs related to import, and two files to patch.

CSPACE-4817 is not fixed.
CSPACE-4866 is fixed, in ImportsResource.java
CSPACE-3911 is fixed, in ImportsResource.java
CSPACE-4807 is fixed, in ImportsResource.java and nuxeo/ImportCommand.java

Basically, if you replace ImportsResource.java and
nuxeo/ImportCommand.java with the latest in master, you'll have the patches.

At that point, you should use the 2.2 syntax (not the 2.1 and below,
because now the system is patched up to 2.2, as far as imports are
concerned). The deprecated syntax won't work reliably until CSPACE-4817 is
fixed.

It sounds like you may have missed patching nuxeo/ImportCommand.java.
I'll link CSPACE-4807 to the other jiras, so it's easier to find. Let us
know if that works!

Ray

On Fri, 23 Mar 2012 10:59:34 -0500, Nate Solas nate.solas@walkerart.org
wrote:

I'm totally stuck. I've been working with our customized codebase trying
to run imports and have had some extremely weird and frustrating behavior.
I'll run an import of 10 collection objects, everything looks right, but
nothing shows up in the cspace admin. Incredibly, sometimes I will see the
objects in the nuxeo database, but un-recognized by cspace services
apparently. Other times nothing will show up but another import of the same
data will work. I've restarted tomcat between attempts, wped the database,
and tried both the old and new curl import commands (
http://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home).
I seemed to have more success with the old, deprecated one, but that was
running into the "fail silently" bug all the time.
I finally installed the patched ImportsResource.java from
http://issues.collectionspace.org/browse/CSPACE-4866 to see if that
helps, and it's the same behavior. I reverted all of our changes and am
running a vanilla Collectionspace 2.0 (with Aron's patch), and now it's
failing every time. Per that ticket I'm trying the dirt-simplest xml import
I can think of, the objectexit one, and... nothing. I've even tried it with
the old syntax and without Aron's patch which didn't work the first time,
then I restarted tomcat, tried the new (2.1 and below) syntax: fail. Tried
the old one again (curl -X) and it worked! Seeing that things were behaving
I tried my 10 objects again (which HAVE worked at times in the past) and it
failed (silently).
I guess this relates to the recent thread about testing imports. I've
been going nuts for a few days on this, trying to eliminate all the
variables on my end, tweaking xml generators, etc, and now as I read more
it seems like there are just a bunch of known "random glitches" with the
imports?
Any tips? More info below:
curl http://localhost:8180/cspace-services/imports?type=xml -i -u
admin@core.collectionspace.org:Administrator -F "
file=@objectexit-utf8.xml;type=application/xml"
catalina.out looks like:
Created ThreadLocal instance: java.lang.ThreadLocal - null
Setting ThreadLocal instance: java.lang.ThreadLocal -
javax.security.auth.login.LoginContext@1f5173f
Preamble type is:
Media type is:application/xml
############## TEMPLATE_DIR:
/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/cspace/config/services/resources/templates
##############
OUTPUT_DIR:/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca
====Path============
/imports/import[0]
====Context=========
====Fragment========
http://collectionspace.org/services/objectexit"
name="objectexit_common">
This OBJECT has been declared a World Heritage Nuisance and must be
disposed of forthwith - Sebastián
OE2010.2

===================
Making directory:
/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9
====TemplateExpander DONE============

importTree reading file:
/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca
exists? true
~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader ::
/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml
~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader ::
/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml
:: DONE

Talk mailing list
Talk@lists.collectionspace.org

http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Thanks for tips, Ray, Chris, and Susan. I'll grab the relations service update before that one gets me... Any other must-have patches I should add? Thanks, Nate On Fri, Mar 23, 2012 at 1:06 PM, Ray Lee <rhlee@berkeley.edu> wrote: > The relationship problem Chris mentioned is CSPACE-4783, and can be > patched in 2.0/2.1 by replacing RelationDocumentModelHandler.java in the > relations service with the 2.2 version. > > I should also mention that while I said there were four bugs relating to > import in 2.0, there are actually more. For example, CSPACE-4789 is still > floating around. But those four were the ones we ran into most often. > > Ray > > > On Mar 23, 2012, at 10:44 AM, Chris Hoffman wrote: > > Glad to hear it's working!! We're actually using 2.0 for several major > installations right now, but we do have it patched, and patched, and > patched… The demo.collectionspace.org site is not patched and has some > significant bugs for instance with saving of relationships. That's a big > one. You want to make sure you have that patch installed. > > We will probably wait for 2.3 to do the next set of upgrades. > > Chris > > On Mar 23, 2012, at 10:41 AM, Nate Solas wrote: > > Ray, you the man. Imports seem to work like a charm now. > > ...Can't believe I didn't find that ticket. Should we not be working with > 2.0 at all? > > Nate > > On Fri, Mar 23, 2012 at 12:12 PM, Ray Lee <rhlee@berkeley.edu> wrote: > >> Hi Nate, >> On 2.0 there are four bugs related to import, and two files to patch. >> >> CSPACE-4817 is not fixed. >> CSPACE-4866 is fixed, in ImportsResource.java >> CSPACE-3911 is fixed, in ImportsResource.java >> CSPACE-4807 is fixed, in ImportsResource.java and nuxeo/ImportCommand.java >> >> Basically, if you replace ImportsResource.java and >> nuxeo/ImportCommand.java with the latest in master, you'll have the patches. >> >> At that point, you should use the 2.2 syntax (not the 2.1 and below, >> because now the system is patched up to 2.2, as far as imports are >> concerned). The deprecated syntax won't work reliably until CSPACE-4817 is >> fixed. >> >> It sounds like you may have missed patching nuxeo/ImportCommand.java. >> I'll link CSPACE-4807 to the other jiras, so it's easier to find. Let us >> know if that works! >> >> Ray >> >> >> >> On Fri, 23 Mar 2012 10:59:34 -0500, Nate Solas <nate.solas@walkerart.org> >> wrote: >> >> I'm totally stuck. I've been working with our customized codebase trying >> to run imports and have had some extremely weird and frustrating behavior. >> I'll run an import of 10 collection objects, everything looks right, but >> nothing shows up in the cspace admin. Incredibly, sometimes I will see the >> objects in the nuxeo database, but un-recognized by cspace services >> apparently. Other times nothing will show up but another import of the same >> data will work. I've restarted tomcat between attempts, wped the database, >> and tried both the old and new curl import commands ( >> http://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home). >> I seemed to have more success with the old, deprecated one, but that was >> running into the "fail silently" bug all the time. >> I finally installed the patched ImportsResource.java from >> http://issues.collectionspace.org/browse/CSPACE-4866 to see if that >> helps, and it's the same behavior. I reverted all of our changes and am >> running a vanilla Collectionspace 2.0 (with Aron's patch), and now it's >> failing every time. Per that ticket I'm trying the dirt-simplest xml import >> I can think of, the objectexit one, and... nothing. I've even tried it with >> the old syntax and without Aron's patch which didn't work the first time, >> then I restarted tomcat, tried the new (2.1 and below) syntax: fail. Tried >> the old one again (curl -X) and it worked! Seeing that things were behaving >> I tried my 10 objects again (which HAVE worked at times in the past) and it >> failed (silently). >> I guess this relates to the recent thread about testing imports. I've >> been going nuts for a few days on this, trying to eliminate all the >> variables on my end, tweaking xml generators, etc, and now as I read more >> it seems like there are just a bunch of known "random glitches" with the >> imports? >> Any tips? More info below: >> curl http://localhost:8180/cspace-services/imports?type=xml -i -u >> admin@core.collectionspace.org:Administrator -F " >> file=@objectexit-utf8.xml;type=application/xml" >> catalina.out looks like: >> Created ThreadLocal instance: java.lang.ThreadLocal - null >> Setting ThreadLocal instance: java.lang.ThreadLocal - >> javax.security.auth.login.LoginContext@1f5173f >> Preamble type is: >> Media type is:application/xml >> ############## TEMPLATE_DIR: >> /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/cspace/config/services/resources/templates >> ############## >> OUTPUT_DIR:/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca >> ====Path============ >> /imports/import[0] >> ====Context========= >> ====Fragment======== >> http://collectionspace.org/services/objectexit" >> name="objectexit_common"> >> This OBJECT has been declared a World Heritage Nuisance and must be >> disposed of forthwith - Sebastián >> OE2010.2 >> >> >> =================== >> Making directory: >> /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9 >> ====TemplateExpander DONE============ >> ================ >> importTree reading file: >> /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca >> exists? true >> ~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: >> /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml >> ~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: >> /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml >> :: DONE >> >> >> > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > > >

JM

Jesse Martinez

Fri, Mar 23, 2012 7:04 PM

I think it would be useful to list these patches for 2.0 on the Deployment
wiki space. MMI is using the 2.0 code base too until we adopt 2.3/2.4. Or
maybe create a JIRA filter for these patched and unpatched issues and link
it to the same page.

Jesse

On Fri, Mar 23, 2012 at 2:06 PM, Ray Lee rhlee@berkeley.edu wrote:

The relationship problem Chris mentioned is CSPACE-4783, and can be
patched in 2.0/2.1 by replacing RelationDocumentModelHandler.java in the
relations service with the 2.2 version.

I should also mention that while I said there were four bugs relating to
import in 2.0, there are actually more. For example, CSPACE-4789 is still
floating around. But those four were the ones we ran into most often.

Ray

On Mar 23, 2012, at 10:44 AM, Chris Hoffman wrote:

Glad to hear it's working!! We're actually using 2.0 for several major
installations right now, but we do have it patched, and patched, and
patched… The demo.collectionspace.org site is not patched and has some
significant bugs for instance with saving of relationships. That's a big
one. You want to make sure you have that patch installed.

We will probably wait for 2.3 to do the next set of upgrades.

Chris

On Mar 23, 2012, at 10:41 AM, Nate Solas wrote:

Ray, you the man. Imports seem to work like a charm now.

...Can't believe I didn't find that ticket. Should we not be working with
2.0 at all?

Nate

On Fri, Mar 23, 2012 at 12:12 PM, Ray Lee rhlee@berkeley.edu wrote:

Hi Nate,
On 2.0 there are four bugs related to import, and two files to patch.

CSPACE-4817 is not fixed.
CSPACE-4866 is fixed, in ImportsResource.java
CSPACE-3911 is fixed, in ImportsResource.java
CSPACE-4807 is fixed, in ImportsResource.java and nuxeo/ImportCommand.java

Basically, if you replace ImportsResource.java and
nuxeo/ImportCommand.java with the latest in master, you'll have the patches.

At that point, you should use the 2.2 syntax (not the 2.1 and below,
because now the system is patched up to 2.2, as far as imports are
concerned). The deprecated syntax won't work reliably until CSPACE-4817 is
fixed.

It sounds like you may have missed patching nuxeo/ImportCommand.java.
I'll link CSPACE-4807 to the other jiras, so it's easier to find. Let us
know if that works!

Ray

On Fri, 23 Mar 2012 10:59:34 -0500, Nate Solas nate.solas@walkerart.org
wrote:

I'm totally stuck. I've been working with our customized codebase trying
to run imports and have had some extremely weird and frustrating behavior.
I'll run an import of 10 collection objects, everything looks right, but
nothing shows up in the cspace admin. Incredibly, sometimes I will see the
objects in the nuxeo database, but un-recognized by cspace services
apparently. Other times nothing will show up but another import of the same
data will work. I've restarted tomcat between attempts, wped the database,
and tried both the old and new curl import commands (
http://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home).
I seemed to have more success with the old, deprecated one, but that was
running into the "fail silently" bug all the time.
I finally installed the patched ImportsResource.java from
http://issues.collectionspace.org/browse/CSPACE-4866 to see if that
helps, and it's the same behavior. I reverted all of our changes and am
running a vanilla Collectionspace 2.0 (with Aron's patch), and now it's
failing every time. Per that ticket I'm trying the dirt-simplest xml import
I can think of, the objectexit one, and... nothing. I've even tried it with
the old syntax and without Aron's patch which didn't work the first time,
then I restarted tomcat, tried the new (2.1 and below) syntax: fail. Tried
the old one again (curl -X) and it worked! Seeing that things were behaving
I tried my 10 objects again (which HAVE worked at times in the past) and it
failed (silently).
I guess this relates to the recent thread about testing imports. I've
been going nuts for a few days on this, trying to eliminate all the
variables on my end, tweaking xml generators, etc, and now as I read more
it seems like there are just a bunch of known "random glitches" with the
imports?
Any tips? More info below:
curl http://localhost:8180/cspace-services/imports?type=xml -i -u
admin@core.collectionspace.org:Administrator -F "
file=@objectexit-utf8.xml;type=application/xml"
catalina.out looks like:
Created ThreadLocal instance: java.lang.ThreadLocal - null
Setting ThreadLocal instance: java.lang.ThreadLocal -
javax.security.auth.login.LoginContext@1f5173f
Preamble type is:
Media type is:application/xml
############## TEMPLATE_DIR:
/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/cspace/config/services/resources/templates
##############
OUTPUT_DIR:/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca
====Path============
/imports/import[0]
====Context=========
====Fragment========
http://collectionspace.org/services/objectexit"
name="objectexit_common">
This OBJECT has been declared a World Heritage Nuisance and must be
disposed of forthwith - Sebastián
OE2010.2

===================
Making directory:
/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9
====TemplateExpander DONE============

importTree reading file:
/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca
exists? true
~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader ::
/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml
~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader ::
/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml
:: DONE

Talk mailing list
Talk@lists.collectionspace.org

http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Talk mailing list
Talk@lists.collectionspace.org

http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

I think it would be useful to list these patches for 2.0 on the Deployment wiki space. MMI is using the 2.0 code base too until we adopt 2.3/2.4. Or maybe create a JIRA filter for these patched and unpatched issues and link it to the same page. - Jesse On Fri, Mar 23, 2012 at 2:06 PM, Ray Lee <rhlee@berkeley.edu> wrote: > The relationship problem Chris mentioned is CSPACE-4783, and can be > patched in 2.0/2.1 by replacing RelationDocumentModelHandler.java in the > relations service with the 2.2 version. > > I should also mention that while I said there were four bugs relating to > import in 2.0, there are actually more. For example, CSPACE-4789 is still > floating around. But those four were the ones we ran into most often. > > Ray > > > On Mar 23, 2012, at 10:44 AM, Chris Hoffman wrote: > > Glad to hear it's working!! We're actually using 2.0 for several major > installations right now, but we do have it patched, and patched, and > patched… The demo.collectionspace.org site is not patched and has some > significant bugs for instance with saving of relationships. That's a big > one. You want to make sure you have that patch installed. > > We will probably wait for 2.3 to do the next set of upgrades. > > Chris > > On Mar 23, 2012, at 10:41 AM, Nate Solas wrote: > > Ray, you the man. Imports seem to work like a charm now. > > ...Can't believe I didn't find that ticket. Should we not be working with > 2.0 at all? > > Nate > > On Fri, Mar 23, 2012 at 12:12 PM, Ray Lee <rhlee@berkeley.edu> wrote: > >> Hi Nate, >> On 2.0 there are four bugs related to import, and two files to patch. >> >> CSPACE-4817 is not fixed. >> CSPACE-4866 is fixed, in ImportsResource.java >> CSPACE-3911 is fixed, in ImportsResource.java >> CSPACE-4807 is fixed, in ImportsResource.java and nuxeo/ImportCommand.java >> >> Basically, if you replace ImportsResource.java and >> nuxeo/ImportCommand.java with the latest in master, you'll have the patches. >> >> At that point, you should use the 2.2 syntax (not the 2.1 and below, >> because now the system is patched up to 2.2, as far as imports are >> concerned). The deprecated syntax won't work reliably until CSPACE-4817 is >> fixed. >> >> It sounds like you may have missed patching nuxeo/ImportCommand.java. >> I'll link CSPACE-4807 to the other jiras, so it's easier to find. Let us >> know if that works! >> >> Ray >> >> >> >> On Fri, 23 Mar 2012 10:59:34 -0500, Nate Solas <nate.solas@walkerart.org> >> wrote: >> >> I'm totally stuck. I've been working with our customized codebase trying >> to run imports and have had some extremely weird and frustrating behavior. >> I'll run an import of 10 collection objects, everything looks right, but >> nothing shows up in the cspace admin. Incredibly, sometimes I will see the >> objects in the nuxeo database, but un-recognized by cspace services >> apparently. Other times nothing will show up but another import of the same >> data will work. I've restarted tomcat between attempts, wped the database, >> and tried both the old and new curl import commands ( >> http://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home). >> I seemed to have more success with the old, deprecated one, but that was >> running into the "fail silently" bug all the time. >> I finally installed the patched ImportsResource.java from >> http://issues.collectionspace.org/browse/CSPACE-4866 to see if that >> helps, and it's the same behavior. I reverted all of our changes and am >> running a vanilla Collectionspace 2.0 (with Aron's patch), and now it's >> failing every time. Per that ticket I'm trying the dirt-simplest xml import >> I can think of, the objectexit one, and... nothing. I've even tried it with >> the old syntax and without Aron's patch which didn't work the first time, >> then I restarted tomcat, tried the new (2.1 and below) syntax: fail. Tried >> the old one again (curl -X) and it worked! Seeing that things were behaving >> I tried my 10 objects again (which HAVE worked at times in the past) and it >> failed (silently). >> I guess this relates to the recent thread about testing imports. I've >> been going nuts for a few days on this, trying to eliminate all the >> variables on my end, tweaking xml generators, etc, and now as I read more >> it seems like there are just a bunch of known "random glitches" with the >> imports? >> Any tips? More info below: >> curl http://localhost:8180/cspace-services/imports?type=xml -i -u >> admin@core.collectionspace.org:Administrator -F " >> file=@objectexit-utf8.xml;type=application/xml" >> catalina.out looks like: >> Created ThreadLocal instance: java.lang.ThreadLocal - null >> Setting ThreadLocal instance: java.lang.ThreadLocal - >> javax.security.auth.login.LoginContext@1f5173f >> Preamble type is: >> Media type is:application/xml >> ############## TEMPLATE_DIR: >> /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/cspace/config/services/resources/templates >> ############## >> OUTPUT_DIR:/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca >> ====Path============ >> /imports/import[0] >> ====Context========= >> ====Fragment======== >> http://collectionspace.org/services/objectexit" >> name="objectexit_common"> >> This OBJECT has been declared a World Heritage Nuisance and must be >> disposed of forthwith - Sebastián >> OE2010.2 >> >> >> =================== >> Making directory: >> /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9 >> ====TemplateExpander DONE============ >> ================ >> importTree reading file: >> /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca >> exists? true >> ~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: >> /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml >> ~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: >> /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml >> :: DONE >> >> >> > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > >

RL

Ray Lee

Fri, Mar 23, 2012 7:10 PM

Hi Nate,
These may not be must-haves for you, but we've also patched CSPACE-4843 to allow boolean (checkbox) fields to work properly, and CSPACE-4721, to allow advanced search on nested fields. Each is a one-file replacement.

CSPACE-4843: https://github.com/collectionspace/application/commit/3f762d943d775d142159d43d2750123ccf19979d
CSPACE-4721: https://github.com/collectionspace/application/commit/4b803f2164eca5230d8ac24554454018ced74e02

Ray

On Mar 23, 2012, at 11:38 AM, Nate Solas wrote:

Thanks for tips, Ray, Chris, and Susan. I'll grab the relations service update before that one gets me... Any other must-have patches I should add? Thanks,
Nate

On Fri, Mar 23, 2012 at 1:06 PM, Ray Lee rhlee@berkeley.edu wrote:
The relationship problem Chris mentioned is CSPACE-4783, and can be patched in 2.0/2.1 by replacing RelationDocumentModelHandler.java in the relations service with the 2.2 version.

I should also mention that while I said there were four bugs relating to import in 2.0, there are actually more. For example, CSPACE-4789 is still floating around. But those four were the ones we ran into most often.

Ray

On Mar 23, 2012, at 10:44 AM, Chris Hoffman wrote:

Glad to hear it's working!! We're actually using 2.0 for several major installations right now, but we do have it patched, and patched, and patched… The demo.collectionspace.org site is not patched and has some significant bugs for instance with saving of relationships. That's a big one. You want to make sure you have that patch installed.

We will probably wait for 2.3 to do the next set of upgrades.

Chris

On Mar 23, 2012, at 10:41 AM, Nate Solas wrote:

Ray, you the man. Imports seem to work like a charm now.

...Can't believe I didn't find that ticket. Should we not be working with 2.0 at all?

Nate

On Fri, Mar 23, 2012 at 12:12 PM, Ray Lee rhlee@berkeley.edu wrote:
Hi Nate,
On 2.0 there are four bugs related to import, and two files to patch.

CSPACE-4817 is not fixed.
CSPACE-4866 is fixed, in ImportsResource.java
CSPACE-3911 is fixed, in ImportsResource.java
CSPACE-4807 is fixed, in ImportsResource.java and nuxeo/ImportCommand.java

Basically, if you replace ImportsResource.java and nuxeo/ImportCommand.java with the latest in master, you'll have the patches.

At that point, you should use the 2.2 syntax (not the 2.1 and below, because now the system is patched up to 2.2, as far as imports are concerned). The deprecated syntax won't work reliably until CSPACE-4817 is fixed.

It sounds like you may have missed patching nuxeo/ImportCommand.java. I'll link CSPACE-4807 to the other jiras, so it's easier to find. Let us know if that works!

Ray

On Fri, 23 Mar 2012 10:59:34 -0500, Nate Solas nate.solas@walkerart.org wrote:

I'm totally stuck. I've been working with our customized codebase trying to run imports and have had some extremely weird and frustrating behavior. I'll run an import of 10 collection objects, everything looks right, but nothing shows up in the cspace admin. Incredibly, sometimes I will see the objects in the nuxeo database, but un-recognized by cspace services apparently. Other times nothing will show up but another import of the same data will work. I've restarted tomcat between attempts, wped the database, and tried both the old and new curl import commands (http://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home). I seemed to have more success with the old, deprecated one, but that was running into the "fail silently" bug all the time.

I finally installed the patched ImportsResource.java from http://issues.collectionspace.org/browse/CSPACE-4866 to see if that helps, and it's the same behavior. I reverted all of our changes and am running a vanilla Collectionspace 2.0 (with Aron's patch), and now it's failing every time. Per that ticket I'm trying the dirt-simplest xml import I can think of, the objectexit one, and... nothing. I've even tried it with the old syntax and without Aron's patch which didn't work the first time, then I restarted tomcat, tried the new (2.1 and below) syntax: fail. Tried the old one again (curl -X) and it worked! Seeing that things were behaving I tried my 10 objects again (which HAVE worked at times in the past) and it failed (silently).
I guess this relates to the recent thread about testing imports. I've been going nuts for a few days on this, trying to eliminate all the variables on my end, tweaking xml generators, etc, and now as I read more it seems like there are just a bunch of known "random glitches" with the imports?
Any tips? More info below:
curl http://localhost:8180/cspace-services/imports?type=xml -i -u admin@core.collectionspace.org:Administrator -F "file=@objectexit-utf8.xml;type=application/xml"
catalina.out looks like:
Created ThreadLocal instance: java.lang.ThreadLocal - null
Setting ThreadLocal instance: java.lang.ThreadLocal - javax.security.auth.login.LoginContext@1f5173f
Preamble type is:
Media type is:application/xml
############## TEMPLATE_DIR: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/cspace/config/services/resources/templates
############## OUTPUT_DIR:/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca
====Path============
/imports/import[0]
====Context=========
====Fragment========
http://collectionspace.org/services/objectexit" name="objectexit_common">
This OBJECT has been declared a World Heritage Nuisance and must be disposed of forthwith - Sebastián
OE2010.2

===================
Making directory: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9
====TemplateExpander DONE============

importTree reading file: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca exists? true
~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml
~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml :: DONE

Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Hi Nate, These may not be must-haves for you, but we've also patched CSPACE-4843 to allow boolean (checkbox) fields to work properly, and CSPACE-4721, to allow advanced search on nested fields. Each is a one-file replacement. CSPACE-4843: https://github.com/collectionspace/application/commit/3f762d943d775d142159d43d2750123ccf19979d CSPACE-4721: https://github.com/collectionspace/application/commit/4b803f2164eca5230d8ac24554454018ced74e02 Ray On Mar 23, 2012, at 11:38 AM, Nate Solas wrote: > Thanks for tips, Ray, Chris, and Susan. I'll grab the relations service update before that one gets me... Any other must-have patches I should add? Thanks, > Nate > > > On Fri, Mar 23, 2012 at 1:06 PM, Ray Lee <rhlee@berkeley.edu> wrote: > The relationship problem Chris mentioned is CSPACE-4783, and can be patched in 2.0/2.1 by replacing RelationDocumentModelHandler.java in the relations service with the 2.2 version. > > I should also mention that while I said there were four bugs relating to import in 2.0, there are actually more. For example, CSPACE-4789 is still floating around. But those four were the ones we ran into most often. > > Ray > > > On Mar 23, 2012, at 10:44 AM, Chris Hoffman wrote: > >> Glad to hear it's working!! We're actually using 2.0 for several major installations right now, but we do have it patched, and patched, and patched… The demo.collectionspace.org site is not patched and has some significant bugs for instance with saving of relationships. That's a big one. You want to make sure you have that patch installed. >> >> We will probably wait for 2.3 to do the next set of upgrades. >> >> Chris >> >> On Mar 23, 2012, at 10:41 AM, Nate Solas wrote: >> >>> Ray, you the man. Imports seem to work like a charm now. >>> >>> ...Can't believe I didn't find that ticket. Should we not be working with 2.0 at all? >>> >>> Nate >>> >>> On Fri, Mar 23, 2012 at 12:12 PM, Ray Lee <rhlee@berkeley.edu> wrote: >>> Hi Nate, >>> On 2.0 there are four bugs related to import, and two files to patch. >>> >>> CSPACE-4817 is not fixed. >>> CSPACE-4866 is fixed, in ImportsResource.java >>> CSPACE-3911 is fixed, in ImportsResource.java >>> CSPACE-4807 is fixed, in ImportsResource.java and nuxeo/ImportCommand.java >>> >>> Basically, if you replace ImportsResource.java and nuxeo/ImportCommand.java with the latest in master, you'll have the patches. >>> >>> At that point, you should use the 2.2 syntax (not the 2.1 and below, because now the system is patched up to 2.2, as far as imports are concerned). The deprecated syntax won't work reliably until CSPACE-4817 is fixed. >>> >>> It sounds like you may have missed patching nuxeo/ImportCommand.java. I'll link CSPACE-4807 to the other jiras, so it's easier to find. Let us know if that works! >>> >>> Ray >>> >>> >>> >>> On Fri, 23 Mar 2012 10:59:34 -0500, Nate Solas <nate.solas@walkerart.org> wrote: >>> >>> I'm totally stuck. I've been working with our customized codebase trying to run imports and have had some extremely weird and frustrating behavior. I'll run an import of 10 collection objects, everything looks right, but nothing shows up in the cspace admin. Incredibly, sometimes I will see the objects in the nuxeo database, but un-recognized by cspace services apparently. Other times nothing will show up but another import of the same data will work. I've restarted tomcat between attempts, wped the database, and tried both the old and new curl import commands (http://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home). I seemed to have more success with the old, deprecated one, but that was running into the "fail silently" bug all the time. >>> >>> I finally installed the patched ImportsResource.java from http://issues.collectionspace.org/browse/CSPACE-4866 to see if that helps, and it's the same behavior. I reverted all of our changes and am running a vanilla Collectionspace 2.0 (with Aron's patch), and now it's failing every time. Per that ticket I'm trying the dirt-simplest xml import I can think of, the objectexit one, and... nothing. I've even tried it with the old syntax and without Aron's patch which didn't work the first time, then I restarted tomcat, tried the new (2.1 and below) syntax: fail. Tried the old one again (curl -X) and it worked! Seeing that things were behaving I tried my 10 objects again (which HAVE worked at times in the past) and it failed (silently). >>> I guess this relates to the recent thread about testing imports. I've been going nuts for a few days on this, trying to eliminate all the variables on my end, tweaking xml generators, etc, and now as I read more it seems like there are just a bunch of known "random glitches" with the imports? >>> Any tips? More info below: >>> curl http://localhost:8180/cspace-services/imports?type=xml -i -u admin@core.collectionspace.org:Administrator -F "file=@objectexit-utf8.xml;type=application/xml" >>> catalina.out looks like: >>> Created ThreadLocal instance: java.lang.ThreadLocal - null >>> Setting ThreadLocal instance: java.lang.ThreadLocal - javax.security.auth.login.LoginContext@1f5173f >>> Preamble type is: >>> Media type is:application/xml >>> ############## TEMPLATE_DIR: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/cspace/config/services/resources/templates >>> ############## OUTPUT_DIR:/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca >>> ====Path============ >>> /imports/import[0] >>> ====Context========= >>> ====Fragment======== >>> http://collectionspace.org/services/objectexit" name="objectexit_common"> >>> This OBJECT has been declared a World Heritage Nuisance and must be disposed of forthwith - Sebastián >>> OE2010.2 >>> >>> >>> =================== >>> Making directory: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9 >>> ====TemplateExpander DONE============ >>> ================ >>> importTree reading file: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca exists? true >>> ~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml >>> ~~~~~~~~~~~~~~~~~~~ LoggedXMLDirectoryReader :: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9/document.xml :: DONE >>> >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >> > >

talk@lists.collectionspace.org

Import: "succeeds", but database is empty

===================
Making directory:
/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9
====TemplateExpander DONE============

===================
Making directory: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9
====TemplateExpander DONE============

===================
Making directory: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9
====TemplateExpander DONE============

===================
Making directory:
/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9
====TemplateExpander DONE============

===================
Making directory:
/home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9
====TemplateExpander DONE============

===================
Making directory: /home/nschroeder/cs_2.0/apache-tomcat-6.0.33/temp/imports-f9ea92df-ec33-4dbe-8ba4-e4329974a0ca/ObjectExit/da01e9fb-f6f9-4865-99f1-3ad380d364c9
====TemplateExpander DONE============