JSF2: valueChangeListerer e valori null

Problema: setto a null il valore di un inputText tramite jQuery, faccio submit della pagina e scatta la validazione tramite validatore custom. Se la validazione fallisce viene riportato nel campo messo a null l’ultimo valore valido precedente.

Causa: da una discussione trovata su http://stackoverflow.com/questions/3933786/jsf-2-bean-validation-validation-failed-empty-values-are-replaced-with-las pare sia un *bug* di Mojarra:

settando la proprietà nel web.xml:

<context-param>
    <param-name>javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL</param-name>
    <param-value>true</param-value>
</context-param>

si verifica un bug in HtmlBasicRenderer#getCurrentValue() in Mojarra:

if (component instanceof UIInput) {
    Object submittedValue = ((UIInput) component).getSubmittedValue();
    if (submittedValue != null) {
        // value may not be a String...
        return submittedValue.toString();
    }
}

String currentValue = null;
Object currentObj = getValue(component);
if (currentObj != null) {
    currentValue = getFormattedValue(context, component, currentObj);
}
return currentValue;

Normalmente, il valore inviato è impostato su null quando il componente UIInput viene convertito e validato con successo. Quando JSF è in procinto di visualizzare nuovamente il valore, prima controlla se il valore inserito non sia null prima di procedere per visualizzare di nuovo il valore di modello. Tuttavia, con questo parametro di contesto, è nullo, invece di una stringa vuota quando non è valido e così sarà sempre visualizzare nuovamente il valore del modello originale quando si rimuove il valore iniziale di un campo obbligatorio.

Soluzione: la parte jQuery setta il valore *stringa vuota* invece di null (nel caso specifico la soluzione funziona perché il test sul valore è effettuato tramite il metodo di utilità org.apache.commons.lang3.StringUtils.isNotBlank sul valore dell’input).

[BIGNAMI] Design Patterns in Java – Parte 1

Il libro di riferimento è: Design Patterns in Java(TM) (Software Patterns Series) by Steven John Metsker.

Un pattern è *un modo per fare qualcosa*, una tecnica già sperimentata e consolidata per espletare un dato compito.

In modo analogo, un design pattern è un pattern che usa classi e metodi in un linguaggio object oriented per risolvere problemi noti.
Un pattern rappresenta una idea, non una particolare implementazione.

Si possono classificare i Design Patterns secondo i problemi che risolvono:
1. Interfacce (Interfaces)
2. Responsabilità (Responsibility)
3. Costruttori (Construction)
4. Operazioni (Operations)
5. Estensioni (Extensions)

In particolare:

  • Interfaces
    • ADAPTER
    • FACADE
    • COMPOSITE
    • BRIDGE
  • Responsibility
    • SINGLETON
    • OBSERVER
    • MEDIATOR
    • PROXY
    • CHAIN OF RESPONSIBILITY
    • FLYWEIGHT
  • Construction
    • BUILDER
    • FACTORY METHOD
    • ABSTRACT FACTORY
    • PROTOTYPE
    • MEMENTO
  • Operations
    • TEMPLATE METHOD
    • STATE
    • STRATEGY
    • COMMAND
    • INTERPRETER
  • Extensions
    • DECORATOR
    • ITERATOR
    • VISITOR
§INTERFACE PATTERNS§  – INTRODUZIONE ALLE INTERFACCE

Una interfaccia è una collezioni di metodi e variabili che rappresentano la parte visibile della classe che implementa l’interfaccia: in altra parola una interfaccia si può considerare come
*una dichiarazione di intenti*.

Una classe astratta senza metodi non abstract è simile ad una interfaccia, ma rimangono alcune differenze.
Differenze tra abstract classes e interfacce in Java:
– una classe può implementare più di una interfaccia ma non può estendere più di una classe abstract.
– una classe astratta può anche implementare metodi non astratti, mentre tutti i metodi di una interfaccia sono per forza astratti.
– una classe astratta può dichiarare e usare variabili di istanza, una interfaccia non può farlo, può solo creare constanti final e static.
– una classe astratta può avere diversi tipi di accesso ai metodi: public, protected, private o package (default). Tutti i metodi di una interfaccia sono implicitamente public.
– una classe astratta può definire costruttori, una interfaccia non può farlo.

Problema da risolvere e relativo pattern Interfaces:
– adattare l’interfaccia di una classe per corrispondere all’interfaccia che il cliente di aspetta: ADAPTER
– fornire una interfaccia semplice ad una collezioni di classi: FACADE
– definire una interfaccia che possa essere implementata sia da oggetti individuali sia da gruppi di oggetti: COMPOSITE
– disaccoppiare una astrazione dalla sua implementazione in modo che le due parti possano variare in modo indipendente: BRIDGE

JBoss 7 SOAP Web Service – JAX-WS 2.2 endorset in JDK 1.6

JBoss 7 mette a disposizione JBoss WS come framework per l’implementazione di web service SOAP.

Fra le funzionalità fornite, è possibile creare l’implementazione del web service a partire dal WSDL (approccio Top Down).

Il tool suppone di default suppone la presenza di JAX-WS 2.2. Il problema nasce dall’assenza della implementazione di riferimento di JAX-WS 2.2 all’interno del Jdk 1.6. Per ovviare al problema si può effettuare l’endorset dei jar necessari dentro il jdk.

Esempio:

IDE eclipse Indigo + plug-in JBoss per web service (JBossAS Tools, JBoss WebService Tools, Hibernate Tools, JBoss JAX-RS Tools)

JDK 1.6.x

Generando il web service da WSDL si ottiene un errore di compilazione:

Errore causato dalla mancanza di JAX-WS 2.2 dentro JDK 1.6

Errore causato dalla mancanza di JAX-WS 2.2 dentro JDK 1.6

Si può risolvere il problema effettuando l’endorset del jar della versione 2.2 dentro il JDK:

  • scaricare la RI di JAX-WS 2.2
  • copiare SOLO i due jar  jaxws-api.jar e jaxb-api.jar all’interno della directory del JDK /jre/lib/endorsed.

Ora, utilizzando il wizard, si può creare il web service:

wizard_creazione_ws wizard_creazione_ws_2

 

(se persiste l’errore di compilazione…chiudere e riaprire eclipse…)

See more at:
http://www.bitspedia.com/2012/03/how-to-use-jax-ws-226-with-jdk-16.html
http://docs.oracle.com/javase/6/docs/technotes/guides/standards/index.html
http://jax-ws.java.net/2.2/docs/ReleaseNotes.html

Spago

SPAGO è un framework J2EE, che implementa il pattern MVC. Fornisce una soluzione per lo sviluppo di applicazioni multicanale/multiprotocollo e l'integrazione di servizi.

Consente lo sviluppo di applicazioni Web, l'integrazione con infrastrutture esistenti e la pubblicazione di servizi su canali diversi.

MVC in SPAGO:

Architettura MVC SPAGO