Early Training Notes

May 5, 2006

Started this project site. The idea is to share my thought processes with people who might be interested.
Some of this information may also migrate over to Sakaipedia, if and when I have the time. Meanwhile there
is a lot to do to prepare for upcoming training sessions and the Sakai Conference in Vancouver.

Glenn has documented many of the planned changes for Sakai 2.2 in Sakai Enabling Technologies

While this document does go into a fair bit of detail on where things live, I need to re-organize it as much
for my own understanding as anything else. Create an outline from sakai_et in Sakai Framework. This
outline is pretty useful all by inself. If you know the name of a service, you can get an idea of where it
will live in the new organization. This could be massaged into a table with even more information
(module name, svn links, etc.).

May 6, 2006

Installed apache-tomcat-5.5.17. Downloaded, compiled and installed Sakai 2.2 Mini. No problems encountered.

May 7, 2006

Updated the Sakai Framework chart showing all Sakai 2.2 services and support tools to include URLs and notes.

Downloaded the Sakai documentation from https://source.sakaiproject.org/svn/reference/trunk/docs/. My first
thought was to have a look at the authorization documentation, since I've been doing a lot of work in that
area for MIT lately. Well, it's a bit of a mess. There is no document (that I could find), that explains
AuthzGroups. John Leasia has two documents that explain site templates and permissions from an administrative
point of view. That's good, but it won't help a developer.

Changed permissions to make personal site generally viewable by public.

Aug. 1

Since work on the notes tool is stalled until I can figure out the bug, I turned to starting work on the design of the integration exercises.

Aug. 1

Since work on the notes tool is stalled until I can figure out the bug, I turned to starting work on the design of the integration exercises.

Added a page for core models. Documentation on authorization is sorely missing. It may need to be written from sratch.

May 11, 2006

Updated the entity model presentation. Two new methods in Entity, which I've asked Glenn to explain. Started on the user model. Glenn is now grouping Authentication and Preferences with User, so I will be including them in that part of the presentation (AuthN moved from Security).

May 12, 2006

Completed the user model presentation. Created a Sakai Kernel Bundle page, largely for historical reasons. Created a Tool Organization page that explains how tools are laid out in Sakai 2.2. From there, created a Simple Tool page. Created placeholder pages for Sakai Tool Development WS and Sakai System Integration WS

June 20, 2006

Attempted to reduce the size of the training environment (sakai_train). The externals file associated with this distribution is really just the value of a property that has to be reset every time it changes.

Modified the externals file, but had problems with it building. Problem was tracked down to a bug in the externals file, in the user module.

June 22, 2006

Environment is much better than it was. I downloaded it on to my base computer. Once I set the externals property, it compiled correctly.

Started work on updating the exercises. Created a directory called "exercises" in dev. Copied in the master project files from sakai_training. Copied in simple1 exercise. Since it has virtually no dependencies, changes where needed. However, it wouldn't compile until I uncommented the sakai-2.2 plugin dependency in the master/project.xml file. It compiles now.

SU tool in the tools module failed to intialize properly in tomcat. It should be removed.

Ran Mercury. Got a message saying that it was disabled. Need to change "mercury.enabled=true" in sakai.properties.
Added tomcat/sakai/sakai.properties and included the new property.
Confirmed that simple1 works correctly.

For simple tool to truly conform to the new Sakai 2.2 directory structures, I need to create two intermediate directories: simple1-tool/tool. Changed the structure. It compiles OK, you need to be all the way down in exercises/simple1/simple1-tool/tool.

Created separate webapp identifiers for simple1 and simple2. Updated simple2 files, including new directory structure. Changes needed to SimpleTool class due to package name differences in Sakai 2.2.

June 22

Completed upate of Sakai training environment. Can now be downloaded from Sakai svn server at:
https://source.sakaiproject.org/svn/sakai/branches/sakai_training/

June 29

Merged directories. Moved all older presentations into "Old-Presentations". Made sure that the new model presentations are in the Presentations-v3 collection.

Updated the "01-Introduction to Sakai" presentation. SKB is deprecated.
Updated the "02-Sakai Training Environment presentation. Now organized into four main sections:

• Kernel services
• Framework services
• Presentation technology
• Portal

This architecture corresponds more with the architectural view of Sakai that I prefer, which is to separate out the kernel services from the higher level framework services (security, user, content hosting, etc.). Glenn doesn't quite see it this way, but the two are equivalent from a systems perspective. I believe that this organization is more clear from a training perspective. Kernel services do not managed persistent data – only run time or session based data.

June 30

Used the JSF Examples code included in sakai_training to look for reasons why the notes1 example won't compile or run. There are a number of differences in the web.xml when comparing them:

Migration Notes from older JSF files to 2.2.

Older:  DOCTYPE header:
<!DOCTYPE web-app
	PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
	"http://java.sun.com/j2ee/dtds/web-app_2.3.dtd">

Newer:
Dropped

=====================

Older:  web-app tag:
<web-app>

Newer:  web-app tag:
<web-app id="WebApp_9" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">

=====================


Older listener tag:
Same for Sun.

New Listener tag:
Use this for MyFaces:
    <listener>
        <listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
    </listener>

=====================

Older filter tag:
(no parameters included)

Newer filter tag:
Including these init parameters:
        <init-param>
        	<param-name>upload.enabled</param-name>
        	<param-value>true</param-value>
        </init-param>
        <init-param>
        	<param-name>http.session</param-name>
        	<param-value>container</param-value>
        </init-param>

=====================

Older filter-mapping tag:
        <servlet-name>Faces Servlet</servlet-name>

Newer filter-mapping tag:
replace with:
        <url-pattern>/*</url-pattern>

=====================

Older Faces servlet tag:
    <servlet>
        <servlet-name>Faces Servlet</servlet-name>
        <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
        <load-on-startup> 2 </load-on-startup>
    </servlet>

Newer servlet-class:
        same

======================

Older Sakai servlet tag:
        <servlet-name>sakai.sample.tools.note</servlet-name>
        <servlet-class>org.sakaiproject.jsf.util.JsfTool</servlet-class>
        <init-param>
            <param-name>default</param-name>
            <param-value>main</param-value>
        </init-param>
        <init-param>
            <param-name>path</param-name>
            <param-value>/note</param-value>
        </init-param>
        <load-on-startup> 1 </load-on-startup>
    </servlet>

Newer servlet tag:
	Examples include different values for init-params (index, and "/").
Additional init-param added:
        <init-param>
            <param-name>default.last.view</param-name>
            <param-value>true</param-value>
        </init-param>

	
======================

Older jsp-config tag:
	Note included.
	
Newer jsp-config tag:
    <jsp-config>
        <!--
	      Prelude and coda for standalone web application.
	      To eliminate "head" and "body" tags, making the application output suitable
	      as a portlet or for embedding, replace prelude with "link" tags
	      for any required CSS or JavaScript files and remove the coda.
        -->
	    <jsp-property-group>
          <url-pattern>*.jsp</url-pattern>
          <include-prelude>/include/head.inc</include-prelude>
          <include-coda>/include/foot.inc</include-coda>
        </jsp-property-group>
    </jsp-config>

======================

Older servlet-mapping tag:
	Same.
    <servlet-mapping>
        <servlet-name>Faces Servlet</servlet-name>
        <url-pattern>*.jsf</url-pattern>
    </servlet-mapping>

Newer servlet-mapping tag:
Additional mapping examples
    <servlet-mapping>
        <servlet-name>Faces Servlet</servlet-name>
        <url-pattern>*.faces</url-pattern>
    </servlet-mapping>

    
    <servlet-mapping>
        <servlet-name>View Source Servlet</servlet-name>
        <url-pattern>*.source</url-pattern>
    </servlet-mapping>

=======================

Older welcome-file-list:
	Same:
    <welcome-file-list>
    	<welcome-file>index.html</welcome-file>
    </welcome-file-list>

Newer welcome-file-list:
Additional welcome file example:
    <welcome-file>index.jsf</welcome-file>

======================

Older context-parameter tags:
    <context-param>
        <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
        <param-value>server</param-value>
    </context-param>

    <context-param>
        <param-name>com.sun.faces.validateXml</param-name>
        <param-value>true</param-value>
    </context-param>

    <context-param>
        <param-name>com.sun.faces.verifyObjects</param-name>
        <param-value>true</param-value>
    </context-param>

Examples for MyFaces:
    <context-param>
        <description>
            State saving method: "client" or "server" (= default)
            See JSF Specification 2.5.2
        </description>
        <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
        <param-value>server</param-value>
    </context-param>

    <context-param>
        <description>
            This parameter tells MyFaces if javascript code should be allowed in the
            rendered HTML output.
            If javascript is allowed, command_link anchors will have javascript code
            that submits the corresponding form.
            If javascript is not allowed, the state saving info and nested parameters
            will be added as url parameters.
            Default: "true"
        </description>
        <param-name>org.apache.myfaces.ALLOW_JAVASCRIPT</param-name>
        <param-value>true</param-value>
    </context-param>
    
    <context-param>
        <description>
            This parameter tells MyFaces if javascript code should be allowed in the
            rendered HTML output.
            If javascript is allowed, command_link anchors will have javascript code
            that submits the corresponding form.
            If javascript is not allowed, the state saving info and nested parameters
            will be added as url parameters.
            Default: "false"

            Setting this param to true should be combined with STATE_SAVING_METHOD "server" for
            best results.

            This is an EXPERIMENTAL feature. You also have to enable the detector filter/filter mapping below to get
            JavaScript detection working.
        </description>
        <param-name>org.apache.myfaces.DETECT_JAVASCRIPT</param-name>
        <param-value>false</param-value>
    </context-param>

    <context-param>
        <description>
            If true, rendered HTML code will be formatted, so that it is "human readable".
            i.e. additional line separators and whitespace will be written, that do not
            influence the HTML code.
            Default: "true"
        </description>
        <param-name>org.apache.myfaces.PRETTY_HTML</param-name>
        <param-value>true</param-value>
    </context-param> 

    <context-param>
       <description>
            If true, a javascript function will be rendered that is able to restore the
            former vertical scroll on every request. Convenient feature if you have pages
            with long lists and you do not want the browser page to always jump to the top
            if you trigger a link or button action that stays on the same page.
            Default: "false"
       </description>
       <param-name>org.apache.myfaces.AUTO_SCROLL</param-name>
        <param-value>true</param-value>
     </context-param>

=========================

Example of a filter to support file upload:

    <filter>
        <filter-name>extensionsFilter</filter-name>
        <filter-class>org.apache.myfaces.component.html.util.ExtensionsFilter</filter-class>
        <init-param>
            <param-name>uploadMaxFileSize</param-name>
            <param-value>1m</param-value>
            <description>Set the size limit for uploaded files.
                Format: 10 - 10 bytes
                        10k - 10 KB
                        10m - 10 MB
                        1g - 1 GB
            </description>
        </init-param>
        <init-param>
            <param-name>uploadThresholdSize</param-name>
            <param-value>100k</param-value>
            <description>Set the threshold size - files
                    below this limit are stored in memory, files above
                    this limit are stored on disk.

                Format: 10 - 10 bytes
                        10k - 10 KB
                        10m - 10 MB
                        1g - 1 GB
            </description>
        </init-param>
        <init-param>
            <param-name>uploadRepositoryPath</param-name>
            <param-value>/temp</param-value>
            <description>Set the path where the intermediary files will be stored.
            </description>
        </init-param>
    </filter>

After the changes were made, notes1 compiled without errors, but presented the following error from Tomcat at startup time:

This looks like a problem with the JSP files and how the Tool Bar Items are being specified.

July 6

Started experiments to reduce the first phase of the notes exercise to a minimum. The main.jsp file consists of the following XML:

<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<%@ taglib uri="http://sakaiproject.org/jsf/sakai" prefix="sakai" %>

<f:loadBundle basename="org.sakaiproject.tool.note.bundle.Messages" var="msgs"/>

<f:view>
<sakai:view_container title="#{msgs.pt_title_main}">
<sakai:view_content>
	<h:form>
		<sakai:messages />
             	<sakai:instruction_message value="#{msgs.pt_title_main}"/>             	
		<sakai:instruction_message value="#{NoteTool.instructionMessage}"/>
	</h:form>
</sakai:view_content>
</sakai:view_container>
</f:view>

A look at the JSF Example code reveals that taglibs are not referenced. Let's remove them for a start.
Also, a <sakai:view> is included inside of the <f:view>. Not clear what that does, but I can add it. It's
also not clear what view_container and veiw_content give us other than eye candy, so let's remove that, leaving:

<f:loadBundle basename="org.sakaiproject.tool.note.bundle.Messages" var="msgs"/>

<f:view>
<sakai:view title="Tag Usage Demos">
	<sakai:messages />
	<sakai:instruction_message value="#{msgs.pt_title_main}"/>             	
	<sakai:instruction_message value="#{NoteTool.instructionMessage}"/>
</sakai:view>
</f:view>

This is pretty darn simple. Let's see how it runs.
Compiles. Error on tomcat start:

There is a reference here to ToolBarItemRenderer, but it's not references in the main.jsp file.

The following imports are included in NotesTool:

import javax.faces.application.FacesMessage;
import javax.faces.context.FacesContext;
import com.sun.faces.util.MessageFactory;

Let's try removing these. Nope. Same error.
Backed up to "jsf-note1-070606" in case I need to revert. Older versions are also still around.

Verified the package name of org.sakaiproject.jsf.util.JsfTool in web.xml file.
Changed com.sun.faces.validateXml and com.sun.faces.verifyObjects both to false. Redeployed. No difference. Changed back.

July 10

Ran an updated on sakai_training. A large number of updates have been made. Perhaps my problem will be fixed.
Re-deployed. Problem still exists. Darn.

July 11

Downloaded all of Sakai 2.2 from the trunk tag.

July 12

Ok. Next step is to look at some other JSF-based tools that have been updated to Sakai 2.2. I think the syllabus tool falls into this catagory. Confirmed. It is using the Sun reference implementation, which is also good.

Going through the tags in web.xml one by one:

<?xml>
UTF encoding was added: encoding="UTF-8".

<web-app>
(no changes)

<display-name>
(no changes)

<description>
(no changes)

The syllabus tool has two servlets defined: one named "Faces Servlet" the other "sakai.syllabus". A third, "sakai.syllabus.filepicker" is commented out. Both of these have filter and filter-mapping tags associated with them.

In the sakai.request filter tag:

Removed "upload.enabled" and "http.session" parameters and their values.

A local context seems to be added to the syllabus, but the local.xml file is empty. This is a placeholder of some kind.

<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/local.xml</param-value>
</context-param>

The syllabus tool also adds a context listener as follows:

<listener>
<listener-class>org.sakaiproject.util.ContextLoaderListener</listener-class>
</listener>

I need to track this down and see what it does. It can be viewed here:
ContextLoaderListener.java

This is an extension of the Spring ContextLoaderListener, likely paired with the local.xml file above. I don't think the notes tool needs this capability, so will leave it out.

The RequestFilter code can be viewed here:
FilterRequest

Overall, there don't appear to be any changes that are likely to solve the load error. Still, let's redeploy and hope for the best. No dice, still fails with same exceptions notices. Interestingly, I noticed that the SU tool fails for the same reason. Hmmm. Could it be that this is not in the code or config files? It might be an environmental problem.

Sakai Mini Experiment

So let's try this. Trash tomcat. Install a clean one. Update sakai_min. Build and deploy it. See if SU tool fails. Compile notes into that environment and see if it works. Interestingly enough, it failed in sakai_mini as well. That strongly suggests that there is something wrong with either the environment, or perhaps a config problem in both SU and notes.

July 17

I thought perhaps the problem might be related to the use of <sakai:view>, so I changed it to <f:view>, deployed, but the problem remains. The main.jsp file currently looks like this:

<f:loadBundle basename="org.sakaiproject.tool.note.bundle.Messages" var="msgs"/>

<f:view>
<f:view title="Tag Usage Demos">
	<sakai:instruction_message value="#{msgs.pt_title_main}"/>             	
	<sakai:instruction_message value="#{NoteTool.instructionMessage}"/>
</f:view>
</f:view>

At this point, I'm pretty much convinced it's an environmental problem. The test case (note1) is almost a bare minimum, HelloWorld example. It can't be reduced much more than it is. What ever this problem is, though, it exists in sakai_mini as well. The final experiment is to build the full Sakai 2.2 environment and see if the problem is present there. After all, the Syllabus tool is a JSF app and is clearing the QA process, whereas the SU tool present in sakai_mini is failing the same way my example is.

Download took nearly an hour. Building took 2.5 hours, but built successfully!

July 18

Thinking about the problem this morning, I occurred to me that I hadn't compared Maven project files. Looking at the presentation tool in Sakai 2.2, I don't see any dependencies on JSF. This seems a bit strange to me. The dependencies are not included in the Syllabus Tool, either.

Commented out all references to JSF (widgets, JSTL, tags, etc.) in project file of note1. Built and deployed ok. Started tomcat. Didn't get the error I was getting before, but tomcat couldn't start up the note1 application. Couldn't load FacesServlet.

Ok, some signficant progress, but not quite success yet. Looks like the Maven dependencies was the problem. At a minimum, a JSF based Sakai tool needs:

The following are no longer needed:

• sakai-jsf-app
• taglibs, standard
• jstl
• sakai-jsf-widgets
• sakai-jsf-widgets-sun

Likely, these are included in the JsfTool now.

So, while the app doesn't generate any errors, it doesn't show any content, either. Shows a plain white screen.
This seems to be purely an application problem at this point. Inserting "<h2>Note Tool</h2>" into the main.jsf file in the <view> tag caused it to be displayed. I might have a package naming problem in the faces-config.xml file.

Package names are correct. The entire XML notation from main.jsf is being sent to the browser, so it's not be processed by JSF.

Above seems overblown. I uncommented all dependencies, except the one for sakai-jsf-widgets. No exceptions, but jsf file is not being processed. I really don't understand how the presentation tool gets away without having these included in the project.xml file.

July 19

Progress turns out to be superficial. While I'm no longer getting tomcat exceptions, the JSF file is not being rendered. Rather, the XML is passed through to the browser. So by inserting a <h2>, that is recognized and displayed in the browser, but JSF tags are not.

As such, I need to dig down an debug what's going on. Since this could be useful to others that follow, I'm going to keep notes in JSF Debugging.

Poking around in the JSF code, I found a presentation called "Sakai 2.0 Presentation Layer" that unfortunately can't be opened. It's in the devtools module. Digging deeper, I found a small app that seems to convert Velocity markup to JSF. Interesting, but not relevant to my quest.

JsfTool is located in the jsf/tool module. It is a Sakai Servlet to use for all JSF tools, which means that HTTP requests come through this. This code explains why JSF files must end in ".jsf" even though the spec supports other extensions. This is harded coded in JsfTool to differientiate
requests for a JSF page from a resource.

Notes application is giving a 404 error on /note/note/main.jsf. We have a path problem here.
Commented out the path parameter:

        <init-param>
            <param-name>path</param-name>
            <param-value>/note</param-value>
        </init-param>

Now I get a JSF error page, plus an exception in Tomcat:

Still have a path problem. Taking out the path parameter doesn't help when it comes time to reference the page.
Removed comments on note path. Redeployed. Started from Mercury this time and got a blank page (XML Pass Through).

Looking at catalina.out I see:

This means that JsfTool is being invoked twice, once with a null target, and once with /main. More information is called for.
Running into maven problems. Changes to JsfTool are not being deployed, for whatever reason.

July 27

Back from several days on vacation to Canada.

The fact that JSF is not working for me is of continuing concern. There are no clues from the Sakai 2.2 release notes that anything major was changed in JSF support. In fact, it's unlikely. There was a lot of change in the package naming, which
conceivably could have an impact, but that's likely to result in an exception, which I'm not seeing here.

I've given some thought to the JSF support in Sakai over the past week. The Sun reference implementation is getting further
behind in general usage. As such, it might be best to switch over MyFaces and be done with it. Unfortunately, I know less
about working with MyFaces than Sun-JSF. Some research is in order. I'll document these in MyFaces Notes.

After compiling some notes about MyFaces, it's time to think about preparing an experimental environment in which to play.
Ideally, this should be the sakai_training environment, since that's what I want people to use in workshops. So I'm gonna
blow away Tomcat, update sakai_training to reflect the trunk and rebuild it. Hopefully, this will also solve the maven
problems I was seeing last week.

Updated sakai_training. Lots of changes, but only one minor changes to message bundle in JSF examples.
The sakai_training environment built in 5 minutes, 58 seconds, successfully.

The first experiment is to attempt to clone the example that is included in the JSF module, and then simplify it by eliminating everything that is not needed. Extensive analysis made of the JSF Example included with JSF Module of Sakai.

July 28, 2006

So time to see if we can convert the examples into being a standalone JSF tool on it's own. Given that this is an attempt to create a Hello World test of MyFaces, we can call this example "hello". Backed up example into example-072806.

Changed top level directory to hello.

Changes to maven project file

Changed id to "hello".
Left dependency on sakai-jsf-tool in place and uncommented it.
Left dependencies on sakai-jsf-app and sakai-util-web in place and uncommented it.
Removed dependencies on jsf-api and jsf-impl which are for Sun RI.
Removed dependency on sakai-jsf-widget-sun which is for Sun RI.
Removed dependencies on commons-fileupload, commons-collections, commons-logging which are auto-provided by Sakai.

Files removed from webapp directory
Removed all JSF files except index.jsp.

Files removed from bundle
Copied Messages.properties to bundle directory.
Deleted all sub directories and other property files.

Files removed from src/java/example
All java files deleted.
Created an org/sakaiproject/hello path under src/java.
Created a new java file called HelloTool.java.

The HelloTool class is pretty simple at this point:

package org.sakaiproject.hello;

public class HelloTool {

	private String sample = "Welcome to the Hello World Example.";

    public String getSample()
    {
        return this.sample;
    }
}

Module now builds successfully under Maven.

Changes to faces-config.xml
Removed example.ExampleBean, example.PagerBean, and example.SimplePropsBean as managed beans.
Added org.sakaiproject.hello.HelloTool as a managed bean.
Removed all navigation cases except "index.jsp".

faces-config.xml now looks like this:

<?xml version='1.0' encoding='UTF-8'?>

<!DOCTYPE faces-config PUBLIC
  "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN"
  "http://java.sun.com/dtd/web-facesconfig_1_0.dtd">

<faces-config>

	<application>
		<locale-config>
			<default-locale>en_US</default-locale>
		</locale-config>
	</application>

	<managed-bean>
		<description>
			Example backing bean for the hello world example.
		</description>
		<managed-bean-name>helloTool</managed-bean-name>
		<managed-bean-class>org.sakaiproject.hello.HelloTool</managed-bean-class>
		<managed-bean-scope>session</managed-bean-scope>
	</managed-bean>


	<navigation-rule>
		<navigation-case>
			<from-outcome>index</from-outcome>
			<to-view-id>/index.jsp</to-view-id>
			<redirect />
		</navigation-case>
	</navigation-rule>
</faces-config>

Changes to web.xml
Changed display name to hello.
Removed commentings from org.sakaiproject.util.ToolListener.
Uncommented servlet definition for org.sakaiproject.jsf.util.JsfTool. Named to hello.
Removed jsp-confg tag section. Header and footers will no longer be included.
Removed the extensionsFilter filter definition and filter mapping.
Removed the View Source Servlet servlet definition.
Removed the View Source Servlet servlet mapping.

The final web.xml file looks like this:

<?xml version="1.0"?>

<web-app id="WebApp_9" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">

    <display-name>hello</display-name>
    <description>Example Sakai 2.0 JSF Widgets Webapp</description>

    <!-- MyFaces JSF - Listener, that does all the startup work (configuration, init). -->
    <listener>
        <listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
    </listener>
	
    <!-- Listener which registers Sakai tools -->
    <listener>
        <listener-class>org.sakaiproject.util.ToolListener</listener-class>
    </listener>

    <!-- Sakai request filter, mapped to anything that goes to the faces servlet -->
    <!-- You can set upload.enabled for Sakai to handle file uploads, or upload.enabled=false and use a custom non-Sakai filter -->
    <filter>
        <filter-name>sakai.request</filter-name>
        <filter-class>org.sakaiproject.util.RequestFilter</filter-class>
        <init-param>
        	<param-name>upload.enabled</param-name>
        	<param-value>false</param-value>
        </init-param>
        <init-param>
        	<param-name>http.session</param-name>
        	<param-value>container</param-value>
        </init-param>
    </filter>

    <filter-mapping>
        <filter-name>sakai.request</filter-name>
        <url-pattern>/*</url-pattern>
        <dispatcher>REQUEST</dispatcher>
        <dispatcher>FORWARD</dispatcher>
        <dispatcher>INCLUDE</dispatcher>
    </filter-mapping>
    
    <!-- Sakai JSF Tool Servlet -->
    <servlet>
        <servlet-name>hello</servlet-name>
        <servlet-class>org.sakaiproject.jsf.util.JsfTool</servlet-class>
        <init-param>
            <param-name>default</param-name>
            <param-value>index</param-value>
        </init-param>
        <init-param>
            <param-name>path</param-name>
            <param-value>/</param-value>
        </init-param>
        <init-param>
            <param-name>default.last.view</param-name>
            <param-value>true</param-value>
        </init-param>
        <load-on-startup> 1 </load-on-startup>
    </servlet>

    <!-- Faces Servlet -->
    <servlet>
        <servlet-name>Faces Servlet</servlet-name>
        <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
        <load-on-startup> 2 </load-on-startup>
    </servlet>
    
    <!-- Faces Servlet Mapping -->
    <!--

         This mapping identifies a jsp page as having JSF content.  If a
         request comes to the server for foo.jsf, the container will
         send the request to the FacesServlet, which will expect a
         corresponding foo.jsp page to exist containing the content.

    -->
    <servlet-mapping>
        <servlet-name>Faces Servlet</servlet-name>
        <url-pattern>*.faces</url-pattern>
    </servlet-mapping>

    <servlet-mapping>
        <servlet-name>Faces Servlet</servlet-name>
        <url-pattern>*.jsf</url-pattern>
    </servlet-mapping>
    
    <welcome-file-list>
	<welcome-file>index.html</welcome-file>
	<welcome-file>index.jsf</welcome-file>
    </welcome-file-list>

    <!--  Boiler-plate JSF configuration below -->
    <!-- 
    <context-param>
        <param-name>javax.faces.CONFIG_FILES</param-name>
        <param-value>
            /WEB-INF/examples-config.xml
        </param-value>
        <description>
            Comma separated list of URIs of (additional) faces config files.
            (e.g. /WEB-INF/my-config.xml)
            See JSF 1.0 PRD2, 10.3.2
        </description>
    </context-param>
    -->
    
    <context-param>
        <description>
            State saving method: "client" or "server" (= default)
            See JSF Specification 2.5.2
        </description>
        <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
        <param-value>server</param-value>
    </context-param>

    <context-param>
        <description>
            This parameter tells MyFaces if javascript code should be allowed in the
            rendered HTML output.
            If javascript is allowed, command_link anchors will have javascript code
            that submits the corresponding form.
            If javascript is not allowed, the state saving info and nested parameters
            will be added as url parameters.
            Default: "true"
        </description>
        <param-name>org.apache.myfaces.ALLOW_JAVASCRIPT</param-name>
        <param-value>true</param-value>
    </context-param>
    
    <context-param>
        <description>
            This parameter tells MyFaces if javascript code should be allowed in the
            rendered HTML output.
            If javascript is allowed, command_link anchors will have javascript code
            that submits the corresponding form.
            If javascript is not allowed, the state saving info and nested parameters
            will be added as url parameters.
            Default: "false"

            Setting this param to true should be combined with STATE_SAVING_METHOD "server" for
            best results.

            This is an EXPERIMENTAL feature. You also have to enable the detector filter/filter mapping below to get
            JavaScript detection working.
        </description>
        <param-name>org.apache.myfaces.DETECT_JAVASCRIPT</param-name>
        <param-value>false</param-value>
    </context-param>

    <context-param>
        <description>
            If true, rendered HTML code will be formatted, so that it is "human readable".
            i.e. additional line separators and whitespace will be written, that do not
            influence the HTML code.
            Default: "true"
        </description>
        <param-name>org.apache.myfaces.PRETTY_HTML</param-name>
        <param-value>true</param-value>
    </context-param>

    <context-param>
       <description>
            If true, a javascript function will be rendered that is able to restore the
            former vertical scroll on every request. Convenient feature if you have pages
            with long lists and you do not want the browser page to always jump to the top
            if you trigger a link or button action that stays on the same page.
            Default: "false"
       </description>
       <param-name>org.apache.myfaces.AUTO_SCROLL</param-name>
        <param-value>true</param-value>
     </context-param>
	
</web-app>

Changes to Sakai Tool registration
Changed name of tool registration file to hello.xml.
Changed id to hello.

This file now looks like this:

<?xml version="1.0"?>

<registration>
	<tool
		id="hello"
		title="Hello World Example"
		description="Example of a very simple MyFaces based Sakai tool.">

		<category name="sakai.sample" />
		<configuration name="sample.confg" value="false" />
	</tool>
</registration>

Changes to index.jsp
Changed view title to "Hello World Example".
Removed all commandLinks.

The index.jsp file now looks like this:

<f:view>
	<sakai:view title="Hellow World example">
		<f:verbatim><br /></f:verbatim>
		<h:outputText value="Hello World" />
	</sakai:view>
</f:view>

Other Changes
Deleted src/webapp/css and src/webapp/include. These shouldn't be needed.
Delete src/bundle/Message/metaprops. These have to do with internationalization and won't be needed.
Removed all message definitions in src/bundle/Messages.properties.

Attempt to build fails with this error message:

The name of the web utils jar has changed. Need to track it down and make the change. I encountered this while trying to fix the note example.

Replaced the "sakai-util-web" dependency with:

		<dependency>
			<groupId>sakaiproject</groupId>
			<artifactId>sakai-util-api</artifactId>
			<version>${sakai.version}</version>
			<properties>
				<war.bundle>true</war.bundle>
			</properties>
		</dependency>
		
		<!--  New for 2.2. -->
		<dependency>
			<groupId>sakaiproject</groupId>
			<artifactId>sakai-util</artifactId>
			<version>${sakai.version}</version>
			<properties>
				<war.bundle>true</war.bundle>
			</properties>
		</dependency>

Builds correctly now. The next step is to fire up Tomcat and see if any errors are generated.
Errors are generated from GroupProvider and SU Tool, but I didn't see any errors with the HelloTool.
Had to enable Mercury in sakai.properties in tomcat/sakai directory.
Hello tool didn't show up under sakai.sample in Mercury. Forgot to deploy it. Heh heh.

Showed up in Mercury, correctly. On launch, displays a blank page. Looking at source shows that XML was passed through once again. There is no difference between the Sun-RI or MyFaces in terms of this bug, whatever it is. So I'm back to debugging Sakai JSF.

Aug 1

Since work on the notes tool is stalled until I can figure out the bug in my JSF code, I started work on the design of the integration exercises. Laid out a page that will describe the database model to be used, and sketched out an intial design for a user display tool that can be used as the front end to the User Provider Exercise and the providers built for it.

Aug 8

I spoke with Chuck a few days ago. He had the following recommendation concerning JSF problems:

I wold start with the Syllabus tool and work backwards. Wen Chen is very strong and writes pretty clean code.

He also suggested checking to see if the JSF examples application actually runs.
My recollection proved true in that the configuration files are not enable to make these examples visible as a Sakai tool. I also tried sakai-jsf-examples, but that failed as well (not found). After hunting through the web.xml and project.xml file, uncommenting a few things and updating them to 2.2, sakai.sample.jsf.widgets-2 seems to work. It's not very complete, but the JSF is obviously working.

Well, this is good news and bad news. It means that somewhere along the line, I screwed up, since the hello world example is derived from this very application. Ok, back to the begining, again.

Made a backup of current work into mjn-jsf-080806.

Cloning the JSF Examples

Copied jsf/examples to jsf-mjn/examples.
Renamed directory to hello2.
Changed id in project.xml to hello2. All else is unchanged (includes previous changes made to make JSF examples to work).
Renamed tools/sakai.sample.jsf.widgets-2 to tools/sakai.sample.hello2, changed data in it as well.
Changed sakai.sample.jsf.widgets-2 to sakai.sample.hello2 in one place (servlet tag) in web.xml.

These changes should put this example application into a different web application named sakai.sample.hello2.
Built hello2. No errors.
Loads in tomcat without errors.
Launches from Tomcat and displays pages.

While exploring the examples (most of which seem to be placeholders, BTW), I came across the <sakai:debug> tag, which dumps an interesting assortment of information to the displayed page. This could be useful.

Simplifying the Example

Ok, now that we have a working application sandbox, let's try to reduce it to a simple hello world example. Ideally, I'd like to get it to the point where it simply works, then compare it back to the broken example and see what's different. I'm going to be much more methodical about elminating elements of the example, compling and and testing more often. Taking too big a jump is probably what did me in the last time.

Removed the commented out section labeled as follows from web.xml:
"MyFaces custom file upload filter - usable with the Sakai JSF inputFileUpload tag!"
There is a section on "Boiler-plate JSF configuration" also commented out that was left in. This may be useful later.

Reading through the web.xml file, I note the coda and prelude files that I removed previously. I wonder if the prelude was, in fact needed.

Re-deployed. Still working.

It seems like the index.jsp is the default entry point into this example.

Simplified index.jsp to be:

<f:view>
<sakai:view title="Tag Usage Demos">

<h2>Hello World Example</h2>

</sakai:view>
</f:view>

Re-deployed. Still working.

This is not quite where the Hello World example should be. That would require code changes and references to new messages in the bundle. Rather than going down that path, however, I'm going to try and continue to eliminate files and other elements that are clearly no longer needed, staring with other JSP files. Removed 32 JSP files from src/webapp.

Re-deployed. Still working.

The next step would be the elimination of code. There are three java classes referenced by faces-config.xml:

• example.PagerBean
• example.ExampleBean
• example.SimplePropsBean

In addition, the following classes are included:

• example.Clock
• example.Grade
• example.ViewSourceServlet
• example.Wizard

ViewSourceServlet is referenced in web.xml, leaving Clock, Grade, and Wizard unreferenced (not true, they were referenced from ExampleBean, see discovery, Aug. 8). These were deleted.

Re-deployed. Still working.

The next step is to eliminate remaining code. None of this is referenced by JSF pages anymore and so should be unneeded.
I will move over the code developed for previous example (that failed) and see if it will work in this new setting.

Aug. 8

Simplifying the Example, Continued

A search of web.xml didn't turn up ViewSourceServlet, so it isn't being set up as a servlet. That code can be eliminated.
Well, it looks like these code modules are designed to work together (go figure!). Build failed. Can't find Wizard or Grade
objects. Probably the best step is to wipe Example Bean down to bare minimum.

Re-built, compiles without error now. However, I get a class not found error when launched from Mercury on VeiwSourceServlet.
Found the servlet definition in web.xml. There was a problem in that I can deleted this but hadn't saved out the changes. Removed servlet definition and corresponding mapping tag for .source files.

Rebuilt and redeployed. Runs again.

Deleted PagerBean and SimplePropBean.

Re-deployed. Still working.

Having removed the code, we can now remove the managed-bean references in faces-config.xml. I'm also removing the unneeded navigation rules. This gives us a very simple faces-config.xml file:

<?xml version='1.0' encoding='UTF-8'?>

<!DOCTYPE faces-config PUBLIC
  "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN"
  "http://java.sun.com/dtd/web-facesconfig_1_0.dtd">

<faces-config>

	<application>
		<locale-config>
			<default-locale>en_US</default-locale>
		</locale-config>
	</application>

	<managed-bean>
		<description>
			Example backing bean for multiple example pages
		</description>
		<managed-bean-name>examplebean</managed-bean-name>
		<managed-bean-class>example.ExampleBean</managed-bean-class>
		<managed-bean-scope>session</managed-bean-scope>
	</managed-bean>

	<navigation-rule>
		<navigation-case>
			<from-outcome>index</from-outcome>
			<to-view-id>/index.jsp</to-view-id>
			<redirect />
		</navigation-case>
	</navigation-rule>
</faces-config>

Re-deployed. Still working.

We're getting pretty close to the hello world example now. Remaining to be done are:

1. Eliminate CSS material (shouldn't be needed).
2. Eliminate the alternative language bundle files.
3. Eliminate the header and footer JSP includes.
4. Migrate HelloTool in.
5. Migrate the HelloTool bundle messages in.

The first two (css and languages) should be removable without problem. There are no more references to the local style sheet that I can see, so I should be able to just delete it. I only need one message.properties file. Alternate languages are out of scope of the workshops currently being presented. So let's try pulling them and see what happens. Deleted 14 langauge files, leaving Messages.properties and Messages.metaprops. Deleted the metaprops file, since it seemed to refer largely to the announcement tool.

Re-deployed. Still working.

Ok, we are getting right down to it now. I'm going to leave the header and foot includes alone, since I now strongly suspect that this is where the previous problems were. First, I'll copy over HelloTool.java. I changed the package definition to example, so that I can separate out package migration for later.

Re-deployed. Still working.

Ran as expected. I haven't wired in HelloTool as a managed bean yet, so as long as it compiles, the code should still run just fine. Given that the current index.jsp file doesn't refer to anything the code body yet, I should be able to switch ExampleBean and HelloTool as managed beans in the faces-config.xml file. The managed-bean section now reads as:

	<managed-bean>
		<description>
			Backing bean for the Hello World example.
		</description>
		<managed-bean-name>examplebean</managed-bean-name>
		<managed-bean-class>example.HelloTool</managed-bean-class>
		<managed-bean-scope>session</managed-bean-scope>
	</managed-bean>

Re-deployed. Still working.

Now we can attempt to access the backing bean from the example page. Code from the failed example reads:

<f:view>
	<sakai:view title="Hellow World example">
		<f:verbatim><br /></f:verbatim>
		<h:outputText value="Hello World" />
	</sakai:view>
</f:view>

This doesn't draw anything from either the bundle or the backing bean, but it's pretty close to what we have in the hello2 example right now:

<f:view>
<sakai:view title="Tag Usage Demos">

<h2>Hello World Example</h2>

</sakai:view>
</f:view>

So let's modify it a bit to eliminate the static HTML in the JSF page:

<f:view>
<sakai:view title="Tag Usage Demos">
<h:outputText value="Hello World" />
</sakai:view>
</f:view>

Re-deployed. Still works with new material.

I had a look at the HTML produced, which looks like this:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<title>Tag Usage Demos</title>
<link href="/library/skin/tool_base.css" type="text/css" rel="stylesheet" media="all" />
<link href="/library/skin/default/tool.css" type="text/css" rel="stylesheet" media="all" />
<script type="text/javascript" language="JavaScript" src="/library/js/headscripts.js"></script>
</head>
<body onload="setMainFrameHeight('Mainb0ef866cxcf9dx4a98x0069x60fbec6df381');setFocus(focus_path);">

<div class="portletBody">

		Hello World
	</div></body></html>
<script type="text/javascript"><!--
function getScrolling() {
    var x = 0; var y = 0;
    if (self.pageXOffset) {
        x = self.pageXOffset;
        y = self.pageYOffset;
    } else if (document.documentElement && document.documentElement.scrollLeft) {
        x = document.documentElement.scrollLeft;
        y = document.documentElement.scrollTop;
    } else if (document.body) {
        x = document.body.scrollLeft;
        y = document.body.scrollTop;
    }
    return x + "," + y;
}

//--></script>

Note the Javascript entry after the closing html tag. This is malformed HTML, but again, out of the scope of this project.

It might be time to see about dropping the header and footer files. Commented out the jsp-config tag in web.xml.

Re-deployed. Darn. It still works. I though for sure this would be the problem. (In retrospect, there is no reason why this should have caused the problem since the contents of head.inc were inserted into main.jsp).

Let's have a close look at each of the web.xml files. A close comparison doesn't reveal much in the way of differences:

• upload.enabled in hello is true, while it's false in hello.

That's about it. I also note that org.apache.myfaces.AUTO_SCROLL is probably responsible for that extra Javascript generation.

So let's set upload.enabled to false and see what happens.

Re-deployed. Nope. Still works. Ran a full file compare, nothing but minor differences (spacing, app name, etc.). So it really looks like the problem wasn't in web.xml, which is surprising given the way it failed (render not done).

Here's an interesting speculation. I note that the default file name in both web.xml files is "index". However, in the hello example, the default page was changed to main. How did the hello app know to start up with main.jsp? The welcome files are defined to be index in both cases as well. No, wrong track. I used main.jsp in the original training example, the hello example used index.jsp. So that's not the problem.

The Messages.properties file was moved way up in the directory path under "bundle".

Ok, next up to to reference the backing bean. The original Note exercise had this for an initial JSF page:

<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<%@ taglib uri="http://sakaiproject.org/jsf/sakai" prefix="sakai" %>

<f:loadBundle basename="org.sakaiproject.tool.note.bundle.Messages" var="msgs"/>

<f:view>
<sakai:view_container title="#{msgs.pt_title_main}">
<sakai:view_content>
	<h:form>
        	<sakai:messages />
        	<sakai:instruction_message value="#{NoteTool.instructionMessage}"/>
	</h:form>
</sakai:view_content>
</sakai:view_container>
</f:view>

Did a side-by-side comparison of faces-config.xml files between hello and hello2 example. They are identical except for one thing: the hello example references "helloTool" as a backing bean, while it's "HelloTool in hello2. Well, that might just do it. However, that wasn't it either. While that is a bug, it's not THE bug, because the hello example doesn't reference the backing bean, either. As long as it doesn't, it shouldn't generate an error.

Did a side-by-side comparison of maven project files. I note that support for external JSF use is included in hello2 and not in hello. Move it over to try it out.

Re-deployed hello. Still fails.

Minor changes made to project.xml for hello2.

Re-deployed hello2. Still works. Hmm.

Copied all of web.xml from hello2 to hello.

Re-deployed hello. Still fails. That pretty much rules out a web.xml problem. Running out of things to look at. Directory strutures are still different.

Moved Messages.properties up directory structure to just under bundle.

Re-deployed hello2. Still works.

Moved HelloTool.java up to src/java/example. Changed faces-config.xml to reflect this. Deleted old code under org/sakaiproject.

Re-deployed hello. Still fails. At this point, even the directory structures are very close to being the same.

Deleted ExampleBean.java from Hello2.

Re-deployed hello2. Still works.

Include directory still present in hello2. Deleted.

Re-deployed hello2. FAILS!!!!!!!!!

Restored include file. Still FAILS!!!!! NOOOOOOO!!!!!!

Failure of JSF Examples

So, we've verified that the failure is tied to the include directory, though restoring it should have worked.

Tried several things to restore the app. None of them worked including flushing the cache (also flushed cookies, which was a bad idea in the middle of a confluence edit, lost some text) and deleting entries in the maven repository including POMs.

Try renaming the app and see if the older version will return to working condition. It may also be possible to build an app from the ground up, instead of pruning down the example code.

Aug. 15

Just got around to testing hello2 after rebuilding Tomcat environment (also threw away Maven repository). Still fails. This is very odd, since the version of the code I'm using is a back up before I removed the include directory (see failure mode, above). something is getting cached somewhere, but I have not idea where, given I've rebuilt Tomcat from scratch. Perhaps it is something about the enviroment as it is built by Maven.

Checked the JSF examples problem, that's still working just fine.

Meanwhile, I've thought of another approach. Suppose I start from a servlet-based application, and migrate it towards being a JSF application. There are some advantages to this. It works well from a pedagogical point of view in the workshop, since I start wtih a servlet example.

Created a hello3 app in jsf-mjn by copying simple1.
Cloning successful. Compiled, deployed, and runs without error.

Copied over the following files from hello2:

1. bundle/*
2. src/java/exampe/*
3. src/webapp/index.jsp
4. src/webapp/WEB-INF/faces-config.xml

The one signficant file NOT copied was web.xml, as that will require some merging.
First we compile the app as is, with no JSF support, but the materials in place.
Got some package import errors on compile, all on components that are not being used.
Commented them out. Now compiles. Redeployed.

Ok, more weirdness. I tried changing the hello world message in SimpleTool.java. Recompiles, doesn't show. Removed war and target from Tomcat and app, recompile, still doesn't show. Hmm. There is some similarity to the problem I was seeing with the JSF problem here: a problem happened, then no amount of tinkering could make it go away.

I checked my build.properties file, but maven was correctly referenced.
Checked environment variables, tomcat is NOT included in path. It is on my laptop. Added it back in.
Re-compiled, redployed. Still broken (Reads "Hello World" instead of "Hello World 3!"

Moved the jsf-mjn directory and apps over to laptop.

Aug 16

Rebuilt the whole environment. Hello2 still fails. Hello3 runs correctly.

Aug 17

Continued work on the Servlet to JSF Migration approach.
Moved simple tool from org.sakaiproject.tool.simple to example. This puts all code into the same Java package. Changed web.xml to reflect change.
Compiles and runs (still a servlet at this point).

To convert this to a JSF aplication we need to:

1. add a reference to StartupServletContextListener (MyFaces context initializer)
2. add JsfTool as a servlet.
3. add FacesServlet as a servlet (is this true? Is this a Sun RI thing?)
4. define servlet mappings for JSF
5. define the welcome file (if needed)
6. add JSF Configuration (I'm going to try relying on defaults for first plass)

It's interesting that (according to these setup files) MyFaces uses the Sun controller (FacesServlet). That's not what I'd expect if I thought about it.

Copied over all but configuration parameters into hello3 web.xml.
Commented out hello3 servlet definition and mappings.

Redeployed. Failed. Tomcat startup error, can't find StartupServletContextListener. This is a maven dependency problem. Added missing dependences (there are a lot of them).

Redeployed. Failed. Null pointer error on forwarding request in Mercury. Servlet definition to JsfTool copied over as hello2, instead of hello3.

Redeployed. Unrendered content failure mode now exists. Two blocks of code where moved over: in web.xml and and maven project.xml. It is possible that the dependencies are wrong, either in naming the wrong things or in version numbers. I believe I checked verison numbers previously, but they should be checked again. Configuration parameters were not included in the web.xml file, so they can be ruled out.

Aug. 22

Attempted to turn on logging for JsfTool by adding entry in conf/logging.properties. That didn't work.
Read up in the logger documentation. There is a log4j.properties file in the logger service. Finding the logger wasn't easy, however. This file is buried in the utils project.

Added this line:

• log4j.logger.org.sakaiproject.jsf.util.JsfTool=DEBUG

This resulted in a single line of data in catalina.out:

This isn't enough data. There's isn't any good way to look at the response content, either. Servlet doesn't provide a way to look at the results in HttpServletRespose, only write to an OutputStream. JsfTool isn't do a lot of work here. It's setting up some environment properties, conditioning things abit, and making sure the context is correct.

Had a look at the MyFaces repository. It's hard to find the exmples, though they are there. I only found one example of a web.xml file at:

http://svn.apache.org/repos/asf/myfaces/legacy/tags/rel_1_0_9_rc3/conf/web.xml

This file references FacesServlet, so I guess that's the right way to do it.
It references the StartupServletContextListener to handle context parameters.

Six context parameters are included:

    <context-param>
        <param-name>javax.faces.CONFIG_FILES</param-name>
        <param-value>
            /WEB-INF/examples-config.xml
        </param-value>
        <description>
            Comma separated list of URIs of (additional) faces config files.
            (e.g. /WEB-INF/my-config.xml)
            See JSF 1.0 PRD2, 10.3.2
        </description>
    </context-param>

    <context-param>
        <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
        <param-value>server</param-value>
        <description>
            State saving method: "client" or "server" (= default)
            See JSF Specification 2.5.2
        </description>
    </context-param>

    <context-param>
        <param-name>org.apache.myfaces.ALLOW_JAVASCRIPT</param-name>
        <param-value>true</param-value>
        <description>
            This parameter tells MyFaces if javascript code should be allowed in the
            rendered HTML output.
            If javascript is allowed, command_link anchors will have javascript code
            that submits the corresponding form.
            If javascript is not allowed, the state saving info and nested parameters
            will be added as url parameters.
            Default: "true"
        </description>
    </context-param>
    
    <context-param>
        <param-name>org.apache.myfaces.DETECT_JAVASCRIPT</param-name>
        <param-value>false</param-value>
        <description>
            This parameter tells MyFaces if javascript code should be allowed in the
            rendered HTML output.
            If javascript is allowed, command_link anchors will have javascript code
            that submits the corresponding form.
            If javascript is not allowed, the state saving info and nested parameters
            will be added as url parameters.
            Default: "false"

            Setting this param to true should be combined with STATE_SAVING_METHOD "server" for
            best results.

            This is an EXPERIMENTAL feature. You also have to enable the detector filter/filter mapping below to get
            JavaScript detection working.
        </description>
    </context-param>

    <context-param>
        <param-name>org.apache.myfaces.PRETTY_HTML</param-name>
        <param-value>true</param-value>
        <description>
            If true, rendered HTML code will be formatted, so that it is "human readable".
            i.e. additional line separators and whitespace will be written, that do not
            influence the HTML code.
            Default: "true"
        </description>
    </context-param>

    <context-param>
        <param-name>org.apache.myfaces.AUTO_SCROLL</param-name>
        <param-value>true</param-value>
        <description>
            If true, a javascript function will be rendered that is able to restore the
            former vertical scroll on every request. Convenient feature if you have pages
            with long lists and you do not want the browser page to always jump to the top
            if you trigger a link or button action that stays on the same page.
            Default: "false"
        </description>
    </context-param>

Aug 28

Spend a fair amount of time over the past few days updating the old training presentations to Sakai 2.2 and working on the new presentations for the System Integration workshop. Things are starting to look pretty good there, thoug I still have to resolve the JSF problem and update those presentations as a result.

In terms of the Systems Integration workshop, it's time to start working on the database and the sample code. That will enable to me to put together the exercise presentations, etc. The CD-ROM image needs substantial work as well, since it was originally designed for the SKB environment and needs to be completley updated for the sakai_training environment.

Aug. 29

I was driving this morning thinking about that JSF problem. One thing that occurs to me is the XML schema references at the top of each page. These were included by the JSP header mechanism and I though I included them in the JSF pages, but that's worth checking. I don't seem to recall them coming through in the unrended XML that appeared in the browser. Maybe they are strictly required now, or the Sakai components changed in a way that no longer auto-includes them.