Probléme avec le scope request

**Esil2008** · 02/07/2008, 18h33

Salut,
J'utilise un scope request pour le managed bean. Je voudrais savoir si c'est possible d'éviter de crée à chaque fois un nouveau bean lors de chaque rafraichissement de vue.

En effet, avec ma a configuration actuelle, lors de chaque rafraichissement de ma vue, on utilisant par exemple un F5, il y a création d'un nouveau managed bean. Or mon constructeur fait beaucoup choses et crée beaucoup de structures. Ce qui me cause une perte énorme en temps d'exécution.

Voila ma configuration

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<managed-bean>
        <description>
            Backing bean for order book monitoring
        </description>
        <managed-bean-name>orderBook</managed-bean-name>
        <managed-bean-class>
            com.ulnet.memberarea.web.OrderBook.OrderBookBean
        </managed-bean-class>
        <managed-bean-scope>
        	request
        </managed-bean-scope>
        <managed-property>
	       <property-name>renderManager</property-name>
	       <value>#{rmanager}</value>
	   	</managed-property>
    </managed-bean>

et voila mon web.xml

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
<?xml version="1.0"?>
 
<!DOCTYPE web-app PUBLIC
  "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
  "http://java.sun.com/dtd/web-app_2_3.dtd">
 
<web-app>
 
    <context-param>
        <param-name>com.icesoft.faces.debugDOMUpdate</param-name>
        <param-value>false</param-value>
    </context-param>
	<!-- This tells JSF to assume a prefix of jspx, which the Facelet's rendered can interpret. 
		Facelets can use many other parameters depending on your application -->
	<context-param>
	    <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
	    <param-value>.jspx</param-value>
  	</context-param>
 
	<!-- javax.faces.STATE_SAVING_METHOD identifies where the state of the
	 view is stored between requests. By default state is saved in the
	 servlet session. -->
    <context-param>
        <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
        <param-value>server</param-value>
        <description>
            State saving method: "client" or "server" (= default)
            See JSF Specification 2.5.2
        </description>
    </context-param>
 
    <!-- 
    To allow multiple windows for a single application, concurrent DOM 
    views must be enabled. 
     -->
    <context-param>
        <param-name>com.icesoft.faces.concurrentDOMViews</param-name>
        <param-value>true</param-value>
    </context-param>
    <!--
    To cause request scope to last only for the duration of a single user event, "standard request scope" must be enabled. This is set through the ICEfaces context parameter:
	com.icesoft.faces.standardRequestScope
    -->
    <!--
    <context-param>
		<param-name>com.icesoft.faces.standardRequestScope</param-name>
		<param-value>true</param-value>
	</context-param>
	-->
    <!-- 
    Synchronous or asynchronous updates can be turned off/on application-wide
    using the ICEfaces context parameter
     -->
    <context-param>
        <param-name>com.icesoft.faces.synchronousUpdate</param-name>
        <param-value>false</param-value>
    </context-param>
 
	<listener>
		<listener-class>com.icesoft.faces.util.event.servlet.ContextEventRepeater</listener-class>
	</listener>
	<!--  Added because a bug appear with Tomcat 5.5.20 -->
	 <listener>
	  <listener-class>
	   com.sun.faces.config.ConfigureListener
	  </listener-class>
	 </listener>
 
    <!-- Faces Servlet 
     The Faces Servlet (javax.faces.webapp.FacesServlet) is the standard JSF servlet.
     This is the servlet that manages the request-processing JSF lifecycle.
    -->
    <servlet>
        <servlet-name>Faces Servlet</servlet-name>
        <servlet-class>javax.faces.webapp.FacesServlet</servlet-class> 
        <load-on-startup>1</load-on-startup>
    </servlet>
 
	<!-- 
	The PersistentFacesServlet is our custom ICEfaces JSF Servlet (in other words, 
	our custom Faces Servlet that does the same request processing JSF lifecycle)
	 -->
    <servlet>
        <servlet-name>Persistent Faces Servlet</servlet-name>
      <!--   <servlet-class>com.icesoft.faces.webapp.xmlhttp.PersistentFacesServlet</servlet-class> -->
        <servlet-class>
        	com.ulnet.memberarea.web.Connection.MemberAreaFacesServlet
        </servlet-class>
        <load-on-startup> 1 </load-on-startup>
    </servlet>
	<!-- 
	For Ajax requests !!!
	 -->
    <servlet>
        <servlet-name>Blocking Servlet</servlet-name>
        <servlet-class>com.icesoft.faces.webapp.xmlhttp.BlockingServlet</servlet-class>
        <load-on-startup> 1 </load-on-startup>
    </servlet>
 
    <!-- extension mapping -->
    <servlet-mapping>
        <servlet-name>Faces Servlet</servlet-name>
        <url-pattern>*.jsf</url-pattern>
    </servlet-mapping>
 
    <servlet-mapping>
        <servlet-name>Persistent Faces Servlet</servlet-name>
        <url-pattern>*.jsf</url-pattern>
    </servlet-mapping>
 
    <servlet-mapping>
        <servlet-name>Persistent Faces Servlet</servlet-name>
        <url-pattern>*.iface</url-pattern>
    </servlet-mapping>
 
    <servlet-mapping>
        <servlet-name>Persistent Faces Servlet</servlet-name>
        <url-pattern>/xmlhttp/*</url-pattern>
    </servlet-mapping>
 
    <servlet-mapping>
        <servlet-name>Blocking Servlet</servlet-name>
        <url-pattern>/block/*</url-pattern>
    </servlet-mapping>
 
    <session-config>
      <session-timeout>700</session-timeout>
    </session-config>
 
    <!-- Welcome files -->
    <welcome-file-list>
        <welcome-file>index.jsf</welcome-file>
        <welcome-file>index.jsp</welcome-file>
        <welcome-file>index.html</welcome-file>
    </welcome-file-list>
 
</web-app>

Note : 'utilise Icefaces dans la couche web.

Toute proposition sera la bienvenue.

Merci

**romaintaz** · 03/07/2008, 08h34

C'est le principe du scope request

A chaque requête (y compris donc lors d'un F5), le bean est complètement recréé.
L'idéal, c'est d'utiliser 2 beans : un bean session, un bean request.
Le premier va conserver les informations plus ou moins "persistentes", qui n'ont pas besoin d'être rafraichies à chaque requête, ces dernières étant alors stockées dans le bean de scope request...

**Esil2008** · 03/07/2008, 09h57

Merci pour le reply
Au faite Icefaces permet d'éviter cela en déclarant le concurrent dom views à False.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
<context-param>
        <param-name>com.icesoft.faces.concurrentDOMViews</param-name>
        <param-value>false</param-value>
    </context-param>

Quand je fais ça, il y a pas de création de bean à chaque rafraichissement. Sauf que ça me cause un problème que je comprends pas. Quand j'essaye d'ouvrir une view avec un code JS (window.open), ça plante, il déclenche une exception.
J'ai ouvert un post concernant cette exception, mais j'ai eu aucun retour pour l'instant
http://www.developpez.net/forums/sho...d.php?t=579554

Merci

**djo.mos** · 04/07/2008, 03h43

Bonjour,
Ok, mais qu'est ce qui t'oblige à mettre ce bean en scope request ? Pourquoi pas le déclarer en scope session par exemple

?

**Esil2008** · 04/07/2008, 10h12

Bonjour djo.mos,
Premièrement dans la documentation Icefaces il préconise l'utilisation du scope request pour les applications web tel que la mienne.
Effectivement j'ai essayé d'utiliser le scope session pour résoudre mon problème, mais ça engendre plusieurs exceptions de concurrence incompréhensible dans le cas ou j'ai deux fenêtres ouvertes de la même application. Ce qui n'arrive absolument pas dans le cas de request. Sachant que toutes les méthodes gèrent les mécanismes de synchronisations de threads.
D'ailleurs c'est pour cette raison que j'ai du relire à nouveau la doc icefaces et c'est la où j'ai vu qu'il préconisait l'utilisation du scope request pour ce genre d'utilisation.

L'origine de mon post est la suivante.
J'ai un bouton qui permet d'ouvrir une fenêtre en plein écran. J'utilise un JS window.open pour cela.
Pour ne pas passer à chaque fois dans mon constructeur, je met le concurrentDomViews à False avec un scope request.
Sauf qu'avec cette configuration. Cette instruction cause une exception (j'ai un post qui parle de ça). J'ai remarqué que cette exception est déclenchée car le programme passe deux fois dans le constructeur du backing bean ...

Mais si je remet concurrentDomViews à True avec un scope request. La il y a pas de problème avec le window.open. Mais ça prend beaucoup de temps à chaque refresh, sachant que le rafraichissement est automatique grâce à un Renderer (Ajax...), donc pas besoin du F5. Et ce qui me gêne le plus ici, c'est si par exemple j'actualise mon appli avec un F5 un certain nombre de fois (plus de 4 fois de temps en temps). Mon appli se bloque ... sans aucune exception ni affichage, simplement le navigateur est entrain de se charger sans aucune réponse !

Toute proposition sera vraiment la bienvenue.
Merci bien

**gazanova** · 17/07/2008, 14h02

Les "scopes" standard (surtout "request" et "session") JSF ne sont vraiment pas adapté au cycle de vie des backing beans d'une appli web (!!).
Pas mal de framework proposent des solutions alternatives:
Richfaces propose un tag keepalive.
tomahawk, un tag savestate
Seam, un scope "conversation", etc...

Peut-etre que Icefaces a aussi une solution plus ou moins équivalente ?

G.

**Zerbull** · 18/07/2008, 08h08

un bean request par page et un bean session pour les données persistentes est la methode que j'ai retenue, on ne peut pas faire grand chose avec la portée request mais neanmoins nécéssaire et c'est dommage de s'en passer

**ouedmouss** · 20/07/2008, 15h21

En effet le scoope propose par icefaces n'est pas un scoop request (je crois qu'il parle de scoope conversationnel), qui conserve les données tant que ton navig n'est pas clos (apres en interne je supose qu'il foute ca en session).
donc méfiance

**wanchy** · 19/02/2010, 18h09

Bonjour à tous, je me permets de réouvrir ce post, car la discussion me plaisait bien et me semble un brin inachevé.

Car la question bean scope request ou session est intérésante.

Envoyé par Zerbull

un bean request par page et un bean session pour les données persistantes est la méthode que j'ai retenue, on ne peut pas faire grand chose avec la portée request mais néanmoins nécessaire et c'est dommage de s'en passer

Je partage assez cet avis de faire :
- un bean par page avec un scope request.
- un bean par objet métier avec un scope session

Après le plus dur est de bien supprimer du scope session les bean objet métier quand ils ne sont plus utile.

Et vous comment utilisez vous vos bean ?
Quand mettez vous en request ?
Quand mettez vous en session ?

Probléme avec le scope request

JSF Java

Discussions similaires

Partager

Partager