[junitee-user] MalformedURLException in FFDC log files using IBM WebSphere

[<dav...@th...>]

The following is a partial snapshot of FFDC log files in IBM WebSphere 
version 6.0.2.17.  Getting a MalformedURLException.

------Start of DE processing------ = [12/27/07 13:06:42:324 CST] , key = 
java.net.MalformedURLException 
com.ibm.ws.webcontainer.srt.WebGroup.getResourceAsStream 602
Exception = java.net.MalformedURLException
Source = com.ibm.ws.webcontainer.srt.WebGroup.getResourceAsStream
probeid = 602
Stack Dump = java.net.MalformedURLException: SRVE0238E: Resource paths 
should have a leading slash
        at 
com.ibm.ws.webcontainer.webapp.WebApp.getResource(WebApp.java:2038)
        at 
com.ibm.ws.webcontainer.webapp.WebApp.getResourceAsStream(WebApp.java:2006)
        at 
com.ibm.ws.webcontainer.facade.ServletContextFacade.getResourceAsStream(ServletContextFacade.java:108)
        at 
org.junitee.servlet.JUnitEEServlet.searchForTests(JUnitEEServlet.java:350)
        at 
org.junitee.servlet.JUnitEEServlet.searchForTests(JUnitEEServlet.java:275)
        at 
org.junitee.servlet.JUnitEEServlet.doGet(JUnitEEServlet.java:183)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
        at 
com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1572)
        at 
com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:762)
        at 
com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3071)
        at 
com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:236)
        at 
com.ibm.ws.webcontainer.VirtualHost.handleRequest(VirtualHost.java:210)
        at 
com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:1958)
        at 
com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:98)
        at 
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:472)
        at 
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:411)
        at 
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:288)
        at 
com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminaters(NewConnectionInitialReadCallback.java:207)
        at 
com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:109)
        at 
com.ibm.ws.tcp.channel.impl.WorkQueueManager.requestComplete(WorkQueueManager.java:566)
        at 
com.ibm.ws.tcp.channel.impl.WorkQueueManager.attemptIO(WorkQueueManager.java:619)
        at 
com.ibm.ws.tcp.channel.impl.WorkQueueManager.workerRun(WorkQueueManager.java:952)
        at 
com.ibm.ws.tcp.channel.impl.WorkQueueManager$Worker.run(WorkQueueManager.java:1039)
        at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1471)

In tracing the execution of the code, I've found that this exception is 
thrown in the JUnitEEServlet.searchForTestCaseList() method.  The line 

InputStream in = 
getServletContext().getResourceAsStream("WEB-INF/testCase.txt");

is the problem as the string does not have a leading slash ("/") before 
"WEB-INF".  The code handles this problem by trying it again, this time 
including the leading slash.  Here's that code:

if (in == null) {
        // there are issues with some containers with/without trailing 
slash, so try it again
        in = 
getServletContext().getResourceAsStream("/WEB-INF/testCase.txt");
}

Although the code does perform/work (because of the 2nd try using the 
leading slash), the errors in the FFDC log files clutter things up and our 
system administrators want us to clean them up.  I'm wondering a couple 
things:
1) The comment in the code above mentioned some containers have problems 
with/without the slash.  What containers?  What problems?
2) Could the code be changed so that the first check includes the slash 
and the 2nd check doesn't use the slash?

Thanks,

David