BEA Weblogic and my CCA install - this one caught me out

IT & Telecoms are full of rat holes as an old colleague of mine described them. Some, as Mick described them, are Mink lined - they're the best and hours can be wasted foraging around in them. My latest rat hole wasn't that much fun, but none the less provided an hour of fascinating diversion from the job in hand.

The actual task was to look at setting up and validating scheduled reports in Oracle CCA Fix Pack 8 (you can appreciate already why a rat hole would be very attractive at this point). Task in hand I opened up a browser and logged into my VM CCA environment, navigated to the advanced reports section of my test tenant (Aeonvista of course) and clicked on user login/logout - nice easy one - went through set-up and all looked got - including the schedule tab and email details entry... .So far so good.

OK to the test client (Supervisor Java App) login, select reporting and click on the login/logout report .... and crash - well error .... Hmmm.

Back to the Admin screen, click view report, Java Error in the page:

java.lang.NoSuchMethodError:org.apache.commons.codec.binary.Base64.encodeBase64String

Now this was a surprise - my test environment is pretty clean - and I was sure this was working before... Then I remembered I'd done an upgrade from FP5, Hmmm .... surely there wasn't an old library included in the new release - that would have been rubbish.

Warning --- Rat Hole --- Warning --- Rat Hole --- Warning --- Rat Hole --- Warning

So now I had a problem to investigate, which was much more fun than the original task. A quick search turned up a stackoverflow post, with someone with a similar issue. So to find the offending library.

A quick look in the WEB-INF/lib folder showed commons-codec-1.6.jar - OK looked like the latest version - should contain the Base64 encode method required. To the AdministrationManager/report code folder, the JSP page is cr_choose_period.jsp and the offending lines:

<%@ page import = "org.apache.commons.codec.binary.Base64" %>

.........

String credentials = Base64.encodeBase64String(sbCredentials.toString().getBytes());

The second line was were the error was appearing and the first showed me the library was being included - so - what's going wrong? To work on a bit of JSP hacking - now its been almost 10 years since I even touched any JSP - some serious cobwebs to clear out of my brain cells for this one... Quick hack at a debug version of the offending JSP file and I had cr_choose_period.debug.jsp, with:

<%@ page import = "org.apache.commons.codec.binary.Base64" %>

<%@ page import = "java.util.*" %>

.......  
  <% out.println("Hello World"); %>
  <%out.println(request.getRealPath("/")); %>
  <%out.println(Base64.class.getProtectionDomain().getCodeSource().getLocation()); %> 

The pop-up dialogue (window) now showed me it was pulling a defunct (outdated) 1.3 library from: 

C:\bea\user_projects\domains\base_domain\servers\AdminServer\tmp\_WL_user

So stop the BEA Weblogic service, delete the contents of the tmp directory, restart weblogic. Check the debug page - excellent now pulling the correct library from the WEB-INF/lib directory. 

C:\bea\user_projects\domains\base_domain\servers\AdminServer\tmp\_WL_user\TAW\qaiheg\war\WEB-INF\lib

Re-instate the correct cr__choose_period.jsp code and - HEY PRESTO - the dialogue (window) now has the date time chooser in there.

Rat Hole End

Now I was back on track setting up the scheduled reports.