2012/2013

Recherches -J2EE-

Enseignante : Mme BEN YAHIA Salwa

Par :

GL3/2

1  

Spring MVC : Exception handling  

I. Exception handling infrastructure  

A.  Main classes 

To manage exceptions, Spring MVC offers by default the following classes:  ExceptionHandlerExceptionResolver: generic exception handler  DefaultHandlerExceptionResolver: exception handler supporting a set of predefined exceptions  SimpleMappingExceptionResolver: good old exception handler (available since 2003!) to map a 

custom exception to a specific error page It is possible to use those 3 handlers, all we need to do is to declare a HandlerExceptionResolverComposite which is basically a container of Exception handlers and delegates the exception handling to each of the registered handler  

With this configuration, each exception handler wil be invoked with respect to their declaration order (a list is ordered by nature)  

B. Detailed description  

1. ExceptionHandlerExceptionResolver This exception handler is the default handler and covers 80% of the use cases. On startup the class is registered in the Spring context with a set of default method argument resolvers and method return values handlers: Default argument resolvers 

ServletRequestMethodArgumentResolver: supports the following types as method arguments  o WebRequest o ServletRequest o MultipartRequest o HttpSession o Principal (for security) o Locale o InputStream o Reader 

ServletResponseMethodArgumentResolver: supports the following types as method arguments  o ServletResponse o OutputStream o Writer 

In addition to these method arguments, this handler also handle the following return types and method annotations: 

2  

Return types:  o ModelAndView o Model o View o String: simple view name return o Map o HttpEntity: to customize Http request body as well as header 

Annotations:  o @ModelAttribute o @RequestBody o @ResponseBody 

 

2) DefaultHandlerExceptionResolver 

This class simply handles the following default exceptions: 

  You need not declare any method with @ExceptionHandler for the above exceptions, they will be handled automatically by the class.   

3) SimpleMappingExceptionResolver 

  This class lets you map an exception to an view. Simply define its “exceptionMappings” property by providing a list of exception/view pair values: 

 Above, we map the ClassNotFoundException to the view “pages/classNotFoundException” and CloneNotSupportedException to “pages/cloneNotSupportedException“. Of course you must ensure that the view declaration is correct and the actual pages exist.    

3  

II. Exception handling strategies In this chapter we discuss about various strategies to handle exceptions.  

A. Return an error message to be displayed 

This is the simplest use case for exception handling: 

 

Above, on NullPointerException detection, we return the source message. Since the handler method is annotated with @ResponseBody, the source message will be simply put in the response body. On the client side, some Javascript to display an error panel with the message: 

 

Please notice that the returned exception message is handled by a success function (line 6) in Javascript. Indeed even if an Exception occured at the server side, as long as the Http response status is 200 the client side will consider it as a success. 

  

B. Return a dedicated error page This strategy simply returns a generic error page and hides all the exception details from the end user. 

 Please note that there is no redirect, we simply render a generic error page instead of the normal target page. 

  

4  

C. Return an error code with custom message 

In this strategy, we let Spring build an generic error page based on the Http code we provide with a custom message. 

 

Please note the definition of Http code and custom error message with the @ResponseStatus annotation at line 7. This strategy is quite equivalent to defining the error page at servlet level in the web.xml: 

 

 The result:  

   

D. Redirect to a custom page with custom error message 

In this strategy, we do a real HTTP redirect to a custom error page with a custom error message. 

 The above code has some hacks. First in the exception handler we put the error message as static attribute of the redirect view object (line 11). It will end up being appended in the query string: errorRedirectPage?errorMessage=xxxx Then in the error message method handler, we extract it from the query with @RequestParam(“errorMessage”) (line 16)and put it back into the model object. Why such a hack ? Why don’t we use the RedirectAttribute map that exists in Spring MVC 3.1 ? Simply because the ExceptionHandlerExceptionResolver class does not support this method argument. 

5  

Of course we could have added the RedirectAttributesMethodArgumentResolver as custom argument resolver but it would require a binderFactory and the current infrastructure of ExceptionHandlerExceptionResolver does not support. 

  

E. Return an exception wrapper object in JSON format, AJAX response 

In this strategy, we return an exception wrapper object serialized with JSON format back to the client 

 To achieve this, we need to add a @ResponseBody annotation to the exception handler method but also a @ResponseStatus annotation to send an Http error code. Unlike the strategy described at A, in this case we want to trigger the error listener at client‐side so we need to send back an Http status other than 200. 

 In the error handler function, we need to extract the exception wrapper object from the body of the returned page (jqXHR.responseText, line 9) and convert it to an JSON object. Next we can extract various exception information from the wrapper object and display them in a modal panel. The way to display the error details is up to you (modal panel, custom message box …) 

 

6  

Programmation orientée aspect 1. Definition 

La programmation orientée aspect (POA, en anglais aspect‐oriented programming ou AOP) est un 

paradigme de programmation qui permet de traiter séparément les préoccupations transverses (en anglais, cross‐cutting concerns), qui relèvent souvent de la technique (aspect en anglais), des préoccupations métier, qui constituent le cœur d'une application. Un exemple classique d'utilisation est la journalisation, mais certains principes architecturaux ou modèles de conception peuvent être implémentés à l'aide de ce paradigme de programmation, comme l'inversion de contrôle (en anglais, inversion of control ou IOC). La programmation orientée aspect est bien une technique transversale (paradigme) et n'est pas liée à un langage de programmation en particulier mais peut être mise en œuvre aussi bien avec un langage orienté objet comme Python qu'avec un langage procédural comme le C, le seul pré‐requis étant l'existence d'un tisseur d'aspect pour le langage cible. 

2. Historique Les concepts de la programmation orientée aspect ont été formulés par Gregor Kiczales et son équipe, qui travaillait alors pour le Xerox PARC. 

3. Limites techniques Les techniques actuelles de conception logicielles et de programmation amènent à découper un logiciel en modules logiciels a priori indépendants les uns des autres car gérant des aspects différents du système conçu. Certains de ces modules implémentent soit des tâches métier, soit des tâches plus applicatives comme l'authentification des utilisateurs ou encore offrant des services techniques comme la génération de trace ou le multi‐threading. Ces modules représentent alors au même niveau d'abstraction, différentes considérations (différents aspects) d'une application, le plus souvent celui de la couche métier. Liste non exhaustive d'exemples de modules : 

gestion des utilisateurs (authentification) ;  archivage des données (persistance) ;  programmation concurrentielle (multi‐threading) ;  information pendant l'exécution du logiciel (trace) ;  logique métier (par exemple informatique de gestion, système d'information géographique, commerce 

électronique...). Dans la pratique, les considérations techniques que sont censés implémenter les modules non seulement s'entrecroisent (par exemple la gestion des utilisateurs fait aussi appel à la génération de trace) mais sont de plus réparties dans la couche métier : c'est l'intrication ou entrecroisement des aspects techniques (crosscutting en anglais). Ainsi, une couche logicielle, initialement dédiée à gérer la logique métier applicative (par exemple un système bancaire), va se retrouver dépendante de modules gérant les aspects transactionnels, journalisation, etc., conduisant à une complexification du code, de son développement et de sa maintenance. La programmation par aspect va permettre d'extraire les dépendances entre modules concernant des aspects techniques entrecroisés et de les gérer depuis l'extérieur de ces modules en les spécifiant dans des composants du système à développer nommés « aspects » ; ils sont développés à un autre niveau d'abstraction. 

4. Principe Ainsi, au lieu d'avoir un appel direct à un module technique depuis un module métier, ou entre deux modules techniques différents, en programmation par aspect, le code du module en cours de développement est concentré sur le but poursuivi (la logique bancaire, pour reprendre notre exemple) , tandis qu'un aspect est spécifié de façon autonome, implémentant un aspect technique particulier, par exemple la persistance ou encore la génération de trace. Un ensemble de points d'insertions ou joinpoint en anglais sont ensuite définis pour établir la liaison entre l'aspect et le code métier ou un autre aspect. Ces définitions de joinpoint sont définis dans le cadre de la POA. Selon les frameworks ou les langages d'aspects, la fusion du code technique avec le code métier est alors soit réalisée à la compilation, soit à l'exécution. 

7  

Bien sûr, si chaque aspect créé devait lui‐même définir explicitement à quel point d'exécution il doit s'insérer dans le code métier ou dans un autre aspect, c’est‐à‐dire par exemple avec une dépendance directe vers le module métier où devra s'intercaler le code technique, on n'aurait alors fait que décaler le problème. Aussi, l'astuce utilisée par plusieurs langages consiste à utiliser un système d'expressions rationnelles pour préciser à quels points d'exécution (en anglais, joinpoint) du système l'aspect spécifié devra être activé. 

Exemple / Étude de cas 

Un logiciel métier qui décrit un environnement distribué est écrit de manière classique en utilisant une décomposition fonctionnelle ou objet. Au moment du déploiement du système, on s’aperçoit que les machines physiques sur lesquelles le système va tourner ont en fait des caractéristiques hétérogènes (puissance, bande passante, etc.) qui impactent ou modifient les fonctionnalités du logiciel d’origine. Une approche fréquente consisterait en ce cas à « patcher » le code un peu partout pour adapter le logiciel à son environnement d’exécution réel. Avec les outils de POA on peut facilement spécifier les changements requis SANS toucher aux sources du code original, dont la logique reste intacte. Les outils de programmation par aspect sont en fait similaires aux modificateurs (before, after et around) que l’on trouve dans des langages comme LISP, auxquels on a ajouté la possibilité d’une description d’insertions déclaratives. Un aspect permet donc de spécifier : 

les points d'action (pointcut), qui définissent les points de jonction satisfaisants aux conditions d'activation de l'aspect, donc le ou les moments où l'interaction va avoir lieu, 

les greffons, c’est‐à‐dire les programmes (advice) qui seront activés avant, autour de ou après les points d'action définis. 

5. Avantages Le couplage entre les modules gérant des aspects techniques peut être réduit de façon très importante, en utilisant ce principe, ce qui présente de nombreux avantages : 

maintenance aisée : les modules techniques, sous forme d'aspect, peuvent être maintenus plus facilement du fait de leur détachement de leur utilisation, 

meilleure réutilisation : tout module peut être réutilisé sans se préoccuper de son environnement et indépendamment du métier ou du domaine d'application. Chaque module implémentant une fonctionnalité technique précise, on n'a pas besoin de se préoccuper des évolutions futures : de nouvelles fonctionnalités pourront être implémentées dans de nouveaux modules qui interagiront avec le système au travers des aspects. 

gain de productivité : le programmeur ne se préoccupe que de l'aspect de l'application qui le concerne, ce qui simplifie son travail, et permet d'augmenter la parallélisation du développement. 

amélioration de la qualité du code : la simplification du code qu'entraîne la programmation par aspect permet de le rendre plus lisible et donc de meilleure qualité. 

6. Inconvénients Le tissage d'aspect qui n'est finalement que de la génération automatique de code inséré à certains points d'exécution du système développé, produit un code qui peut être difficile à analyser (parce que généré automatiquement) lors des phases de mise au point des logiciels (débogage, test). Mais en fait cette difficulté est du même ordre que celle apportée par toute décomposition non linéaire (fonctionnelle ou objet par exemple). Cela dit, une implémentation comme AJDT (acronyme anglais de AspectJ Development Tools), basée sur AspectJ, offre des outils sophistiqués qui permettent de passer de façon transparente, en mode débogage, du code d'une classe à celui d'un aspect. 

7. Lexique La programmation orientée aspect, parce qu'elle propose un paradigme de programmation et de nouveaux concepts, a développé un jargon bien spécifique qui ne facilite pas la compréhension de ses concepts qui sont, en définitive, simples mais puissants. Aspect  

Un module définissant des greffons et leurs points d'activation ; 

Greffon (advice)  

8  

Un programme qui sera activé à un certain point d'exécution du système, précisé par un point de 

jonction ; 

Tissage ou tramage (weaving)  

Insertion statique ou dynamique dans le système logiciel de l'appel aux greffons ; 

Point de coupe, d'action, de coupure ou de greffe (pointcut)  

Endroit du logiciel où est inséré un greffon par le tisseur d'aspect ; 

Point de jonction ou d'exécution (join point)  

Endroit spécifique dans le flot d'exécution du système, où il est valide d'insérer un greffon. Pour 

clarifier le propos, il n'est pas possible, par exemple, d'insérer un greffon au milieu du code d'une 

fonction. Par contre on pourra le faire avant, autour de, à la place ou après l'appel de la fonction. 

Considérations entrecroisées ou préoccupations transversales (cross‐cutting concerns)  

Mélange, au sein d'un même programme, de sous‐programmes distincts couvrant des aspects 

techniques séparés. 

8. Implémentation Stratégies 

Deux grandes stratégies de tissage d'aspects existent :  le tissage statique par instrumentation du code source ou du pseudo‐code machine intermédiaire 

(bytecode Java, IL)  le tissage dynamique lors de l'exécution du logiciel (implémentée par exemple par JAC) 

Tisseurs d'aspects  En Java :  

o AspectJ : Extension du langage Java nécessitant donc une étape de précompilation2. Le résultat est toutefois du bytecode Java standard. 

o Java Aspect Components (JAC) : Framework 100 % Java conçu par des centres de recherche français3. 

o Spring : Spring AOP  En C++ :  

o AspectC++ (en)  En .NET (C#, VB.NET …) :  

o LOOM.NET o AspectDNG o PostSharp o Spring.NET o CodeFluent Entities 

En PHP :  o la Go! AOP bibliothèque o AOP Pecl extension 

En C :  o Aspect‐C 

En Caml :  o Aspectual Caml 

En Python :  

o Aspyct o Aspects o Spring Python 

En Common Lisp :  o AspectL 

En Ruby :  o AspectR 

En Lua :  o AspectLua o RE‐AspectLua, le remplaçant 

d'AspectLua 

 

     

9  

AJAX

What is AJAX? 

AJAX = Asynchronous JavaScript and XML. 

AJAX is a technique for creating fast and dynamic web pages. 

AJAX allows web pages to be updated asynchronously by exchanging small amounts of data with the server behind the scenes. This means that it is possible to update parts of a web page, without reloading the whole page. 

Classic web pages, (which do not use AJAX) must reload the entire page if the content should change. 

Examples of applications using AJAX: Google Maps, Gmail, Youtube, and Facebook tabs. 

 

How AJAX Works 

 

 

AJAX is Based on Internet Standards 

AJAX is based on internet standards, and uses a combination of: 

XMLHttpRequest object (to exchange data asynchronously with a server) 

JavaScript/DOM (to display/interact with the information) 

CSS (to style the data) 

XML (often used as the format for transferring data) 

  AJAX applications are browser‐ and platform‐independent! 

 

Google Suggest 

AJAX was made popular in 2005 by Google, with Google Suggest. 

Google Suggest is using AJAX to create a very dynamic web interface: When you start typing in Google's search box, a JavaScript sends the letters off to a server and the server returns a list of suggestions. 

 

Exam

Trad

The udata tservea data

The pcanno

Ajax

Here in theform 

Algo

if (u }

mple 

ditional me

user enters tto the serveer‐side scripabase and d

problem witot save the 

 Method 

when the ue backgrounfrom the pa

orithm 

user hits commenemail //HappCallPa //UserRemoveDispla

ethod 

the commeer‐side script(for exampdisplay a 'Th

th this apprentered da

user clicks thnd. The useage and sho

the submint = (user= (user's

pens in Baage("save_

r sees thie(form) ay("Thank

ents and empt through tple a PHP pahank You' m

och is that tta without 

he Submit br does not sow a 'Thank

it button)r submittes email id

ackground _comment.p

is...

you for y

mail and thethe post or age) by loadmessage in t

the users loloading the

button, a javsee it beingk you' messa

) { ed commentd)

php?commen

your comme

n clicks the get methodding that pathe browser

oses some te PHP file. 

vascript fung loaded. Insage dynami

t)

nt=" + com

ent.")

submit butd. When thiage in the br. 

ime waiting

nction is calstead the Jaically ‐ with

mment + "&

tton. The brs is done, th

browser. Thi

g for anothe

led which loavaScript wout reloadi

 

&email=" +

rowser sendhe browseris page will 

er page to lo

 

oads the seill immediatng the page

+ email);

ds the enterr will call thesave the da

oad. The pa

rver‐side sctly remove e. 

10 

red e ata to 

age 

 

cript the 

 

11  

Application 

The given example was for a simple application. In more advaced uses, the result generated by the called server‐side script will be taken and used in the page. Some applications that would be impossible without Ajax are... 

Auto complition for form fields (Google Suggest)  Live Chat (XHTML live Chat) 

Examples of use of Ajax 

GMail  Google Suggest  Backpackit  A live version of the Feedback Example ‐ See Ajax Contact Form for explanation. 

Problems 

Breaks the Back button  Works only on the latest browsers  Harder to make and maintain  Goes against user expectations  Assesibility issues