It's all about the answers!

Ask a question

Searching RAM asset from RELM results into an internal server error (ClassCastException)


Shinji Kanai (59714) | asked Sep 22 '14, 9:05 p.m.
 Hello

I added RAM 7.5.1.2 to the data source of RELM/LQE 4.0.6/5.0.1. RAM assets are indexed fine because I can search them from LQE > Query > Full Text Search. The problem occurs when I search the same assets through RELM's search box located on top-right corner. Can anyone guide me where I should look into to fix this problem? Trace is also attached. 


2014-09-22 19:35:02.877+1000 [         http-bio-9450-exec-31] [] ERROR com.ibm.relm.frontservice.jaf.RmpsFrontService  - CRCPC1815E An internal error has occurred.
User action: Check the relm.log file in the logs directory of the server to see what happened just before this error.
Stack trace:
com.ibm.relm.frontservice.MessageBoxException: CRCPC1815E An internal error has occurred.
at com.ibm.relm.frontservice.jaf.RmpsFrontService.rmpsService(RmpsFrontService.java:430)
at com.ibm.relm.frontservice.jaf.RmpsFrontService.doGet(RmpsFrontService.java:576)
at com.ibm.team.jfs.app.servlet.AppContainerServlet.dispatchRequest(AppContainerServlet.java:174)
at com.ibm.team.jfs.app.servlet.AppContainerServlet.service(AppContainerServlet.java:285)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at com.ibm.team.repository.servlet.AbstractTeamServerServlet.service(AbstractTeamServerServlet.java:1674)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.eclipse.equinox.http.registry.internal.ServletManager$ServletWrapper.service(ServletManager.java:180)
at org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(ServletRegistration.java:61)
at org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:126)
at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:76)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.eclipse.equinox.servletbridge.BridgeServlet.service(BridgeServlet.java:120)
at com.ibm.team.repository.server.servletbridge.JazzServlet.service(JazzServlet.java:74)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at com.ibm.team.repository.server.servletbridge.BridgeFilter.processDelegate(BridgeFilter.java:165)
at com.ibm.team.repository.server.servletbridge.BridgeFilter.doFilter(BridgeFilter.java:198)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:336)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:906)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:929)
at java.lang.Thread.run(Thread.java:761)
Caused by: java.lang.ClassCastException: java.lang.String incompatible with com.hp.hpl.jena.datatypes.xsd.XSDDateTime
at com.ibm.relm.ple.service.search.RdfUtil.getDateTime(RdfUtil.java:85)
at com.ibm.relm.ple.service.search.PrettyTitleHitFormatter.formatHit(PrettyTitleHitFormatter.java:85)
at com.ibm.relm.ple.service.search.HitLoader.loadAndFilterHitProperties(HitLoader.java:281)
at com.ibm.relm.ple.service.search.HitPager.loadHitProperties(HitPager.java:238)
at com.ibm.relm.ple.service.search.HitPager.getPage(HitPager.java:166)
at com.ibm.relm.ple.service.search.LqeFullTextSearchService.fetchPage(LqeFullTextSearchService.java:536) 
at com.ibm.relm.ple.service.search.LqeFullTextSearchService.doSearch(LqeFullTextSearchService.java:285)
at com.ibm.relm.ple.service.search.LqeFullTextSearchService.doGetOrPost(LqeFullTextSearchService.java:207)
at com.ibm.relm.ple.service.search.LqeFullTextSearchService.rmpsGet(LqeFullTextSearchService.java:163)
at com.ibm.relm.frontservice.jaf.RmpsFrontService.rmpsService(RmpsFrontService.java:357)
... 34 more

Accepted answer


permanent link
John Carolan (71616) | answered Sep 23 '14, 7:29 a.m.
edited Sep 23 '14, 7:38 a.m.
Hi Shinji,

I haven't seen this before, but the message "java.lang.String incompatible with com.hp.hpl.jena.datatypes.xsd.XSDDateTime" does indicate that the RDF data contains something which ought to be a datetime attribute but which doesn't conform to the expected xsd:dateTime format.   

You might be able to narrow down the source of the problem by constructing a SPARQL query, for example (assuming the RAM artifacts can be identified with the type "oslc_am:Asset") this will filter the date attributes which match the expected formatting (or possibly throw an error - I am not sure!) :

--------------------
Prefixes

SELECT * WHERE {

?resource   
rdf:type oslc_am:Asset ;
?attr  ?date   . FILTER (?date > "2010-01-01T00:00:00Z"^^xsd:dateTime )

}
LIMIT 100

# I always use a LIMIT in case the result set is huge and takes forever to return

--------------------

... and compare that with another query which only lists known datetime attributes, for example (and I am not sure if this one exists on a RAM artifact) "dcterms:modified":

--------------------
Prefixes
SELECT * WHERE {
?resource   
rdf:type oslc_am:Asset ;
dcterms:modified ?date . 
}
LIMIT 100
--------------------

If there is a resource with a dcterms:modified value (or any other datetime attribute) in the second query which is not represented in the first query, that might indicate that the RDF data for that datetime attribute is not in the correct format.  

You could also just omit the FILTER clause altogether in the first query to get a complete listing attributes on all RAM artifacts in the index, but that would probably be a very long list to parse.

Hope that helps!

John
Shinji Kanai selected this answer as the correct answer

Comments
John Carolan commented Sep 23 '14, 7:36 a.m.

  Prefixes


John Carolan commented Sep 23 '14, 9:40 a.m.

 And if you can identify some RAM artifact attribute values which are inappropriate for a datetime attribute - you may be able to correct them in RAM and re-index the data source.  However, it may not be that easy depending on how RAM is storing the attributes.  I'll be interested to see what you find.


Shinji Kanai commented Sep 23 '14, 10:17 p.m.

Hi John, thank you for your kind help.

I increased the debug level of RELM to see the returned output from GET call which is invoked as part of searching, please see below:

org.apache.http.wire  - << "      <binding name="modified">[\n]"
org.apache.http.wire  - << "        <literal>2014-09-22T19:40:46+1000</literal>[\n]"
org.apache.http.wire  - << "      </binding>[\n]"
*NOTE: Above output is manipulated bit for display purpose.

The "modified" is the only property related to DateTime returned from this particular GET call.  According to 3.2.7.3 section in XSDDateTime schema, the time zone (+1000) returned looks like violating [+/-]hh:mm format; colon (:) is missing. It appears that this is the source of problem. I've been searching for a way to change default format being used in RAM 7512 but no luck so far. Will update if I find a solution.


One other answer



permanent link
Peter Haumer (2.2k12018) | answered Sep 23 '14, 10:10 p.m.
JAZZ DEVELOPER
Hello.
Yes, John is correct. This is a problem with RAM's TRS feed, which provides the dates as strings and not proper xsd dates. I have done a fix just now that parses these date strings as well as part of that Defect 98966 that you are subscribed to, Shinji. Add a comment to that work item if you need a patch for a specific release. I will also file this as a defect against RAM.
Best regards,
Peter Haumer from RELM development.


Comments
Shinji Kanai commented Sep 24 '14, 2:17 a.m.

Thank you, Peter! I will monitor the progress on Defect 98966.

Your answer


Register or to post your answer.