CC Monitoring Portlet Failure

[spostek]

All,

I just installed deployed KOSMOS 0.1.7 binaries out of the box on a Jboss portal 2.01RC1/Jboss4.0.2/Windows XP and it worked like I charm once I fed in my company's proxy info in the the JVM.

However, when I try to run the same thing on my own CruiseControl servers boxes, feeding the appropriate CC Project URL's into portlet.xml's "monitored.urls".

I'm getting the following error in the JBoss log file:
********************************
2006-01-05 10:16:21,505 DEBUG [hu.midori.kosmos.server.AbstractKosmosService] Reloading "http://buildux3:8080/cruisecontrol/buildresults/build-help"...
2006-01-05 10:16:21,505 DEBUG [hu.midori.kosmos.server.AbstractKosmosService] Beginning store session....
2006-01-05 10:16:21,505 DEBUG [hu.midori.kosmos.server.util.ScrapingUtils] Downloading HTML DOM from http://buildux3.cup.hp.com:8080/cruisecontrol/buildresults/build-help...
2006-01-05 10:16:21,771 DEBUG [hu.midori.kosmos.server.util.ScrapingUtils] DOM top-level children: 1
2006-01-05 10:16:21,787 ERROR [hu.midori.kosmos.server.cc.CcServiceImpl] Unable to scrape
java.lang.NullPointerException
at hu.midori.kosmos.server.cc.CcServiceImpl$CcDataHandler.reloadData(CcServiceImpl.java:86)
at hu.midori.kosmos.server.AbstractKosmosService.getFromCache(AbstractKosmosService.java:101)
at hu.midori.kosmos.server.cc.CcServiceImpl.getProjects(CcServiceImpl.java:53)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:335)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:181)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:148)
at org.springframework.remoting.support.RemoteInvocationTraceInterceptor.invoke(RemoteInvocationTraceInterceptor.java:68)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:170)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:176)
at $Proxy60.getProjects(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.caucho.hessian.server.HessianSkeleton.invoke(HessianSkeleton.java:157)
at org.springframework.remoting.caucho.HessianServiceExporter.handleRequest(HessianServiceExporter.java:87)
at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:44)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:717)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:658)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:392)
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:357)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:595)
2006-01-05 10:16:21,787 DEBUG [hu.midori.kosmos.server.AbstractKosmosService] Ending store session...
*******************************
Any ideas?

Thanks

[aron.gombas]

The problem is that after downloading the CC Build Results page, the Kosmos CC service can't find the link that points to the "XML Log File" tabpage.
If you download the Build Results as HTML, can you see the following HTML snippet in there?

<a class="tabs-link" href="/cruisecontrol/buildresults/gridsphere?tab=xmlLogFile">XML Log File</a>

[spostek]

Aron,

I really appreciate the response. Yes, it is there and here it is:

"a class="tabs-link" href="logs/quake-java/log20060106071559Lbuild.225.xml">XML Log File</a"

One thing that might be contributing to the problem, I'm using CC's reporting jsp from 2.3.1 with a patch to fix an issue that caused the "XML Log" tag not working, because it's path that was returned was the absolute one. http://sourceforge.net/mailarchive/message.php?msg_id=14014041

Would there be a way around this by building the cruisecontrol war file differently or making a change in Kosmos?

Thanks,
Steve

[aron.gombas]

Yes, it is there and here it is:

Steve, the problem is that the Kosmos CC service impl is always looking for a element where the "href" attribute contains "?tab=xmlLogFile"! I thought it's a standard URL in CC?!
What you wrote about your patch can easily cause this problem. Can't you apply a patch that generates URL with "?tab=xmlLogFile"?
That'd immediately solve your problem.