I'm not sure how this is happening. I submitted a band-aid in the code to limp through but the proper cause needs to be found.

Here's the page/screen where the remove button causes that exception

Is there a stack trace for the exception?

Does the comparator have any cases to deal with null values?

WARN: Exception calling method doMessageFrame java.lang.reflect.InvocationTargetException (Caused by java.lang.ClassCastException) (2007-09-11 14:13:03,815 http-8080-Processor24_org.sakaiproject.cheftool.VelocityPortletPaneledAction)

 What happens is that if I do a search (say chicago bears). Then add a citation via the add button. Then go back to "revise citations". Then go "back to search results". Try to hit the "remove" button I get the above problem. Where it happens is:

CitationHelperAction:

2237: public void doMessageFrame(RunData data)

2306: else if(operation.equalsIgnoreCase("remove"))
2307: {
2308: logger.debug("removing citation " + citationId + " from " + collectionId);
2309: collection.remove( citation );

BaseCitationService:

2761: public boolean remove(Citation item)
2762:{
2763: checkForUpdates();
2764: boolean success = true;
2765: this.m_order.remove(item.getId());

 2765 throws the ClassCastException. I followed it via Eclipse and calling remove is on m_oder is calling compare

2011: public int compare(Object arg0, Object arg1)
2012: {
2013: int rv = 0;
2014: if (!(arg0 instanceof String) || !(arg1 instanceof String))
2015: {
2016: throw new ClassCastException();
2017: }
2018:
2019: Object obj0 = m_citations.get(arg0);
2020: Object obj1 = m_citations.get(arg1);
2021:
2022: // Stopgap fix
2023: /*
2024: if ((obj0 == null && obj1 != null) ||
2025: (obj0 != null && obj1 == null))
2026: return 0;
2027: */
2028:
2029: if (!(obj0 instanceof Citation) || !(obj1 instanceof Citation))
2030: {
2031: throw new ClassCastException();
2032: }


 My band-aid is 2022 -2027 so you'l have to comment it out to see the exception.

  In Eclipse I set a breakpoint and stepped through the code while inspecting variables. arg0 and arg1 do have values at 2013. So we get past 2017 okay. Then 2019 and 2020 are the problems. arg0 lookup on 2019 always return null. Yet 2020 returns a citation. So obviously the 2029 check throws that ClassCastException.

Is this still an issue? It seems like the addition of the multiple-key comparator or Damian's "stopgap fix" takes care of this.

Is this fixed?

No, although the stopgap fix will get us through. We need to eventually look through that DB process I was asking about (emailing) last week as I think the exception is being thrown related to bogus citation IDs in the list. This was the ticket I was looking at when I was asking those questions about those copied orphaned DB entries.

  I'll add a JIRA ticket for it and relate it to this ticket.

  Anyways, for 2.5 I think we're okay w/ the stogap solution. But it is not FIXED...more like mitigated.

Updating fix version to 2.5.0.003 as tag was just cut and this ticket was included.

Jim, is this one you can verify and close?

This was fixed and verified in September. I is already merged to 2.5.x.