Much Ado

About seemingly trivial stuff in the last couple of weeks, like how to redirect an URL in JSF, how to completely wipe off sensitive, crucial information that were accidently, mistakenly checked into CVS, etc. But as the happy ending, I finished my part of transforming CIMA portal to use GridFTP for data transfer services. (Of course I have to mention CIMA portal often to maintain my seat in the Google search competition.)

In the coming couple of weeks, besides the PolarGrid meeting and a quick trip to the west, I expect to be watching videos and surfing webs, hoping to find something in the cloud.

Accessing JSF Backing Beans from JSP

As sophisticated as it sounds, I don't really have much clue about what I'm talking here. Starting with very little knowledge on either JSF or JSP, I struggled with one simple problem for almost a week. That much searching in darkness at least deserves a blog entry I guess.

To make the long story short, in one of my CIMA portal renovations, I have a backing bean that takes a string parameter from the JSF/JSP front end, and generates an URL to be dispatched/forwarded/redirected by JSF/JSP. Stunningly, I couldn't find appropriate JSF tags that meet exactly what I need. After studying all possibilities listed in a very good summary given my restricted environment, I gave up and took the brute force approach of accessing the backing bean attribute from JSP directly:
<%
cima.jsf.managedbeans.MyBean mbean = (cima.jsf.managedbeans.MyBean) request.getAttribute("MyBean");
String url = mbean.get_url();
response.sendRedirect(url);
%>


However the above code gives NULL pointer exception because MyBean was not initialized for request, likely because JSF <managed-beans> declaration in faces-config.xml didn't fall though JSP invocation path -- I encountered some statements like that out on the web. Finally I settled with a simple solution buried in a helpful discussing thread, which is to insert the following line before trying to grab MyBean object out of request:
javax.faces.context.FacesContext.getCurrentInstance().getApplication().getVariableResolver().resolveVariable(javax.faces.context.FacesContext.getCurrentInstance(), "MyBean");


Worked like charm, if only I understood every piece of the complete mystery.

Short Week

with long meetings started off the year. CIMA project plans were discussed, and I messed with Log4J for a while to (slightly) improve GridFTP portlet performance further. Also spent some time on the CDI pre proposal, we'll see how far this one goes.

Log4J with Tomcat and Gridsphere

For a couple of days I've been trying to tune up (actually down) the logging level of some Gridsphere portlets, which use the Java cog kit to GridFTP files. Excessive security handshaking and encryption messages were showing up in catalina.out, even though the logging level was set to "ERROR" in log4j.properties. Obviously understanding better the Tomcat Logging Documentation or some interesting online discussions is the proper start, but here are my quick idioms:

• Gridsphere puts a log4j.xml file in ${CATALINA_HOME}/common/classes/, to make Tomcat honor the Log4J settings defined there, commons-logging and log4j jars need to present in ${CATALINA_HOME}/common/lib/.


• For the log4j.properties file in ${CATALINA_HOME}/webapps/some-portlet/WEB-INF/classes/ to be honored, commons-logging and log4j jars are required in the corresponding WEB-INF/lib/ directory. Those in ${CATALINA_HOME}/shared/lib/ didn't seem to count, and putting the two jars in individual web app directories incidentally got rid of some annoying log4j warning about "No appenders could be found for logger (org.apache.catalina.session.ManagerBase)" as well.

Experience drew from Tomcat 5.5.25 and Gridsphere 2.2.10.