Reprise du message précédent :
tu as mis une @Service sur ton implémentation?

oui @Service("lolService" )
(avec une minuscule)
 
Comme je suis pas autonome sur Spring je copie ce que je trouve dans le reste du code

je suis dispo la semaine prochaine si tu veux

cool, je te conseille le début de semaine

et t'as aussi mis la conf dans ton xml de contexte?
dans nos projets on a des trucs comme ca:

j'arrive pas à trouver tous les .xml de spring (je suis sur un bloat), mais si je type ma variable par l'interface, ça marche, c'est si je la type par l'implé directement que ça passe pas.
 
Et la remarque de moinsmoins est pertinente, même si c'est pas un test U, c'est quand même l'implé le sujet principal du test. Il serait normal de pouvoir typer directement la variable par l'implémentation.

Spring ne fonctionne qu'avec les interfaces si je me trompe pas. Du coup ce que tu pourrais faire, c'est déclarer tes 2 implémentations et utiliser @Qualifier("lolServiceMock" ) au bon endroit.

J'ai laissé tomber, merci pour le temps et les conseils.

http://www.theserverside.com/tt/ar [...] =Stripes15
 
quand meme...qqn avait posté ça il me semble, mais Stripes a vraiment l'air pas mal

 ça résout quoi comme problème ?

je suis pas sur de comprendre ta question ?
 
ça simplifie le dev web java par rapport à du servlet/JSP pur, et c'est super simple à mettre en oeuvre je trouve
 
c'est clair, tu lis le code facilement, tout est dans le code, et ça suit bien la logique request/response
si tu viens de Struts tu l'apprend en 3 minutes
 
tu utilises quoi personnelement comme framework ? Tapestry, Wicket,  Struts2 ?

Moi en 2007

Enfin pas spécialement ça précisément, mais mentionné Stripes

Le problème des frameworks java qui puent du fion, principalement

Nray il a une grosse bite et un gros couteau, il y va à coup de servlet+jsp

truc de ouf

ah ?

nan, j'ai une tonne de merdier, et justement j'arrive pas à alléger (virer Spring, virer soit le filter soit la servlet, mais les 2 ça fait beaucoup)

Bah ouais, il pue vachement moins que le reste (bon il pue quand même, faut pas se faire d'illusion, ça reste un framework web en java ce qui fait 3 points négatifs, il part pas exactement bien)

C'est pas paske tu utilises spring que t'y vas pas à coup de servlet+jsp Tu utilises pas Spring MVC si?

ouais, y'a du JSP, j'crois que la servlet c'est pas la mienne mais celle de Struts2.

ben en gros ça a l'air de faire ce que font les autres, mais de manière vachement plus légère...
 
ça pourrait remplacer Struts2 dans ton truc

Débarquement en quelle taille ?
C'est le meilleur framework MVC basé sur la techno des servlets/JSP (que je connais).

j'avais implicitement admis le débarquement
 
et oui c'est bon Stripes

fixed

De toute façon, les servlets, c'est moche, et les frameworks en Java ne font que broder autour.

pourquoi c'est moche ?
 
ce qui est moche de manière générale c'est qu'on cherche à faire faire à un protocole (HTTP) ce pour quoi il n'a jamais été prévu...

Le seul truc pour lequel il n'a pas été fait, à la limite, ce sont les échances stateful (ce qui rend de systèmes comme Seaside pas toujours très stables/sûrs). Et les servlet, à part si tu utilises le management de sessions, ne sort pas du cadre.

cite moi une appli web un minimum utile qui se serve pas du mécanisme de session ?
 
HTTP est un protocole stateless, or on en fait un usage stateful : c'est du bricolage
après c'est plus ou moins élégant, plus ou moins bien planqué, mais ça reste l'idée de planter un clou avec un tournevis : c'est possible, mais c'est pas fait pour

et aussi c'est un protocole déconnecté (y'a un gros lien avec stateless) et il fait chier pour les messages courts.

d'ailleurs vous qui devez probablement suivre ça de plus près que moi : y'a des discussions pour un http 2.0 ou autre, avec un mode stateful natif, ou devant l'existant tlm prend peur et rien ne bouge ?

 
HTTP est stateless, un HTTP stateful c'est pas du HTTP

C'est pour ça que c'est moche (enfin, je dirais qu'on en fait un usage batard entre le stateless et le statefull avec les sessions et les cookies). Ceci étant dit, c'est un mal nécessaire pour que ce soit fiable et scalable (parce que comme le rappelle raynal: déconnecté). C'est ce qui fait toute la complexité des applis web, et les frameworks permettent de rationnaliser le code.

 
je parlais d'un successeur éventuel...si tu veux pas qu'il s'appelle http soit, je demandais si il existait une étude sur un protocole succédant à HTTP et qui serait stateful

Un successeur, c'est censé remplacer et améliorer son prédécesseur. Utiliser un protocole stateful pour le web aurait surtout l'avantage de flinguer tout le truc et de brûler les serveurs (en plus de les rendre beaucoup plus compliqués à implémenter côté soft), et de perdre les avantages non négligeables de garder les états sur le client uniquement.

Si t'as besoin d'un protocole stateful, utilises un protocole stateful

Pas à ma connaissance, il y a eu des discussions sur le sujet à la création du protocole, mais je n'ai pas vu de discussions sur le remplacement de HTTP par un protocole stateful. Uniquement des discussions d'implémentations de systèmes stateful par dessus un protocole stateless (là encore, cf Seaside)

 
heu, et où tu maintiens l'état sur le client ? tu parles du sessionID ou des cookies ?
parce que quand meme le gros de la session est géré coté serveur :  
- contenu de la session
- lifecycle de la session
 
et c'est déjà la merde à gérer coté server

Ni l'un ni l'autre.

Implicit questions : you fail at them
 
et tu parlais de quoi donc ???

Tu ballades tout ce dont le serveur à besoin dans tes requêtes, en query dans l'URL ou en params dans tes forms.

c'est en partie vrai...
 
prenons un exemple de session archi-classique : le caddie...si tu rajoutes le dernier CD de Sigur Ros, et que tu vas dans une autre section du site, y'a queu dalle à propos du CD qui va transiter dans tes requetes...
pourtant il est bien qq part, et il est lié à TA visite en particulier...
 
la session, elle vit server-side only, la seule qui soit lié à la session qui se balade, c'est l'identifiant de session

tu le fais exprès? T'as décidé d'invoquer l'esprit de magicbuzz parce qu'il te manque?

attends, on va résumer :  
- on dit que les framwork web c'est pas top
- j'estime que c'est du au fait qu'on cherche à faire du stateful sur un protocole qui n'est pas prévu pour
- j'émets aussi l'idée que ce serait bien d'avoir un protocole stateful et je demande si y'a des travaux en ce sens
- tu réponds que ce serait le bordel, parce que ça "brulerait" les serveurs (ton propre terme)
- je te réponds que c'est déjà le cas, principalement à cause du sessions management
- tu pars sur un trip sur l'état du client, qui est géré par le client
- je te répond que c'est marginal par rapport à la gestion de la session et de ce qu'elle contient.
 
Bilan : y'a déjà une charge coté serveur pour gérer du pseudo stateful, et je vois pas en quoi avoir un protocole expressément stateful allourdirait le bousin plus que ça...
 
mais bon, le Grand Masklinn a décidé que non, alors tout le monde doit fermer sa gueule
 
c'est sympa de "discuter" avec toi sinon

C'est vrai que quand tu réécris toute la fin parce que la réalité te va pas, ça simplifie le truc

Sauf que la manière dont ça s'est fini c'est

• Tu demandes comment gérer l'état sur le client, en proposant les sessions et les cookies
• Je te dis que je ne parle ni de l'un ni de l'autre
• Tu réponds qu'il y avait une question et que tu veux savoir ce que je propose
• Je te répond que je parle de balader tout l'état dans les requêtes, donc d'avoir 0 état stocké sur le serveur (à propos de la communication avec cet utilisateur donné)
• Tu repars sur les sessions, alors que ce n'est clairement et explicitement pas ce dont je parle

Quand à un protocole stateful (et connecté), ça impose de maintenir une (ou plusieurs) connection(s) permanentes avec la gestion de session correspondante, ça complexifie (ou rend impossible) la gestion de connections multiples simultanées à un site donné depuis un client unique, ça dégage à peu près complètement les caches transparents, ...

Hum, i'm lost : quand tu parles de balader l'état dans les requetes, tu parles de ce que tu aimerais que ça fasse hypothétiquement si on pouvait changer les choses, ou de ce que ça fait ?
 
parce que là maintenant en 2009, la plus grosse partie de la gestion d'état, c'est le serveur qui la gère via les sessions...et si t'as déjà bossé sur un site à fort traffic, entre ça et les caches, ce sont pas des problématiques triviales à gérer.
 
pour le protocole stateful, c'est vrai que ça impose une gestion du keep alive, et que ça a des inconvénients...
un truc bien ce serait que le stateful soit possible sans etre obligatoire, un truc géré coté serveur où le serveur dirait : attention, pour cette requete, on va rentrer en mode stateful
 
m'enfin bon, le poids de l'existant étant ce qu'il est, ça changera probablement jamais

 
Si le serveur stocke des paires session . objet-caddie, et que l'objet-caddie est modifié par des requètes, oui tu as du stateful (et c'est effectivement ce qui se pratique actuellement la plupart du temps).
 
Si par contre le serveur stocke des paire id-caddie . objet-caddie, que les objet-caddie sont immutable, et que les liens /add et /del provoquent la génération d'un nouvel id-caddie associé à un nouvel objet-caddie différent du premier, là par contre tu as un caddie stateless. (tu peut faire back et revoir ton ancien caddie, tu peut ouvrir des onglets et forker complètement en 2 caddies ta navigation ça fonctionnera très bien sans flinguer ta session).
 
 
Par contre j'ai pas capté pourquoi la tendance à faire du stateful on http crée des framework web qui te plaisent pas.