extra field!!!

I was doing a custom component in JSF, and I kept getting an extra input field with the clientId as the id attribute, and I did not know why. I searched the web and did not find anybody who had ever encountered this. Since it always came last in the component I could not even figure out a way to hide the thing because any JavaScript I put in the component came prior to the existance of the field. I do not do anything in my encodeBegin() that asks for this.

Then I started wondering if extending the UIInput component required something that I was not doing; either that I figured or it was putting this darn extra field.

After studying other custom components' code, it finally occurred to me that if you extend a custom component (like UIInput) you have to be mindful of what methods that component implements, and what it does in those implemented methods. Then you have to decide if you still want that particular part of the component you are extending.

In my case, UIInput used encodeEnd() method to actually produce its field, so I just overrode encodeEnd() and made it do nothing. Then I started to wonder why I even was extending UIInput instead of UIComponent or something...

I guess that is another lesson...

postback

I was doing some research on JSF custom components. I saw that one way to do AJAX in your custom components is to program the code needed to get your data right in your decode() in your component or in your renderer.

The problem I was having was that when I told the AJAX code to do the POST it was not acting in JSF request lifecycle like a postback had occurred. It was only running the first and last phases of this lifecycle...like it does when you first visit a page.

The solution? Apparently JSF determines if this page was a postback by looking at all the input fields (or textarea, etc), and seeing if they have a name attribute. If they do then they need to have an entry in the post "search area" that you send as a string to the AJAX "send" command. So that includes state saving field, and any other fields that are displayed or hidden that have a name...I think.

Anyway doing this got my decode() method to be called, and the JSF lifecycle to call all the phases.

Making Eclipse (Ganymede) Create Your Custom JSF jar file

Apparently I am an IDE man. I know it is possible to remember the flags to run the jar command so that you can package up a set of directories, but I would rather let the IDE do the work.

But I am having a bit of difficulty making Eclipse do what I want.
I decided to package up one of my custom components into a jar file, so that someone (like me) could use the component by dropping the jar into their application’s WEB-INF/lib directory.

So I moved everything my components needed to a different project, and made the project path have every library it needed to build the java files. This worked fine.

When you want to create a jar file for your custom JSF component, your jar is pretty simple. The root directory of the jar contains package trees with class files on the leaves of these trees, and resource files like message bundles or anything else you would put in the src directory to have it on the class path.

In Eclipse-ese, creating a Jar is called “export…” So if you export to a Jar by right-clicking your project, selecting Export… from the context menu, and following the instruction in the Jar export wizard when all is said and done your classes will be in the right place if you select the src directory and the build directory that eclipse manages for you. But the META-INF directory that eclipse builds for you as a sibling to the WEB-INF file cannot stay where it is if your Jar is going to have the META-INF file in the right place. The right place for the META-INF file in your jar is in the root directory of the Jar. In the jar should be your faces-config.xml and your whatever.tld file where you describe your tags.

So my solution (which worked) was to move the META-INF from being a child of the Web Content directory, to being a sibling of the Web Content directory. Then you can simply check the box next to the META-INF directory, and it is moved to the right place.

Thoughts on JSF 1.2

Here are some miscellaneous thoughts on JSF 1.2.

The differences between JSF 1.2 and JSF 1.1 are not huge. Essentially the main differences are that you need to use objects called ValueExpressions instead of ValueBindings. Similarly you need to use MethodExpressions instead of MethodBindings. Also you will be using JSP 2.1 instead of 2.0. Also you need to use W3C XML Schema designations for your config files instead of DTD’s. Also I think you need to use a container that can handle Java EE stuff instead of J2EE stuff…but I am not sure about that. Also some classes have been deprecated in 1.2 that were in use in 1.1; for example, in the Tag Handler classes you would define for a custom component, you will not be inheriting from the UIComponentELTag instead of UIComponentTag.

You might take a look at (Vogel, L. (n.d.). JavaServer Faces 1.2 development with Eclipse WTP JSF Tooling - Tutorial. Retrieved from http://www.vogella.de/articles/JavaServerFaces/article.html) which shows how to get a project off the ground using JSF 1.2. I used Tomcat for my experiments. I would have liked to have also gotten it working with JDeveloper 11g since it uses a Java EE container. However I could not see an Enterprise Manager for the standalone 11g OC4J, and I did not want to learn how to use admin.jar, since that is how I supposed I would have to deploy to OC4J without EM working. Maybe now that 11g OC4J has gone into production now (I was still using a technical preview install) the EM will be in place…or maybe they are calling EM something else now…
Also Eclipse does not know how to talk to OC4J 11g yet. However it does know how to talk to Tomcat 6.0, which is compliant with JSF 1.2 and JSP 2.1 and Java EE and all that stuff. So I finally got Eclipse talking to Tomcat with all the right libraries. I put all the libraries needed in the build path and in the WEB-INF\lib path as well.

I also used Apache MyFaces JSF implementation. I think Apache Mojarra would have worked just as well, but again Eclipse may not know how to talk to GlassFish. I do not think it does. However if you want to use Apache Mojarra against other Java EE containers you are supposed to be able to do that. However, it appears to me that in order to actually deploy to any web server there is always a set libraries you need to include in order to be able to do this. It is not clear to me quite yet how to lay my hands always on this set of libraries, although I am thinking: probably the website of the app server in question…in the chapter on JSF perhaps?? Eclipse, if it knows how to deal with a server or a version of that server, will line up these magical libraries for the server if you specify what server you are using for a particular project. So if you are creating a new “Dynamic Web Project” of the JSF type, you can specify what server you want to deploy to (assuming you have set up Eclipse’s connection to your installation of whatever server you want to deploy to), and then those server-specific libraries will be lined up for you.

It looks like JSF 2.0 is in the works (ai yi yi!), so y’all better get it (and keep it) in gear!! J

Good site

Got questions about JSF or JSP or how they fit together?

The following tutorial may just answer some questions for you!

http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html

Hah! I found it.

I am working my way through Schalk and Burns's JSF: The Complete Reference.

I skipped ahead to Chapter 10 because I promised my groupies (hah!) that I would put some juicy nuggets about custom JSF component definition in my paper for RMOUG (Rocky Mountain Oracle Users Group) in a month and a half.

So I had to study more about custom component definition.

As I worked through the chapters on that subject in this book, I got to one of the examples, and it just did not work. As I debugged the code, I saw that the component's property called listener (a MethodBinding) was being set in the component's Tag Handler class, in its setProperties() method.

Then, the component (on a different request) tried to do something with this listener value that was set...but lo! The value of this property was null.

That let me to ask a question that I have asked before, but had grown fuzzy on the answer. The question was...what scope are components at? Request? Session? Does scope even apply to this, since they are not managed beans?

The partial answer is that components by default span requests. But if you start adding extra properties to the component then you had better override a couple of properties, if your component or one of its ancestors implemented the StateHolder interface at some point. If you are extending UIInput for example, this already has implemented this.

So what are these properties you need to override? saveState() and restoreState(). In the following example, the "extra" property we are adding is called listener and is a MethodBinding object:
@Override
public void restoreState(FacesContext context, Object state) {
Object values[] = (Object[]) state;
super.restoreState(context, values[0]);
listener = (MethodBinding) values[1];
}


@Override
public Object saveState(FacesContext context) {
Object values[] = new Object[2];
values[0] = super.saveState(context);
values[1] = listener;
return (values);
}

After adding these methods, the books example worked fine.

The name of the example component was HtmlHelloInputMB if anybody else is working through that same book.

I have informed the primary author through the email given on the books website, which has all the sample code for the book by the way: http://www.jsfcompref.com/

iReport logging

I have been using the iReport IDE for Jasper Reports template creation. One strange thing about this report of iReport: I do not see a way to see a compilation or a runtime error/message log. If an error occurs, by default the report simply does not run.

A friend of mine finally figured out a way to get some messaging out by using log4j: here was the note he sent to me:

I found a way to get iReport to log. If you start iReport from the .bat file supplied in the bin directory, you can add log4j configuration to JVM command; i.e., in the bin/startup.bat file, add the following to the java command: -Dlog4j.configuration=file:C:\bea\domains\oppenDomain\config-oppen\log4j.xml

(make sure you’re pointing to a valid xml file!

Thanks,

Ayman

p.s. the full command should look something like:

java -cp "%IREPORT_CLASSPATH%" -Dlog4j.configuration=file:C:\bea\domains\oppenDomain\config-oppen\log4j.xml -Direport.home="%IREPORT_HOME%" -Djava.security.policy="%IREPORT_HOME%/policy.all" -Xms128m -Xmx512m it.businesslogic.ireport.gui.MainFrame %*

Polymorphism work

I have recently started to study polymorphism more. My goal is to continue to improve my ability to think in Java. For example, with polymorphism if you have a cascading series of if statements which is meant to branch out like a case/switch statement and call the different methods that basically do the same type of things, you probably should refactor it to take advantage of polymorphism. I read the following article and it helped me create a solution to such a refactoring problem which was fresh and useful: http://www.javaworld.com/javaworld/javatips/jw-javatip30.html

I hope you find this example useful also. The syntax of this person's examples is not perfect, but the concepts are there, and there are enough parts of the example to put together some refactoring of your own as I described above.

iBATIS

I mostly wanted to check in because I am job hunting now and I want to keep things flowing.

I have been starting to work on the RMOUG site redeaux ;-) (with members-only site).

As I am looking for jobs I keep getting hit with jobs which want JSON, DWR, Prototype, and Dojo. I better get on the ball with these great tools.

At any rate, I worked with iBATIS caching. It is working very well. iBATIS seems so stable...I am sure there are bad things about it, but I cannot think of too many. :-)

Have a great one.

component trees (views)

I was reading about the differences between binding a UI JSP component to a UIComponent property in your backing bean using the binding property on the JSP component, and value-binding your JSP component to a model-level bean property in some class somewhere.

Well I figured out a couple of things:
1. One difference: if you believe in MVC you should keep your view-level stuff sepparate from your model level stuff. So using binding is better than value binding if you have the option.
2. The binding connection gets the values into the backing bean properties in phase two of the JSF lifecycle, where as it is the model update phase (phase 4 or 5) before you get it updated if you have a value binding connection. At least I think so...
3. From what I read it sounds like if the JSF container is in the process of rendering a UIComponent, that is no guarentee that any other UIComponent in that page's view has been put in the view (component tree) or rendered! This is for JSF 1.1. In JSF 1.2 it sounds like they have made it so that if rendering is occurring you can guarentee that all the view has been built already! I wonder if in JSF 1.1 a render of a particular UIComponent alway implies that the component has been inserted into the tree. It seems as if you would have to construct a tree in a way that would allow later traversal. And not just random nodes...although I do remember algorithms for BTree insertion that allowed you to insert random nodes and have them end up in a reasonable order...so who knows.