Récuperer la clé d'un FacesMessage

Version imprimable

30/03/2009, 17h12
issamjet

Récuperer la clé d'un FacesMessage

Salut,

je suis entrain de réaliser un générateur de fichiers de tests pour les applications JSF.
La tache la plus importante est de récupérer les scénarios de chaque utilisateur lors de sa navigation dans une application JSF.
La difficulté que j'ai trouvée est comment récupérer les clés des messages(FacesMessage)
Par exemple :
quand JSF génère un message ("Value is required") mon générateur doit automatiquement détecter la clé de ce message qui est ("javax.faces.component.UIInput.REQUIRED").

Merci.
30/03/2009, 17h48
tchize_

ca risque d'être impossible à faire (si deux clés donnent le même message final, impossible de distinguer). Pourquoi ne pas simplement te baser sur le texte dans une langue et imposer cette langue lors du test?
30/03/2009, 17h59
yciabaud

Ils sont dans le contexte JSF, tu itere sur tous les messages et tu teste si la clef corresponds.

cf. FacesContext.getMessages()
30/03/2009, 18h03
issamjet

Citation:

Envoyé par tchize_

ça risque d'être impossible à faire (si deux clés donnent le même message final, impossible de distinguer). Pourquoi ne pas simplement te baser sur le texte dans une langue et imposer cette langue lors du test?

Merci tchize_ pour la réponse.
En fait, mon travail consiste à récupérer les clés car les messages devront être personnalisés par l'utilisateur il peut écrire n'importe quoi comme message d'erreur mais la clé reste toujours invariante.
Ma mission consiste à pouvoir récupérer la clé lors de l'envoi du message d'erreur par JSF et non pas à partir du message lui même pour la raison que vous avez mentionnée.
30/03/2009, 18h06
issamjet

Citation:

Envoyé par yciabaud

Ils sont dans le contexte JSF, tu itere sur tous les messages et tu teste si la clef corresponds.

cf. FacesContext.getMessages()

Merci yciabaud

J'ai pensé à ça mais dans ce cas on peut arriver dans une situation où il y a le même message pour deux clés différentes.
30/03/2009, 20h14
tchize_

tu veux les messages avant ou après le rendu? Si tu veux personnaliser les messages d'erreurs, c'est déjà standard dans JSF. Faut fouiner un peux dans les specs, y a moyen de fournir ton propre ressource bundle à JSF et les noms des clés est standard. Si tu veux la liste des messages d'erreurs pour la page courante, c'est de fait comme a dit yciabaud. Si tu veux parser la page pour choper les erreur, bonne chance :-)
31/03/2009, 11h56
issamjet

Citation:

Envoyé par tchize_

tu veux les messages avant ou après le rendu? Si tu veux personnaliser les messages d'erreurs, c'est déjà standard dans JSF. Faut fouiner un peux dans les specs, y a moyen de fournir ton propre ressource bundle à JSF et les noms des clés est standard. Si tu veux la liste des messages d'erreurs pour la page courante, c'est de fait comme a dit yciabaud. Si tu veux parser la page pour choper les erreur, bonne chance :-)

Merci

En fait je veux récupérer automatiquement la liste des clés des messages d'erreurs générés pour la page courante.
Le fait de parser le fichier de ressources presente un probleme car un developpeur JSF peut personnaliser ses messages comme il veut, donc on peut trouver le même message qui a deux clés différentes. Par exemple:
javax.faces.component.UIInput.REQUIRED=entrer une valeur ici
Et
javax.faces.converter.NumberConverter.NUMBER=entrer une valeur ici.

Le problème, c'est que les messages sont générés par les composants de la manière suivantes (myfaces, _MessagesUtils.java):

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40     static void addErrorMessage(FacesContext facesContext,
41                                 UIComponent component,
42                                 String messageId)
43     {
44         facesContext.addMessage(component.getClientId(facesContext),
45                                 getMessage(facesContext,
46                                            facesContext.getViewRoot().getLocale(),
47                                            FacesMessage.SEVERITY_ERROR,
48                                            messageId,
49                                            null));
50     }
51
64     static FacesMessage getMessage(FacesContext facesContext,
65                                    Locale locale,
66                                    FacesMessage.Severity severity,
67                                    String messageId,
68                                    Object args[])
69     {
70         ResourceBundle appBundle;
71         ResourceBundle defBundle;
72         String summary;
73         String detail;
74
75         appBundle = getApplicationBundle(facesContext, locale);
76         summary = getBundleString(appBundle, messageId);
//.......
114         if (args != null && args.length > 0)
115         {
116             MessageFormat format;
117
118             if (summary != null)
119             {
120                 format = new MessageFormat JavaDoc(summary, locale);
121                 summary = format.format(args);
122             }
//.....
130
131         return new FacesMessage(severity, summary, detail);
132     }

Comme tu le vois, la clé n'est stockée nulle part, on traduit directement le message d'erreur dans la langue de l'utilisateur.

Citation:

Envoyé par tchize_

Le problème, c'est que les messages sont générés par les composants de la manière suivantes (myfaces, _MessagesUtils.java):

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40     static void addErrorMessage(FacesContext facesContext,
41                                 UIComponent component,
42                                 String messageId)
43     {
44         facesContext.addMessage(component.getClientId(facesContext),
45                                 getMessage(facesContext,
46                                            facesContext.getViewRoot().getLocale(),
47                                            FacesMessage.SEVERITY_ERROR,
48                                            messageId,
49                                            null));
50     }
51
64     static FacesMessage getMessage(FacesContext facesContext,
65                                    Locale locale,
66                                    FacesMessage.Severity severity,
67                                    String messageId,
68                                    Object args[])
69     {
70         ResourceBundle appBundle;
71         ResourceBundle defBundle;
72         String summary;
73         String detail;
74
75         appBundle = getApplicationBundle(facesContext, locale);
76         summary = getBundleString(appBundle, messageId);
//.......
114         if (args != null && args.length > 0)
115         {
116             MessageFormat format;
117
118             if (summary != null)
119             {
120                 format = new MessageFormat JavaDoc(summary, locale);
121                 summary = format.format(args);
122             }
//.....
130
131         return new FacesMessage(severity, summary, detail);
132     }

Comme tu le vois, la clé n'est stockée nulle part, on traduit directement le message d'erreur dans la langue de l'utilisateur.

Merci
Le problème maintenant est plus claire.
Une seule chose, d'où JSF récupère le paramètre messageId?

31/03/2009, 12h56
tchize_

c'est le paramètre passé en méthode à l'argument. Le code que je te montre est spécifique à une version de myfaces, comem ce sont des classes internes, elle peuvent changer à tout moment. Ton message id est juste passé en paramètre par le composant lorsqu'il a un problème dans myfaces. La manière dont ce message id est récupéré par le composant dépend du composant (hardcodé, calculé, constante, ....)
31/03/2009, 13h55
issamjet

Citation:

Envoyé par tchize_

c'est le paramètre passé en méthode à l'argument. Le code que je te montre est spécifique à une version de myfaces, comem ce sont des classes internes, elle peuvent changer à tout moment. Ton message id est juste passé en paramètre par le composant lorsqu'il a un problème dans myfaces. La manière dont ce message id est récupéré par le composant dépend du composant (hardcodé, calculé, constante, ....)

D'accord, mais est ce que je peux intercepter le message lors de son envoi par jsf comme ça je peux connaitre la cause et parsuite la clé.
31/03/2009, 14h18
tchize_

le "message" envoyé à JSF par le composant est un object FacesMessage contenant du pur texte déjà mis en forme opur l'utilisateur (locale correct, ressourcebundle utilisé, éventuellement MessageFormat utilisé), y a rien d'autre à intercepter.
31/03/2009, 15h46
issamjet

Citation:

Envoyé par tchize_

le "message" envoyé à JSF par le composant est un object FacesMessage contenant du pur texte déjà mis en forme opur l'utilisateur (locale correct, ressourcebundle utilisé, éventuellement MessageFormat utilisé), y a rien d'autre à intercepter.

OK. Vous me dites donc que la seule solution est de chercher la clé en parsant le fichier de ressources en supposant qu'il n'y a pas de messages redondants.
31/03/2009, 17h40
tchize_

je me dit que la solution serait surtout de se passer du besoin d'avoir à connaitre les clé, j'ai du mal a comprendre pourquoi tu veux retrouver les clés associées aux faces message. Parce que, même en parsant le fichier de ressources, va y avoir des trucs dur à interprêter à l'envers:
http://svn.apache.org/repos/asf/myfa..._fr.properties
31/03/2009, 18h45
issamjet

Citation:

Envoyé par tchize_

je me dit que la solution serait surtout de se passer du besoin d'avoir à connaitre les clé, j'ai du mal a comprendre pourquoi tu veux retrouver les clés associées aux faces message. Parce que, même en parsant le fichier de ressources, va y avoir des trucs dur à interprêter à l'envers:
http://svn.apache.org/repos/asf/myfa..._fr.properties

Mon projet consiste à intercepter la trace d'un utilisateur et générer automatiquement un fichier contenant cette trace avec tous les paramètres saisis par l'utilisateur,tous les clés des messages d'erreurs....
Ce fichier sera reconnu par le frameWork JSF UNIT et tout le scénario sera rejoué tout en testant est ce que la navigation est la même, est ce que les messages d'erreurs sont les mêmes(nécessité de la clé car le contenu des messages peut être modifié et pas la clé)
31/03/2009, 21h00
tchize_

si tu stocke la langue de l'utilisateur et que tu sais quel ressource bundle est déployé (je suppose que tu le change pas tous les jours), rejouer le scénar rejouera théoriquement les mêmes messages d'erreur, je vois donc pas la nécessiter de ce casser le cul à essayer de peut être arriver à récupérer correctement les clés, alors que tu peux te baser directement les messages. Au pire, quand tu crée ton test unitaire, si c'est mais vraiment nécessaire, t'ouvre toi meme le ressource bundle pour trouver tes clés.
01/04/2009, 11h11
issamjet

Citation:

Envoyé par tchize_

si tu stocke la langue de l'utilisateur et que tu sais quel ressource bundle est déployé (je suppose que tu le change pas tous les jours), rejouer le scénar rejouera théoriquement les mêmes messages d'erreur, je vois donc pas la nécessiter de ce casser le cul à essayer de peut être arriver à récupérer correctement les clés, alors que tu peux te baser directement les messages. Au pire, quand tu crée ton test unitaire, si c'est mais vraiment nécessaire, t'ouvre toi meme le ressource bundle pour trouver tes clés.

Merci
j'ai commencé à faire ça.
je veux savoir est ce que je peux transformer ce fichier en HashMap (est ce qu'il y a des méthodes implémentées utilisables) à la place de le parser.
01/04/2009, 13h41
tchize_

si tu veux pas t'emmerder à parser et que tu ne stocke que des string dans ta map, utilise la sérialisation pour l'écrire dans une fichier ton scénar :)
02/04/2009, 10h49
issamjet

Mais le problème reste pour les messages de validation des formulaires que le développeur les crée lui même il les lance lors de la validation selon son métier.
02/04/2009, 11h15
tchize_

et alors, tu va rejouer, normalement, le test avec les même métiers
06/04/2009, 11h17
issamjet

Bonjour,
Mon problème reste toujours non résolu jusqu'à maintenant, la solution consiste tout d'abord à savoir d'où JSF récupère le String MessageId, certainement il y a une ou plusieurs phases dans le cycle de vie où ce messageId est généré puis utilisé par la méthode
" static FacesMessage getMessage(FacesContext facesContext,
Locale locale,FacesMessage.Severity severity,String messageId,Object args[])"
:roll:
06/04/2009, 11h26
tchize_

cette méthode statique est protégée et spécifique à myfaces, l'implémentation sun RI utilisera un tout autre système. La seule chose standardisée, c'est dans quel fichier properties on va chercher les clés et les noms des clés. Après, chaque composant crée ses FacesMessages comme il le désire. Tu peux, éventuellement, peut etre jouer sur le fait que le fichier soit standardisé pour fournir ta propre implémentation de ressourcebundle qui, au passage, enregistrerait ce qu'on lui demande comme clés. Mais ca pose plusieurs problèmes:

1) gérer lesthread multiples faisant les demandes
2) c'est pas parce qu'un composant demande un clé qu'il va nécessairement en faire un facesmessage
3) tu saura quel clé est demandée, mais pas quel composant l'a demandée.

Bonjour

J'ai voulu faire quelques modifications à la classe javax.faces.component.UIInput. J'ai construit un nouveau package javax.faces.component et j'y ai déclaré une nouvelle classe UIInput dans la quelle j'ai mis le code source de la classe UIInput de JSF. Le message d'erreur suivant m'est affiché

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
 
 
 ERROR [[/testJSF]] Exception lors de l'envoi de l'évènement contexte initialisé (context initialized) à l'instance de classe d'écoute (listener) org.jboss.web.jsf.integration.config.JBossJSFConfigureListener
java.lang.VerifyError: (class: org/richfaces/renderkit/PickListRenderer, method: getConvertedValue signature: (Ljavax/faces/context/FacesContext;Ljavax/faces/component/UIComponent;Ljava/lang/Object;)Ljava/lang/Object;) Incompatible argument to function
 at java.lang.Class.getDeclaredConstructors0(Native Method)
 at java.lang.Class.privateGetDeclaredConstructors(Unknown Source)
 at java.lang.Class.getConstructor0(Unknown Source)
 at java.lang.Class.newInstance0(Unknown Source)
 at java.lang.Class.newInstance(Unknown Source)
 at com.sun.faces.config.ConfigureListener.configure(ConfigureListener.java:1001)
 at com.sun.faces.config.ConfigureListener.configure(ConfigureListener.java:1073)
 at com.sun.faces.config.ConfigureListener.configure(ConfigureListener.java:493)
 at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:381)
 at org.jboss.web.jsf.integration.config.JBossJSFConfigureListener.contextInitialized(JBossJSFConfigureListener.java:69)
 at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3856)
 at org.apache.catalina.core.StandardContext.start(StandardContext.java:4361)
 at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:790)
 at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:770)
 at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:553)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:296)
 at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.apache.catalina.core.StandardContext.init(StandardContext.java:5312)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:296)
 at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.web.tomcat.service.TomcatDeployer.performDeployInternal(TomcatDeployer.java:301)
 at org.jboss.web.tomcat.service.TomcatDeployer.performDeploy(TomcatDeployer.java:104)
 at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:375)
 at org.jboss.web.WebModule.startModule(WebModule.java:83)
 at org.jboss.web.WebModule.startService(WebModule.java:61)
 at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
 at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
 at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
 at $Proxy0.start(Unknown Source)
 at org.jboss.system.ServiceController.start(ServiceController.java:417)
 at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
 at $Proxy44.start(Unknown Source)
 at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:466)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
 at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
 at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
 at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
 at org.jboss.wsf.container.jboss42.DeployerInterceptor.start(DeployerInterceptor.java:87)
 at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.start(SubDeployerInterceptorSupport.java:188)
 at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:95)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
 at $Proxy45.start(Unknown Source)
 at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
 at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
 at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
 at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
 at $Proxy9.deploy(Unknown Source)
 at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
 at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:610)
 at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
 at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:274)
 at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:225)

sachant que j'ai fait la meme chose avec FacesServlet et son package javax.faces.webapp et ça a marché

09/04/2009, 00h09
tchize_

si tu veux modifier une classe déjà existante, soit tu prend les source et tu la remplace, tu recompile let source et voilà, soit, si tu la met dans un package à part, tu lui donne un nouveau nom. Sinon, tu va avoir des problème avec le classloader, tu saura jamais quelle version est invoquée puisqu'elles ont le meme nom et le meme package.
10/04/2009, 16h20
issamjet

Bonjour,

Dans mon cas, je veux modifier la classe UIInput.java mais celle ci ne peut pas être compilée toujours il y a des erreurs même si j'y fais rien car cette classe appartient à JSF API. que faire??
10/04/2009, 17h08
tchize_

quel procédure tu suis pour modifier uiinput?
10/04/2009, 17h22
issamjet

Ces histoires sont nouvelles pour moi.
mais j'ai essayé avec une autre classe et ça a marché.J'ai fait des modifications à la classe FacesServlet et j'ai déclaré un nouveau package portant le même nom "javax.faces.webapp" et j'y ai mis cette classe et je l'ai modifiée pas mal de fois et ça a marché.Mais avec la classe UIInput c'était pas le cas
10/04/2009, 17h39
tchize_

si tu modifie une classe, fait bien attention a supprimer l'ancienne version. De toutes facons, la manière la plus propre reste de prendre les sources de ce que tu veux modifier, de faire tes modifications dedans et de faire ensuite un package avec ces source, en utilisant la méthode de compilation décrite par l'éditeur dont tu as eu les source. Exemple avec myfaces: tu télécharge les sources, tu fait ts modification, tu change le numéro de version dans le pom.xml et tu fais un "mvn package" pour créer ta propre release.
10/04/2009, 18h00
issamjet

Désolé, mais j'ai pas pigé ce que vous voulez dire, si vous pouvez m'expliquer par détails, je serai reconnaissant.

et ou je peut trouver la classe messageFactory pour la modifier et comment le faire
10/04/2009, 20h03
tchize_
alors, parce que visiblement c'est pas très clair chez toi.

Le code que je t'ai montré est spécifique à une version précise de l'implémentation myfaces de JSF. Modifier ces classes signifie que
1. Tu va être bloqué sur cette version, tu ne pourra plus faire d'upgrade, à moins de faire toi même le suivi de mise à jour et appliquer tous les patchs inter-versions
2. tu n'interceptera que les composant de base de myfaces faisant appel à cette classe, pas ceux qui construisent directement leur message, ni les composants additionnel
3. Tu ne pourra pas utiliser autre chose que myfaces si ça s'avère nécessaire par la suite
4. Ce n'est absolument pas standard, tu va patcher une implémentation en lui ajoutant une fonctionnalité non prévue dans la spécification.
C'est donc une solution bancale (en même temps le besoin de base m'a l'air bancal, masi bon, t'es seul juge)

Pour trouver cette classe, tu fais une recherche dans le code source que tu pourra trouver là bas. http://myfaces.apache.org/download.html

Si je t'avais montré ce code, c'est justement pour te démontrer que c'était assez foireux comme besoin :)
13/04/2009, 11h30
issamjet

la classe que je veux modifier(MessageFactory) est inexistante dans la source dans jsf-api mais elle existe dans différentes places dans Build.
comment faire dans ce cas??
13/04/2009, 12h27
tchize_

elle est probablement dans le impl, suffit de faire une recherche par nom de fichier.
14/04/2009, 20h05
issamjet

Merci bien pour ton aide tchize, j'ai arrivé à résoudre mon problème, je vais poster la solution inchAllah

Merci