Good morning. It’s time for my JavaOne 2008 Day 1 report (though it’s actually the morning of the 2nd day :). Thanks to the graciousness of Sun Microsystems, I’m here on the Java Blogger program, giving me really amazing access and privileges. All I have to do is blog about my experience, which I would have done anyway, so over the next few days, I’ll be filing “reports” on what I’ve seen and heard. So, with that introduction out of the way, let’s recap day 1. (more…)

Popularity: 42% [?]

Next week, I’ll be off to JavaOne. With everything that’s going on, I thought it would be nice to have my JavaOne schedule on my Google Calendar, which I could then sync with my phone. Sadly, it wasn’t as easy as I thought it would be (though I certainly could be the failure in the process :). After I imported my schedule into Outlook (used only — and grudgingly — as iTunes is broken in that it only supports Outlook) and then synced that with my Google Calendar, all of the event start times were adjusted for the time zone differences. Importing by CSV resulted in cryptic messages about my calendar not being available, so I did what any good geek would do: I wrote my own solution, creatively named J1Sync. (more…)

Popularity: 39% [?]

Today, Ryan Lubke committed code to the Mojarra tree that will allow a JSF developer to prototype and/or develop just about every JSF artifact using Groovy. When deployed to the server in development mode, the Groovy file can be changed on disk, and the changes will be picked up automatically, allowing one to avoid the compile/package/deploy cycle that can make Java web development so tedious. Once the artifact is “done,” the Groovy source can be copied to a Java source file and compiled (or the build process can compile the .groovy files to .class files) for production deployment. This could be a really nice feature for component development, for example.

For more details, including a sample NetBeans project, visit Ryan’s entry.

All around, a very, very cool enhancement. Great work, Ryan!

Technorati Tags: javaserver faces, jsf, mojarra, groovy

Popularity: 54% [?]

In a blog entry last year, Ken Paulsen gave a short introduction to the FileStreamer utility in JSFTemplating. Since Scales is now using JSFTemplating to make the component authoring process easier, I have been able to use this facility, allowing me to deprecate some custom code. In the process of making the migration, I’ve made changes to JSFTemplating that will be of benefit to all. In this entry, I’d like to highlight those changes, and show you how you, too, can use this great facility. (more…)

Popularity: 68% [?]

In a recent blog post, Java EE 6 (JSR 316) specification co-lead Roberto Chinnici discussed the two leading proposals for the web profile in the upcoming Java EE 6 specification (For more information about profiles, one can start with this article on TheServerSide.) The part that caught me by surprise and confuses me greatly is why the inclusion of JavaServer Faces in the web profile would be controversial. Having spoken with an expert group member, who I will not out :), the argument comes down to this: “We shouldn’t force a broken technology, that is not the clear winner on people.” I think that’s a very interesting statement, in that it precludes doing just about anything in the spec. (more…)

Popularity: 69% [?]

At the lunch session of the OKC JUG today, a question was asked about the difference between the valueChangeListener attribute and <f:valueChangeListener/>. That is,

<h:selectOneMenu id="optionMenu" value="#{optionBean.selectedOption}" valueChangeListener="#{optionBean.optionChanged}" onchange="submit()"> <f:selectItems value="#{optionBean.optionList}" /> </h:selectOneMenu>

and

<h:selectOneMenu id="optionMenu" value="#{optionBean.selectedOption}" onchange="submit()"> <f:selectItems value="#{optionBean.optionList}" /> <f:valueChangeListener type="com.mycompany.MyValueChangeListenerImpl" /> </h:selectOneMenu>

The question was, which is “better?” There was also a question if the latter form automatically handled the JS on the parent component. I will now attempt to answer those questions now.
(more…)

Popularity: 82% [?]

One of my long-standing complaints with Ant is that project dependency management is non-existent in the core Ant distribution. Many will quickly point to the Maven Ant tasks, but I’ve never been really fond of them for one reason or another. The other advice I often get is to use Ivy, but even after several attempts, I had never gotten Ivy to work. With the recent release of 2.0 beta 1, though, I thought I’d try again, and I’m glad I did. Not only have I gotten it to work for me, but I was also able to successfully configure custom resolvers. Below is what I had to do to migrate the Mojarra Scales dependency management to Ivy. (more…)

Popularity: 100% [?]

In my last post, I alluded to some refactoring done inside the Sandbox/Scales library to simplify the components’ code. If you are interested in learning more about what was done, and how you can apply the same techniques to your own JSF components, please see this article, written by Ken Paulsen and myself, with editing help from Rick Palkovic, which shows how one can use JSFTemplating and some (currently “private”) annotations from the Woodstock project to greatly simplify JSF component authoring. I think it’s a very interesting and helpful technique, which, by the way, resembles what JSF 2 will likely offer when we finally ship it later this year.

Oh, yeah. Happy New Year’s!

Popularity: 69% [?]

Some of you may be wondering what the status is on the RI Sandbox. With the announcement of Project Mojarra, we can finally take the wraps off of Mojarra Scales, the promotion of the RI/Mojarra Sandbox to its own project. (more…)

Popularity: 74% [?]

It is with a pretty high degree of excitement that we, the JSF RI Mojarra development team, announce Project Mojarra. While the project itself is not new (it’s the same, high quality and stable JSF implementation we’re all familiar with ;), the announcement of the new moniker brings to an end a lengthy, and sometimes frustrating, process of deciding on a name that can pass legal muster. For more details on the name change, see this entry by Ryan Lubke.

Popularity: 63% [?]