Primefaces dialog stopped working after migration from 11 to 12

JSF 2.1.19 

Primefaces 12.0 

 After migrating Primefaces from 11 to 12 the dialog buttons (yes and no) stopped working, the action in the underlying commandButton was not called anymore. The problem was solved with adding the attribute type="button" to the confirmDialog

Richfaces.showModalPanel is not working with IE11 under some circumstances

IE 11
Richfaces 3.3.3.Final
JSF 1.2

Under some circumstances (in our case it is a page change, a download of a document and some other stuff), we did not figure out whats the exact problem, the javascript call Richfaces.showModalPanel() is not working anymore in IE 11. No problem with IE 10, Firefox or Chrome.

Usually you upgrade the JSF and Richfaces version to something thats maintained and forget this old stuff problems, but this was not possible for other reasons.

The solution we found is to change the code from

oncomplete="if(#{!list.errorMessages}){Richfaces.showModalPanel('myPanel');}jQuery.unblockUI();"

to

oncomplete="if(#{!list.errorMessages}){#{rich:component('myPanel')}.show()};jQuery.unblockUI();"

Now the ModalPanel is working in IE 11.

JMeter und JSF 1.2

JMeter 2.9
JSF 1.2

Bei JSF 1.2 Applikationen gibt es für JMeter ein paar Hürden, ein paar konnte ich lösen:

1. Bei JSF 1.2 Applikationen werden für die *.jsf Requests Redirects ausgeführt die im Script vorhanden sind --> die Redirects werden also 2x ausgeführt

Lösung: Redirects händisch von den Requests entfernen:

2. Schon das Logon klappt nicht im Script, es wirft einen 404.

Lösung: HTTP Authorisierungs Manager hinzufügen

3. Manche jsf Seiten werfen einen 500er obwohl eigentlich alles zu stimmen scheint, typischer Stacktrace:

javax.servlet.ServletException: viewId:/person.jsf - View /person.jsf could not be restored.
at java.lang.Throwable.<init>(Throwable.java:80)

Wenn man mit JMeter Proxy das Script aufgenommen hat ist zwar der javx.faces.ViewState als Param im Request aufgenommen, aber durch verschiedene widrige Umstände wie zB die Redirects aus dem ersten Tip müssen die stateViews nicht mehr übereinstimmen. Abhilfe schafft hier ein Regular Expression Extractor:

So holt man sich den ViewState aus den Responses:

Und so stopft man diese Variable in die eigenen Requests:

JSF datatable und commandlink

JavaServer Faces 2.0.3
Tomahawk 1.1.10

Will man in seiner h:datatable einen h:commandlink verwenden und das dahinterliegende Bean im Requestscope arbeitet, passiert es häufig, das die action des h:commandlink einfach nicht ausgeführt wird. Viele Seiten im Netz beschäftigen sich mit diesem Phänomen, aber eine hieb und stichfeste Lösung findet man eigentlich nicht. Zum Laufen gebracht habe ich es dann mit der Tomahawk Version der datatable f:datatable.
Aber auch dabei gibt es einige Fallstricke, die einem im ersten Augenblick nicht ganz einleuchten.

Hier der xhtml Teil, wie er funktioniert, die Action also ausgeführt wird:

Zu beachten ist hier, das es nur funktioniert wenn preserveDatamodel true gesetzt wird, andernfalls wird die action des h:commandlinks nicht ausgeführt. Eine genauere Erklärung was preserveDataModel genau macht, findet man hier.

Eine weitere Falle stellt das attribute rendered dar, setzt man es als Attribut der t:datatable ein, funktioniert der h:commandlink schon wieder nicht.

f:param wird gesetzt, damit man in der Actionmethode auch den richtigen Eintrag erwischt:

FacesContext.getCurrentInstance().getExternalContext()
   .getRequestParameterMap().get("imageDetailInfo")

Links:
Artikel und Diskussion über dieses Problem
Blogbeitrag: Lösung des Problems durch Schreiben eines CommandLinkRenderers
Auführlicher Artikel von BalusC über das Arbeiten mit datatables

JSF 2.0 - Ajax Einsatz

Java Server Faces 2.0.3

Der Einsatz von Ajax in JSF ist relativ simpel zu implementieren, hier ein kleines Testbeispiel, das 2 Buttons includiert, wobei einer einen Ajax Request auslöst, während der andere einen normalen Request auslöst.

Der f:ajax tag wird einfach als Kindelement unter das Control gehängt, daß den Request auslösen soll, und als Attribut render wird die id des Tags eingetragen, der als einziger neu gerendert werden soll, simpler geht es fast nicht mehr.
Dazu die Bean, die natürlich auch in der faces-config.xml registriert ist:

import java.util.Date;

public class SearchBean {
 private Date now;
 public Date getNow() {
  now =  new java.util.Date();
  return now;
 }
 public void setNow(Date now) {
  this.now = now;
 }
}

Man kann schon sehen wie beim Drücken des einen Buttons alles neu gezeichnet wird, während der andere nur das eine Control neu zeichnet.

Einen Fallstrick gibt es, der mit etwas Zeit gekostet hat: Der Ajax Request funktionierte einfach nicht, und im Log war diese seltsame Fehlermeldung zu finden:

Eine oder mehrere Ressourcen haben das Ziel 'head', aber es wurde keine Komponente 'head' in der Ansicht definiert.

Mit Hilfe dieses Blogeintrags habe ich dann das Problem ausmachen können:
Das jsf.js wurde nicht geladen, weil ich den Tag 'head' eingesetzt habe und nicht den Tag 'h:head'.


Links:
Ajax Kapitel aus dem JSF 2.0 Buch der Firma irian

Upgrade Java Server Faces von 1.2 auf 2.0 - faces-config.xml

Java Server Faces 1.2.14 zu 2.0.3
Tomahawk 1.1.10

Beim Upgrade eines JSF Projekts müssen einige Bibliotheken ausgetauscht werden und wenn es sich um ein mit Eclipse und dem JBoss Tools erzeugtes Projekt handelt sogar einige der .settings Files per Hand angepasst werden (zumindest fand ich keinen anderen Weg).

Eine besondere Falle, insbesondere da die Fehlermeldungen nicht vorhanden sind, bzw. nichts aussagen, ist die faces-config.xml. Bemerkt habe ich das Problem, als aus irgendeinem Grund meine Tomahawk Tags nicht mehr in Html umgewandelt wurden sondern z.B. als t:graphicImage nutzlos direkt mitübertragen wurden.

Die Lösung war, den ersten Teil der faces-config, der so aussah:

durch eine 2.0 kompatible zu ersetzten:

Tomahawk: inputFileUpload

Java Server Faces: 2.0.3
Tomahawk 1.1.10 für JSF 2.0

Um Files angenehm hochladen zu können habe ich mal den Tag inputFileUpload aus der Tomahawk Bibliothek ausprobiert.

Dazu das xhtml File:

Zu beachten ist, das die Form den enctype braucht, sonst funkt es nicht.

Da die Bean:

import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import org.apache.myfaces.custom.fileupload.UploadedFile;

public class FileUploadBean {
 private UploadedFile upFile;
 FileOutputStream out;
 InputStream stream;

 public FileUploadBean() {
 }

 public UploadedFile getUpFile() {
  return upFile;
 }

 public void setUpFile(UploadedFile upFile) {
  this.upFile = upFile;
 }

 public String upload() throws IOException {
  try {
   stream = upFile.getInputStream();
   long size = upFile.getSize();
   byte[] buffer = new byte[(int) size];
   stream.read(buffer, 0, (int) size);
   out = new FileOutputStream("/path/to/your/dir/testfile.jpg");
   out.write(buffer);
   System.out.println("Erfolgreicher Upload");
   return "ok";
  } catch (Exception ioe) {
   System.out.println("Upload gescheitert");
   return "no";
  } finally {
   if (stream != null) {
    stream.close();
   }
   if (out != null) {
    out.close();
   }
  }
 }
}

Tomahawk braucht noch einen Eintrag in das web.xml:

 
  Extensions Filter
  org.apache.myfaces.webapp.filter.ExtensionsFilter
  
   uploadMaxFileSize100m
  
   uploadThresholdSize100k
  
   
   Set the path where the intermediary files will be stored.
        
   uploadRepositoryPath/temp
 
 
  Extensions Filter
  Faces Servlet
 

Weiters darf man natürlich nicht vergessen das Bean in der faces-config.xml als ManagedBean zu registrieren.

Links:
Beispiel für inputFileUpload auf roseindia.net
Beispiel für inputFileUpload von balusc
Tomahawk Homepage

JSR-303 (Bean Validation) in JSF 2.0.2 und Google App Engine 1.3.1

Bean Validation ist eine wunderbare Sache, und um diese für JSF in der GAE nutzen zu können, verwende man folgende jars in seinem Buildpath:

jpa-api-2.0.Beta-20090815.jar
log4j-1.2.14.jar
slf4j-api-1.5.6.jar
slf4j-log4j12-1.5.6.jar
validation-api-1.0.0.GA.jar
hilbernate-validator-4.0.2.GA.jar

Downloadsite:
sourceforge.net (die ersten 5 jars sind im zip des 6ten enthalten).
Links:
openscope.net

JSF 2.0.2 mit Google App Engine 1.3.1 - javax.naming.InitialContext Exception

Eclipse 3.5.2
appengine sdk 1.3.1
mojarra-2.0.2

Ich habe versucht mithilfe dieser Anleitung eine "Hello world"-JSF Applikation auf der Google App Engine zum Laufen zu kriegen, aber leider wollte das Teil nicht wie ich und warf diese Exception:

java.lang.NoClassDefFoundError: javax.naming.InitialContext is a restricted class.

Scheinbar taucht diese Klasse nicht auf der Google White List auf, und nur in dieser Beschriebene dürfen in der Sandbox der Engine ihr Unwesen treiben. Ärgerlich wenn man JSF 2.0 verwenden will, sie von Google als kompatibel angepriesen wird... und dann nix funzt.
Nach etwas Recherche fand ich eine gute Seele, welche die jsf-impl.jar per Hand zu Fuß gefixed hat, damit läufts nun.

Hier der Link zum gepatchten jar:
code.google.com