Tuesday Aug 23, 2011
Thursday Jan 21, 2010
Tuesday Jan 20, 2009
By user12615560 on 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
Thursday Jan 01, 2009
By user12615560 on Jan 01, 2009
I'm not one to normally post much of anything personal on the web, however, since several co-workers found my family's new situation interesting, I thought I might share.
This year my family and I are going green(er). Specificially, we've moved into a house that is off the grid meaning the house doesn't use the typical public utilities (i.e. city water, electric, etc).
For electricity, the house has a solar array hooked up to a set of batteries. The setup provides enough power for two days of typical usage with no sunlight. Even though we live in California, there are days when you don't get sun during the winter. For those cases we do have a propane generator that can provide power to the house and also acts as an alternator to charge the batteries so that the generator wouldn't have to continually run.
For water, we have two pumps. One is attached to a windmill and the other is electric. So we have two choices for drawing water into our storage tank. Not much wind as of late, so the electric has of course been in use.
Being an employee of the tech industry (and a player of MMOs), high speed access is important. We have this via a microwave dish directed at a local communications tower.
The house itself is a very nice log cabin. Now don't think that we're backwoods living. The house has all of the normal amenities: wood stove (there is forced hot air heating if needed), central air, several baths, dishwasher, etc.
So for a small change in lifestyle, we get to enjoy this new house, with a great view in the mountains. While we've only been here a few days now, we've already gotten into the groove of being more conscience about power usage and you find there's a lot of things you just take for granted. A perfect example of this is a microwave. Most microwaves have a digital clock. While it's a small draw on power, it's continuous and can drain the batteries. Because little things like that have such an impact in our new reality, we can't have them. So for a microwave, we're using one with a mechanical timer. I could rattle on about other devices that you may not think twice about (we never did), but I think you get the point.
At any rate, off or on the grid, it seems that thinking about the impact of the smallest things would be of some benefit as little stuff starts to add up over time. Something to think about.
Oh! And you haven't truly lived until you've driven a fully loaded 16-foot moving truck on muddy, windy mountain roads. If we move again, we're leaving our stuff behind!
P.S. Happy New Year!
Thursday Apr 17, 2008
By user12615560 on 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.
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 -->
The init parameter com.sun.faces.developmentMode serves two purposes.
- When enabled, any changes to any faces-config.xml under
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
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.
- When enabled, any changes to any faces-config.xml under WEB-INF
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 scriptsUPDATED APR 29, 2008 : Including the .groovy extension is no longer necessary
within the faces-config.xml, make sure you include the .groovy extension.
What artifacts can be scripted with Groovy
The support we've added allows you to use Groovy for all JSF artifacts.
|| Dynamic Reloaded
| Managed Beans
|| Yes (\*)
|ActionListener (application level)
\* 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.