[Dspace-tech] error in DSpace 1.7.x XMLUI admin eperson (with Oracle backend)

[Pottinger, Hardy J.]

Hi, I'm in the process of upgrading to DSpace 1.7, and am using the 1.7.x branch for testing. Everything installed fine, and I've got a bare-bones repository up and running. However, in the XMLUI, when I click on the admin ePeople link, I get the following error:

java.lang.IllegalArgumentException: No such column rnum

Our environment is RHEL5, with Oracle on the back end, here's the info from the XMLUI Java Information control panel:

Java and Operating System

Java Runtime Environment Version: 1.6.0_22
Java Runtime Environment Vendor: Sun Microsystems Inc.
Operating System Name: Linux
Operating System Architecture: i386
Operating System Version: 2.6.18-238.1.1.el5

Runtime statistics

Available processors: 2
Maximum memory: 910 MiB
Allocated memory: 126 MiB
Used memory: 58 MiB
Free memory: 68 MiB

Here are the first few lines of the stack trace:

java.lang.IllegalArgumentException: No such column rnum
at org.dspace.storage.rdbms.TableRow.canonicalizeAndCheck(TableRow.java:581)
at org.dspace.storage.rdbms.TableRow.setColumn(TableRow.java:433)
at org.dspace.storage.rdbms.DatabaseManager.process(DatabaseManager.java:1111)
at org.dspace.storage.rdbms.TableRowIterator.next(TableRowIterator.java:151)
at org.dspace.storage.rdbms.TableRowIterator.toList(TableRowIterator.java:204)
at org.dspace.eperson.EPerson.search(EPerson.java:358)
at org.dspace.app.xmlui.aspect.administrative.eperson.ManageEPeopleMain.addBody(ManageEPeopleMain.java:121)
at org.dspace.app.xmlui.wing.AbstractWingTransformer.startElement(AbstractWingTransformer.java:223)
at sun.reflect.GeneratedMethodAccessor213.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:71)
at $Proxy66.startElement(Unknown Source)
at org.apache.cocoon.components.sax.XMLTeePipe.startElement(XMLTeePipe.java:87)
at org.apache.cocoon.xml.AbstractXMLPipe.startElement(AbstractXMLPipe.java:94)
at org.dspace.app.xmlui.wing.AbstractWingTransformer.startElement(AbstractWingTransformer.java:240)
at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:71)
at $Proxy49.startElement(Unknown Source)

...

Oddly enough, no such error is thrown when using the JSPUI. From the stack trace, I can see the error is getting thrown at org.dspace.eperson.EPerson.search, and I've confirmed that there is Oracle-specific code there which should be inserting 'rnum' into the query.

I'm going to keep poking at this, but I thought I'd report it here at least, to see if anyone has run into something similar, or, if anyone wants to fire up an Oracle-based 1.7.x install and see if they see the same thing.

I'd rather not report a bug if this is just a config problem on my part.

--
HARDY POTTINGER <potti...@umsystem.edu>
University of Missouri Library Systems
http://lso.umsystem.edu/~pottingerhj/
"No matter how far down the wrong road you've gone,
turn back." --Turkish proverb

[Pottinger, Hardy J.]

> org.dspace.storage.rdbms.TableRow.canonicalizeAndCheck(TableRow.java:581

OK, so, looking more closely at the stack trace, the problem appears to be that the canonicalizeAndCheck method in TableRow is failing when it attempts to verify the rnum column, which is created back in org.dspace.eperson.EPerson.search.

That makes sense because it's not actually a column on the table? Maybe? :-\

I'm going to see how the JSPUI is displaying ePeople next.


--Hardy

> ke(PoolableProxyHandler.java:71)
> at $Proxy49.startElement(Unknown Source)
>
> ...
>
> Oddly enough, no such error is thrown when using the JSPUI. From the
> stack trace, I can see the error is getting thrown at
> org.dspace.eperson.EPerson.search, and I've confirmed that there is
> Oracle-specific code there which should be inserting 'rnum' into the
> query.
>
> I'm going to keep poking at this, but I thought I'd report it here at
> least, to see if anyone has run into something similar, or, if anyone
> wants to fire up an Oracle-based 1.7.x install and see if they see the
> same thing.
>
> I'd rather not report a bug if this is just a config problem on my part.
>
> --
> HARDY POTTINGER <potti...@umsystem.edu>
> University of Missouri Library Systems
> http://lso.umsystem.edu/~pottingerhj/
> "No matter how far down the wrong road you've gone,
> turn back." --Turkish proverb
>
>
>

> ------------------------------------------------------------------------
> ------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> DSpace-tech mailing list
> DSpac...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dspace-tech