Written by: Dan HinojosaSat, 5 Jan 2008 02:33 PM PST .
Filed Under: SeamDaniel HinojosadbunitJSFJBoss SeamxmlunitseleniumJBosspresentationXML UnitJBoss World 2008easymock

I was accepted to present at JBoss World 2008 about a couple of months ago, and I am just about done crafting my presentation. My presentation highlights how to unit-test, integration-test, and acceptance test your jboss seam web applications.

The presentation will use a slew of technologies from easymock to selenium. I only have a measly 90 minutes to go through it all, but I hope and anticipate that it will be exciting, entertaining , and informational.

My bio and information about the presentation is here. For complete information on JBoss World 2008 in Orlando and other presentations that will be presented, please visit jbossworld.com

1 comment for Agile Development Using JBoss Seam @ JBoss World 2008 in Orlando

Written by: Dan HinojosaWed, 1 Feb 2006 10:30 AM PST .
Filed Under: MyFacesJSFJava Server FacesJBossNullPointerException

If you are trying to get JSF-RI and JBoss 4.0.3 to work with each other, you are in for a special surprise. The following code will help de-stupefy the situation:

java.lang.NullPointerException
        at javax.faces.webapp.UIComponentTag.setupResponseWriter(UIComponentTag.java:615)
        at javax.faces.webapp.UIComponentTag.doStartTag(UIComponentTag.java:217)
        at org.apache.myfaces.taglib.core.ViewTag.doStartTag(ViewTag.java:71) 

The NullPointerException is a result of a collision with the JSF-RI. This error occurs only with JBoss 4.0.3 because it comes packaged with MyFaces. The following solution was recommended by JBoss in their wiki.

Fix for the all configuration

The all configuration has something missing from the all/deploy/jbossweb-tomcat5.5.sar/meta-inf/jboss-service.xml file. If using the all configuration with JSF you should edit the value of the FilteredPackages attribute to make it look like this:

<attribute name="FilteredPackages">javax.servlet,org.apache.commons.logging</attribute>

Note that there should be no space on either side of the comma. For more details on this issue, see http://jira.jboss.com/jira/browse/JBAS-2349

Using the JSF Reference Implementation

To use the JSF Reference Implementation instead of the bundled MyFaces implementation, simply delete the jbossweb-tomcat55.sar/jsf-lib directory. Then, package the RI in your WEB-INF/lib directory as usual.

Note: You may also need to delete temp directories such as server/default/tmp and server/default/work. See comment by Geoffery in http://jira.jboss.com/jira/browse/JBAS-1508

I hope that helps.

1 comment for Getting JBoss 4.0.3 to work the JSF-RI

Written by: Dan HinojosaMon, 12 Sep 2005 03:32 PM PDT .
Filed Under: JSFWishList

I like JSF, but there are too many times where I violate the DRY (Don't redo yourself) principle. One such case is when using JSPs in JSF. The JSPs in JSF are too tightly coupled with the managed beans specified in the faces-config.xml. You must always explicitly set a bean into the JSP to be able to use it. If you want a page that is identical to one that you have just created, except that you want it to use a different bean, you can copy and paste your code into the identical page and then go back and set the bean so that it refers to an entirely different bean. But, in Object Oriented Programming, copy and paste can be a bad thing, and should always throw up a red flag.

My suggestion is to create an XML entity called managed-page for faces-config.xml. This entity would provide a developer with the option to set the reference to an entirely different bean than is specified in the JSP file. Let me provide an example.

Example of using managed-pages in faces-config.xml

<managed-page>
    <name>dogs.jsp</name>
    <root-page>animals.jsp</root-page>
    <managed-property>
           <property-name>animalBean</property-name>
           <value>#{dogBean}</value>
    </managed-property>
</managed-page>

<managed-page>
    <name>cats.jsp</name>
    <root-page>animals.jsp</root-page>
    <managed-property>
           <property-name>animalBean</property-name>
           <value>#{catBean}</value>
    </managed-property>
</managed-page>

In this example, the managed-page items give the end user the impression that two separate pages, called dogs.jsp and cats.jsp, exist. In actuality, both JSPs use the same page, but use different beans. The programmer can still use the animals.jsp page - it would just resolve to whatever #{animalBean} is. Here is an example page of animals.jsp that is used by the virtual dogs.jsp and cats.jsp.

Example of a reuseable page

<%@page contentType="text/html"%>
<%@page pageEncoding="UTF-8"%>
<%@taglib uri="http://java.sun.com/jsf/core" prefix="f"%>
<%@taglib uri="http://java.sun.com/jsf/html" prefix="h"%>
<%@taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c"%>
<%@taglib uri="http://myfaces.apache.org/extensions" prefix="x"%>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   "http://www.w3.org/TR/html4/loose.dtd">

<html>
    <f:view locale="en_US">
        <head>
            <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
            <f:loadBundle basename="standard" var="standard"/>
            <f:loadBundle basename="label" var="label"/>
            <title><h:outputText value="#{standard.animals}"/></title>
        </head>
        <body>
            <h:form>
                <h:graphicImage value="#{animalBean.image}"/>
                <h:dataTable value="#{animalBean.dataModel}" var="animal">
                    <h:column>
                        <f:facet name="header">
                            <h:outputLabel value="#{column.name}"/>
                        </f:facet>
                        <h:outputText value="#{animal.name}"/>
                    </h:column>
                    <h:column>
                        <f:facet name="header">
                            <h:outputLabel value="#{column.age}"/>
                        </f:facet>
                        <h:outputText value="#{animal.age}"/>
                    </h:column>
                    <h:column>
                        <f:facet name="header">
                            <h:outputLabel value="#{column.edit}"/>
                        </f:facet>
                        <h:commandLink action="#{animalBean.select}" immediate="true">
                            <h:outputText value="#{standard.edit}"/>
                        </h:commandLink>
                    </h:column>
                </h:dataTable>
            </h:form>
        </body>
    </f:view>
</html>

The resulting page, ideally, would render a standard animal picture of a dog with a list of dogs for dogs.jsp. It would display a picture of a cat with a list of cats for cats.jsp. The great part of this idea is that you also use these virtual pages in your navigation mapping for the cases in which you have different destinations for actions fired in dogs.jsp or cats.jsp. Keep in mind, also, that this may not have anything to do with polymorphism. It can be used with anything that your heart desires. For example, I can use this page again to show all dogs up for adoption, all cats adopted, all dogs and or cats that need medical attention, etc. The key to this idea is page reuse. If this can be included in the next JSF spec, I would be thrilled. ;)

2 comments for Dear JSF Spec Leads: I want this as a gift for the Holidays,

Written by: Dan HinojosaFri, 9 Sep 2005 10:39 AM PDT .
Filed Under: OnceManagedBeanDebugCompileJSFEdit

There is a known issue in Java Server Faces Reference Implementation. The issue is called "edit-compile-debug". The description of this issue is as follows:

If you're using component bindings pointing to beans stored in session scope with values initialized from the JSP page, you may run into some difficulties in the "edit-compile-debug" cycle. Consider this JSP fragment: <h:commandButton binding="#{backingBean.button1}" value="press me" /> Let's say that "backingBean" is stored in session scope. The first time the browser views this page, backingBean gets instantiated, and initialized with the value "press me". Now, let's say the web-app is being authored in place, on the web container. In other words, any changes made to the JSP are seen "live" on the server. If you change the JSP to alter the value of the button to be different, say like this: <h:commandButton binding="#{backingBean.button1}" value="click me" /> and save the page, then re-load the page in the browser, you'll see that the button still shows up with the old label, "press me". This is because the spec is designed to only initialize the backing bean with a value the first time the page is loaded, and the bean is still sitting in the session with the old value. There are several workarounds to this problem.

1. use "request" or "none" scope for your backing bean
2. use java code to push the value into the bean, rather than JSP
3. ask the user to re-start their browser after modifying the JSP page.
4. a way to invalidate the session when the JSP page has changed.

Now, after just having read that, you can see that this "known issue" is big and can have implications. I encountered this issue, not with bindings, but with backingBeans that are in the session scope and whose properties are set by a two-tier reference. Here is an example:

     <managed-bean>
        <managed-bean-name>petContext</managed-bean-name>
        <managed-bean-class>
            com.evolutionnext.jsf.management.PetContext
        </managed-bean-class>
        <managed-bean-scope>
            session
        </managed-bean-scope>
        <managed-property>
            <property-name>owner</property-name>
            <value>#{ownerContext.owner}</value> <!-- This is the two tier reference -->
        </managed-property>
        <managed-property>
            <property-name>exceptionContext</property-name>
            <value>#{exceptionContext}</value>
        </managed-property>
     </managed-bean>

OwnerContext is a backingBean that houses an owner and is in a session scope. The owner can be accessed by using getOwner() and setOwner(). The OwnerContext has methods create() and update() that manage the persistence of the Owner. I have an exceptionContext there for error reporting, but that isn't the issue. PetContext holds a pet object and is also in the session scope. The pet can be accessed using getPet() and setPet(). This Pet Context has a create() and update() method. Instead of persisting it, I get the owner reference, which is the PetContext bean, and add it to the Owner. Notice that in element '<value>#{ownerContext.owner}</value>' above, I have what I call a two tier reference. I call it that because I don't know what else to call it - I am unfamiliar with the correct term. I know I am taking a gamble by doing this because ownerContext could be null, so I have to make sure that there is a managed bean in the faces-config.xml that would supply my PetContext correctly.

Now, when you use a multi-tiered reference like in this example, it will only get set once by the Java Server Faces implementation from Sun Microsystems. You will find that, after a while, this stickiness of having a property of a backingBean set only once can have unwanted effects. This problem happened to me when I was choosing multiple owners from a dataTable and setting setOwner() of OwnerContext multiple times. The result of this was that a pet kept getting applied to the wrong owner. Yikes!

So I used the recommended workaround for the problem and changed the managed bean scope to request (see example below). That resolved that issue. Another recommendation would be to avoid the two-tier reference in your managed beans.

     <managed-bean>
        <managed-bean-name>petContext</managed-bean-name>
        <managed-bean-class>
            com.evolutionnext.jsf.management.PetContext
        </managed-bean-class>
        <managed-bean-scope>
            request <!-- Changed this to request -->
        </managed-bean-scope>
        <managed-property>
            <property-name>owner</property-name>
            <value>#{ownerContext.owner}</value>
        </managed-property>
        <managed-property>
            <property-name>exceptionContext</property-name>
            <value>#{exceptionContext}</value>
        </managed-property>
     </managed-bean>

This took me quite a while to figure out, and is one of those things that, after suffering for a few hours, you decide to look in the “known issues” page of the product that you are using. Let me know if you have ever encountered this problem, or if you have another possible solution.

1 comment for That's quite a big "known issue" for JSF