Monday Oct 19, 2009
Mojarra 2.0.0 is now available!
There are several ways to obtain the release.
Please review the release notes as there are important details there pertaining to differences between the implementation and the specification as well as a basic migration guide from 1.2 to 2.0 (note that this is a live document, so we'll be making additions - check back regularly).
The JSF 2.0 tutorial from our Sun documentation team should be available in the coming weeks. As soon as it is, we'll send out a notification. Until then, here are some nice resources for JSF 2.0:
On the tools+JSF 2.0 front, NetBeans is well underway with the JSF 2.0 support. I'd recommend grabbing the NetBeans development build and try it out! Ed noted the other day that you could highlight a section of markup in a Facelet template and extract it into a composite component. Slick! The JetBrains guys have been busy as well. Check out their
blog on JSF 2.0 support within Maia.
I'd like to personally thank all of our external contributors who have been committing code to the repository directly or submitting patches to help improve our quality (these are in no particular order - my apologies if I've missed anyone):
- Guy Veraghtert
- Imre Oßwald
- Ted Goddard
- Mark Collette
- Dan Allen
- Alexandr Smirnov
- Martin Marinschek
- Michael Kurz
- Andy Schwartz
I'd also like to thank our top three issue reporters for taking the time to log issues (again, in no particular order)
- Frank Hofmann
- Guy Veraghtert
- Juergen Zimmerman
Also, thanks to Ed Burns, Roger Kitain, Jim Driscoll, and Doug Donahue for putting up with me for the past two years while we worked on this project :)
Finally, if you'd like to discuss JSF 2.0 with other users, I'd recommend the following:
The GlassFish Webtier forums are monitored by the Mojarra developers. The IRC channel, also, is frequented by the Mojarra developers, as well as folks from Exadel, MyFaces, and consumers of JSF as a technology. It's a great way to interact with the community.
I'm excited that we've reached this stage and am looking forward to hearing/reading about people's experiences with JSF 2.0!
Tuesday Jan 20, 2009
As those of you using the Woodstock component set know, all new development on Woodstock has been stopped.
In an effort to help developers easily transition from Woodstock, the following announcement was made:
We are happy to announce a relationship between the NetBeans and ICEfaces
communities to facilitate migration for current Woodstock users. With the
latest ICEface NetBeans plugin (v1.7.2SP1), you can add the ICEfaces
framework to an existing project and begin to develop ICEface pages along
side existing Woodstock pages. Resources have been created to aid migration,
including a detailed Migration Guide and a Component Comparision Matrix
between Woodstock and ICEfaces components. This is just the beginning of a
relationship between the NetBeans and ICEfaces communities. Additional
migration utilities are planned for upcoming ICEfaces releases.
Resources: *Learn more at the Woodstock to ICEfaces Migration page
http://www.icefaces.org/main/product/woodstock-migration.iface
*Download the ICEfaces plugin from ICEfaces.org
http://www.icefaces.org/main/downloads/os-downloads.iface?category=NetBeans
or from the NetBeans Update Center by choosing Tools > Plugins from
within the NetBeans IDE.
*Read the Woodstock to ICEfaces Porting Guide
http://www.netbeans.org/kb/docs/web/icefaces-migration-1.html
*Join theWoodstock to ICEfaces Migration Forum
http://www.icefaces.org/JForum/forums/list.page
Friday Dec 19, 2008
Just a quick heads up that the Project Mojarra team has pushed two releases to the project site today.
1.2_11 is a minor bug fix release. 2.0.0 PR is our release that is feature complete with respect to the JavaServer Faces 2.0 PR specification.
Both releases should be available on the update center for GlassFish V3 Prelude by the end of the day. For those running JSF on GlassFish V2, please review the release notes for upgrade instructions.
As usual, if you have feed back on potential implementation features or think you've found a bug, please log an issue on our tracker.
Feedback for the 2.0 PR specification should be mailed to jsr-314-comments@jcp.org.
UPDATE (12/22/2008) We're working out a small snag with the two
releases on the UpdateCenter. For now, I'd recommend the manual
upgrade steps detailed in the release notes. As soon as the UC issues
are resolved, I'll post another update to this entry.
UPDATE (12/24/2008) We've ironed out the UC repository issues, so 1.2_11 and 2.0.0 PR are now available on the GlassFish V3 Prelude UpdateCenter (just in time for Christmas too!).
Thursday Apr 17, 2008
Starting with tonight's nightly build of Mojarra 1.2_09,
developers can opt to use Groovy to enable rapid prototyping for their
JSF applications.
Why Groovy?
Several reasons.
First and foremost was the learning curve that java developers
would face when using Groovy. Since Groovy scripts can be written in
either standard java syntax or using Groovy's syntax, it's one less thing for
developers to learn when trying to write their applications. Just use
standard Java syntax in the .groovy file and get on with your work.
This also means that once you're done prototyping in Groovy, you can copy
the source to a .java file and include it in your standard build process so
that your code can run on any JSF implementation. Another is
annotation support. Groovy-based managed beans can use resource injection per the JSF 1.2 specification. Finally, from an
integrator's standpoint, I could call the Groovy runtime and
get a regular Class made this integration easy to do (i.e. not a lot of
changes were needed to the core).
How to enable Groovy
support
Enabling Groovy support is fairly straight forward.
Just follow these steps:
- Download Groovy 1.5.5 and include the groovy-all-1.5.5.jar with your web
application (or copy it to your application server's lib directory)
- Add the following to your web.xml
<!-- Enable Groovy Support --> <context-param> <param-name>com.sun.faces.developmentMode</param-name> <param-value>true</param-value> </context-param> . . . <filter> <filter-name>GroovyFilter</filter-name> <filter-class>com.sun.faces.scripting.GroovySupportFilter</filter-class> </filter> <filter-mapping> <filter-name>GroovyFilter</filter-name> <url-pattern>/*</url-pattern> <dispatcher>REQUEST</dispatcher> <dispatcher>FORWARD</dispatcher> <dispatcher>INCLUDE</dispatcher> <dispatcher>ERROR</dispatcher> </filter-mapping>
|
The init parameter com.sun.faces.developmentMode serves two
purposes.
- When enabled, any changes to any faces-config.xml under
WEB-INF
will cause the faces application to be re-loaded
without having to
redeploy. This is handy as you add
new managed beans or other
artifacts to your
application.
- For certain JSF artifacts, specifically those that can be
considered
stateless application singletons (think Renderer
or PhaseListener),
Mojarra will wrap groovy based versions
of these classes with a proxy
so that changes to a Render or
PhaseListener are picked up at runtime
without a reploy
step.
One might wonder what the filter is for. This filter simply
ensures the
the context classloader is properly setup.
Unfortunately it is needed to
an issue in GlassFish and Tomcat
where the context classloader is reset
on a forward, somthing
that is a common task in web applications.
Create a directory under WEB-INF called groovy.
These are where your
groovy scripts will be placed. You can
use the the typical package scheme
as you would with typical java
source files. When referencing Groovy scripts
within the
faces-config.xml, make sure you include the .groovy extension.
Exmaples:
<managed-bean-class>sample.SimpleBean.groovy</managed-bean-class>
UPDATED APR 29, 2008 : Including the .groovy extension is no longer necessary
What artifacts can be scripted with Groovy
The
support we've added allows you to use Groovy for all JSF artifacts.
Artifact
|
Dynamic Reloaded
|
Managed Beans
|
Yes (*)
|
Renderer
|
Yes
|
PhaseListener
|
Yes
|
ActionListener (application level)
|
Yes
|
Renderer
|
Yes
|
ELResolver
|
Yes
|
Component
|
Yes
|
Converter
|
Yes
|
Validator
|
Yes
|
ApplicationFactory
|
Yes(**)
|
FacesContextFactory
|
Yes(**)
|
LifecycleFactory
|
Yes(**)
|
* If a reload of the faces-config.xml was not triggered, session scoped or
application scoped beans won't show changes until they have been removed
from scope. That said, if a faces-config reload occurs, all known sessions
will be invalidated and all application scoped beans will be removed.
** While these artifacts can be scripted they tend to hold state so you'll need
to trigger a faces-config reload (a simple touch of the faces-config.xml will do)
to view changes. Still no recompile or redeploy necessary.
When using this feature, I highly recommend the use of Facelets for two major reasons. The
first being there are no tags or tlds that need to be maintained. This
is important since there is no dynamic reloading of JSP tag handlers or TLDs
at the moment. The second is that the facelets taglib files will be
reloaded when a faces-config reload occurs, so again no redeployment!
For those who use NetBeans, this feature really shines. Within NetBeans one is able to run/deploy the project and then make changes to your
groovy, faces-config.xml, facelets taglib and xhtml files, save then and
reload within the browser and see the changes (again - no redeploy)!
I found this particularly handy when writing groovy-based renderers and
components. Feel free to download this sample
Facelets-based NetBeans project that is setup for groovy development
(includes a simple Groovy bean and all of the configuration so you don't
have to mess with it). Note that you still need to provide
Facelets, Groovy, and the Mojarra nightly build. I should point out
this blog which references a
Groovy plugin for NetBeans. I've been using it while testing the
functionality and while it's missing some features, it's a nice alternative
to treating Groovy scripts as plain text.
All of this having been
said, this support is still new, so I'm sure there are still some snags
hiding somewhere in the code. If you find any, please log an issue
detailing the problem you have. We'll be sure to get the bug fixed as
soon as possible. Likewise, any ideas on how to improve the
feature/end-user experience, let us know on the Mojarra user or dev
mailing lists. We'd love to hear from you.
Hi Ryan,
The earth is greener now :)
Release of JS...
Nice! and Congrats.
Congrats on the release. I look forward to u...