When working with JSF 1.x you will eventually find out about some of its annoying features. Such as that it is all about HTTP POST and nothing but HTTP POST. So when working with forms with inputTextArea components you will notice that refreshing or navigating away and then back will leave them blank again. Some of customers I worked for had a problem understand this limitation, because dropdown boxes just worked fine and demanded that the text areas work the same.

I found a small piece of code that will remedy this shortcoming.   

It's something that it very hard to find once some of your RichFaces pages are suddenly acting very weird, like sortable columns only sorting once and then ignoring all other requests. It turns out that the following configuration changes the way events and life cycle are handled, breaking AJAX.

<context-param> 

<param-name>facelets.BUILD_BEFORE_RESTORE</param-name> 

... Java is dead! But that's a good thing if you believe the writer of the following article:

http://muckandbrass.com/web/display/~cemerick/2009/10/01/Java+is+dead,+but+you'll+learn+to+love+it

In short he elaborates  on the fact that Java has now become a settled language like C and that any major changes would break more things than that it would change for the better. The world of tomorrow is for languages such as Scala and Groovy. To discuss the subject here, I would like to refer you all to the group discussion.

A classic from lifehacker, that introduces you to 10 applications on the web that can make your life much easier, even for free. A must read, found at:  

http://lifehacker.com/5361979/top-10-underhyped-webapps-2009-edition

I  really like the TinyChat and the Aviary Suite.

In my daily job I use Hibernate as my favourite ORM-framework. It's very convenient not having to think about all those low-level database stuff, but sometimes you can encounter some problems with the non- or badly documented features that can cause a lot of agitation and loss of time.

A few of these quirks are already documented at this link, but I would like to also add a few of my tips below.

As of the 1st of juli the specification of JSR-314, also known as JSF 2.0, has become final. This means it's high time to look at all the changes, hopefully all improvements, that this new version brings us.

Throughout the years of the existence of JSF it has been flooded with critique. Combine that with the rise of new alternatives like RIA (e.g. Adobe Flex) and you understand that SUN must come up with something very good to make any meaningful impact. Fortunately the JSF team, led by Ed Burns and Roger Kitain, listened to all the critics and at the same time tried to unify the wild growth of implementations. A leading rule is; less configuration, more convention.

A number of features to look out for:

De annotaties zijn al een tijdje ingeburgerd in Java en iedereen die ooit met Java 1.5 of hoger heeft gewerkt, zal het vertrouwde @-tje herkennen, maar hoe vaak heb je er nu een zelf gemaakt? Waarschijnlijk nooit, want dat is toch het domein van de Springs, Hibernates en andere frameworks in deze wereld. Hoe gaat het überhaupt in zijn werk? Het is namelijk geen onderdeel van een of ander certificaat.
Op internet zijn wel wat dingen te vinden over hoe annotaties te maken, maar daarbij valt me op dat er nooit wordt ingegaan op zogenaamde runtime annotaties, annotaties die je ook tijdens het runnen van jouw programma kunt gebruiken.

Annotaties zijn in feite niet meer dan interfaces:

public @interface Ranked {
      String column() default "";
}

Er vallen wel een aantal dingen op; voor het keyword interface staat een @-tje en de property declaratie ziet er heel verschillend uit. Ook ben je wat beperkt in je typekeuze voor een property. Alleen primitieve types, String, Class, annotaties en enums mogen of een 1-dimensionale array hiervan. Geen objecten dus. In de praktijk is dit echter niet echt een belemmering.
Het keyword default geeft, geheel verwacht, een standaard waarde aan de property. Als je dit keyword weglaat, is deze property verplicht om in te vullen.
De overige configuratie kun je op de interface annoteren en zal ik even de vier nuttigste opties doornemen:

@Retention:
Dit geeft aan wanneer een annotatie beschikbaar is op de class. Dit kan zijn alleen tijdens build-time, tijdens compile-time of tijdens runtime. Zie de enum RetentionPolicy.

@Target
Dit geeft aan waar de annotatie geldig is, bv. op types, fields of methods. Zie de enum ElementType.

@Documented
Dit geeft aan of de annotatie ook wordt meegenomen met de Javadoc.

@Inherited
Dit geeft aan of de annotatie ook wordt doorgegeven via inheritance.

Onze annotatie zie er na configuratie er als volgt uit:

@Retention(value=RetentionPolicy.RUNTIME)
@Target(value={ElementType.TYPE})
@Documented
public @interface Ranked {

}

Dus kunnen we deze annotatie tijdens runtime nog steeds gebruiken en mag deze alleen op classes worden gebruikt. De @Documented spreekt vanzelf.
Nu is de annotatie klaar voor gebruik op de bekend manier:

/*
* Deze class is geranked.
*/
@Ranked
public class Product {

}
 
Nu moeten we ook nog wat met deze property gaan doen, want ook al lijkt Spring soms magisch, het werkt niet vanzelf. Onze magie zit bijvoorbeeld in de DAO, waar we entiteiten met @Ranked automatisch sorteren. (Ja, ik weet dat dit ook kan met @Sort kan)

if (persistentClass.isAnnotationPresent(Ranked.class)) {
            return findByCriteriaOrdered(Order.desc(RANK));
}

Waar het hier om gaat is de method isAnnotationPresent van de class Class. Deze kijkt of een annotatie tijdens runtime (vandaar de RetentionPolicy) in de class aanwezig is. Als dat zo is, kun je daarmee iets doen, zoals hier gebeurd.

Het uploaden van bestanden is vaak een niet-triviale taak. Eerst moet je het bestand worden gevalideerd op type en grootte, naar een tijdelijke bestemming worden gestreamed en daarna gekopieerd, wat nu al simpeler klinkt dan het is als je het zelf moet doen.
Met RichFaces wordt het echter een stuk simpeler, een oplossing die ik jullie niet wilde onthouden.

De component:

Met de <rich:fileUpload> tag plaats je de component. In mijn geval ziet het er als volgt uit:

<rich:fileUpload maxFilesQuantity="1"
            immediateUpload="true"  onsizerejected="alert('Uw bestand mag niet groter dan 1000KB zijn');"
            ontyperejected="alert('Alleen *.jpg, *.gif, *.png en *.bmp bestanden zijn toegestaan als plaatje');"
            acceptedTypes="jpg, gif, png, bmp"
            fileUploadListener="#{bean.upload}">
</rich:fileUpload>

Dit creëert een upload-component dat één plaatje accepteert en het meteen upload na het selecteren. Als het groter is dan 1000KB (te configureren als maxRequestSize init-param bij het rich-faces filter in web.xml) of als niet voldoet aan de bestandtype-eis, dan geeft dit component netjes een melding. De listener verwijst naar een specifiek event in de achterliggende bean.

public void upload(UploadEvent event) throws IOException {
        UploadItem item = event.getUploadItem();
        String filePath = //path waar het bestand naar toe moet

        File file = new File(filePath);
        file.createNewFile();
        FileOutputStream fos = new FileOutputStream(file);
        // In de web.xml is ook weer configureren of er  tijdelijke bestanden worden
        // gemaakt of dat alleen het geheugen wordt gebruikt. Standaard wordt er
        // gebruik gemaakt van tijdelijke bestanden.
        //<init-param>
        //   <param-name>createTempFiles</param-name>
        //   <param-value>true</param-value>
        //</init-param>   
        if (item.isTempFile()) {
            FileInputStream fis = new FileInputStream(item.getFile());
            IOUtils.write(IOUtils.toByteArray(fis), fos);
            fis.close();
        } else {
            IOUtils.write(item.getData(), fos);
        }
        fos.close();
}

Merk op dat ik bij deze code ook de IOUtils uit Apache Commons gebruik om de bestandsafhandeling aanzienlijk te vereenvoudigen.
Hiermee is het bestand geupload, inclusief nette afhandeling van eventuele fouten. Bedankt RichFaces!