Searching RAM asset from RELM results into an internal server error (ClassCastException)
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
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!) :
--------------------
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":
--------------------
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
Comments
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.
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
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.
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.