Reprise du message précédent :

 
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.

De ce qui est fait pour la majorité des systèmes web (au sens large) et du mode opératif le plus basique pour lequel le HTTP a été créé.

Là encore, ça a été discuté et abandonné au début des années 90.

Personnellement je parlais même (appliqué à un caddie) de ne pas stocker de caddie du tout sur le serveur, avec les avantages de ne pas avoir à s'emmerder à timeouter les caddies/sessions (et donc pas de problèmes liés à des AFK trop long) et l'avantage/inconvénient de forker les caddies, mais tu paies le prix en données transitant (et en complexité de génération des URLs, mais ça se gère avec un helper ou 2 donc c'est pas spécialement un problème) et si tu gères mal ton packing tu prend le risque de taper dans la limite de taille des URLs de certains navigateurs.

T'as aussi l'alternative de stocker tout le panier en cookie, mais t'es également limité en taille de données, tu perds le forking et tu risques des race conditions (je sais pas ce qui se passe si 2 pages modifient un cookie simultanément, mais je doute que ça soit joli)

Documentation des exceptions Java http://rymden.nu/exceptions.html

 
comment tu garantis l'intégrité des données qui transitent ? un des principe de base du web c'est que tu peux pas faire confiance au contenu qui vient du client...

Tu valides qu'elles sont cohérentes à l'arrivée, et tu ne fais transiter que des données que l'utilisateur t'a fournies (quelles autres?) par le mécanisme par lesquelles tu les fais transiter, si ton client décide que finalement il veut pas un vibromasseur vibrant canard rose avec haut-parleur il en veut 40, j'vois pas pourquoi tu refuserais

 
parce que t'en a que 39 en stock, qu'au delà de 10 les FDP sont offerts ce qui change le total de sa commande, etc...

Tu peux parfaitement l'indiquer au recap

et alors?

irrelevant.
 

ben en gros en fonction des règles métier que tu peux avoir, y'a des inputs clients qui sont pas valide...et en gros ça te force à revalider sans cesse, alors qu'avec un truc purement server side, le contenu du caddie est forcément clean, puisque tu l'as vérifié avant de le mettre dedans...

Il me semblait avoir vu un moment des docs de sun pour un garbage collector qui partait de l'idée d'un GC générationnel mais cassait l'assymétrie entre les pools (et se basait plutôt sur des stats de remplissage pour savoir lesquels copier dans lesquels), j'arrive plus à mettre la main dessus, ça dit quelque chose à quelqu'un ?

Wicket est stateful débrayable. Echo2 est aussi stateful (et la démo superbement rapide, au passage).
En fait, à partir du moment où tu mets des données transitoires en session ou en BD, ton appli est stateful, même si le framework web n'est pas lui-même à proprement parler stateful. Il faut voir un framework web pour ce qu'il est: un système permettant la création de pages dynamiques et leur enchainement. Le fait qu'il puisse ou non gérer des états est, - ou non -, un choix supplémentaire, sachant que cette gestion peut être faite de plusieurs manières différentes. Mais étant donné que la génération des pages dépend de ces états, il parait logique que cette gestion soit étroitement associée au framework.

La validation elle-même à chaque requête serait aussi lourde pour le serveur que la gestion des états.

une idée/un outil pour un petit cache clef/valeurs (chaine/xml) qui soit persistant entre les re-démarrage de tomcat. y'aura pas d'update des valeurs.

Je voudrais aussi con et simple que possible.

memcached?

heu non, pardon, manque de contexte : je vais chercher des docs sur un autres serveur, et je veux juste pas aller les chercher à chaque coup. donc je voudrais encore plus con si possible.

T'as d'autres infos? (fréquence des modifs des documents, âge max acceptable, toussa)?

jamais modifié le doc, age max : 100 ans. Je veux juste pas que à chaque requête d'un de mes clients je tape dans le serveur upstream.
 
c'est tout con.

Bah un truc genre rsync/wget --mirror en cron qui tourne toutes les xmn?

trop complexe. j'pense que je vais faire des fichiers sur le disque.

Ca fait quoi à part des fichiers sur le disque, rsync/wget

ça lance un processus externe et ça nécessite d'être installé partout où on veut l'utiliser ? bref, ça fait plus chier la maintenance/exploit que du 100% pure java.

boah, ehcache. Ca fait bcp plus que ce que tu veux, mais ça devrait pas etre un probleme non plus. (i.e l'api de base est assez simple)

 
 
quand je dépacke le war avec jar xfv monwar.war il me préserve pas les timestamps des fichiers. Il me les met tous à la date du dernier dépacketage. Alors que jar tfv monwar.war me renvoie des dates correctes

 
C'est pas géré que depuis java 6 ce truc ?

tu pourrais m'en dire plus stp ? j'arrive à faire parler google.

 
 
http://java.sun.com/javase/6/webno [...] ility.html
 

'tain mais qu'est-ce que j'utilise moi encore comme outil

Ca existe des librairies d'appenders custom pour log4j ? En gros je cherche une FileAppender qui pourrait gérer l'archivage des fichiers de log (en copiant sur un repertoire réseau par exemple)

 
Je ne sais pas si ca doit être le boulot de log4j. On fait plutôt ca avec des scripts de maintenance.
Mais sinon tu peux développer ton propre appender c'est simple à faire.

Exact, ce n'est pas à Log4J à prévoir cela...
 
Chez nous, un cron démarre peu après minuit pour archiver les logs ayant fait leur rotation sur la date.

j'ai un p'tit souci JDBC-ODBC... (JDK1.5)

<note préliminaire>
je sais que le bridge est à éviter mais l'existant (DB2/400, choix techniques à l'install,...) fait que l'on n'a pas le choix
</note préliminaire>

Ca marche nickel sous Windows, ça fouette grave sous Linux.

J'ai bien installé la couche ODBC sous Linux et la connexion fonctionne avec les utilitaires Linux (isql...).

En googlant un peu, il apparaîtrait que Sun n'aurait pas implémenté la couche Unix de son bridge, mais le post date de 2004...
Qq'un peut confirmer ?

Je bidouille un ptit truc avec du jdbc sur postgresql, c'est un site web avec des login/password, etc... J'ai une pk sur le login pour éviter les doublons, donc si quelqu'un tente de s'inscrire en double ça throw une SQLException.

Quand j'ai de telles erreurs du backend sql, comment être sur quand y'a une exception que c'est bien la faute à un violation de la pk et pas autre chose ?

Tout ce que j'ai à dispo c'est le message (et j'ai du mal à faire rentrer l'idée "parser le message" dans la case "traitement fiable" ), j'ai même pas la division SQLTransientException vs. SQLNonTransientException (et encore même avec ça c'est pas vraiment précis).

dans hibernate/mysql ça throw une ConstraintViolationException.
(donc après tu espère que c'est la bonne)
 
Mais globalement, c'est la merde de récupérer le nom de la contrainte violée.

questions métaphysiques du soir :  

• on dit souvent que c'est une mauvaise pratique d'avoir trop d'arguments dans un constructeur (les classes du JDK en ont rarement plus de 3). Que faire si ça a un sens métier d'avoir plus de 3 arguments, sans pour autant que les regrouper apporte une quelconque plus value ?

Par ex j'ai une entité "operation" qui encapsule un id (long) qui est l'id unique en base, un montant (double), une date (DateMidnight), une catégorie (un objet à moi), un nom, une description et un flag (boolean)
Je peux wrapper nom et description dans un objet pipo "label", mais j'en vois pas bien l'intéret...
 
ça fait un constructeur qui a une sale gueule, mais comment faire plus élégamment ?
 

• Je voudrais faire des "pretty printers", qui m'affichent une opération de différentes façon (Categorie - Montant, Nom - Montant, etc...). Quelle est la manière la plus propre de procéder ? J'imagine qu'il vaut mieux ne pas coupler une Operation à un Printer...je fais un Visitor ? un "static printer" avec une méthode à laquelle je passe une opération et un style de formattage et qui me le formatte ?

1) osef, t'as 7 arguments, c'est pas la mort; si à l'usage ça devient lourd, il sera temps de factoriser. A priori leurs types sont assez distincts pour que ça pose pas trop de probleme; sinon tu peux tjs de faire une petite factory/builder. Factory.newMachin(id, name).withAmount(montant).withDate(now).withCat(cat).build();
 

http://rwhansen.blogspot.com/2007/ [...] oshua.html

c pas mal en effet, couplé à une factory ça correspondrait bien à mon besoin...j'aime bien l'idée de l'ajout progressif des attributs, et la validation a posteriori que ça permet

merci

De ce que j'ai trouvé, ça se base sur une conversion explicite assez dégueu dans hibernate, et encore avec mysql ça passe parceque mysql fournit des types séparés selon les erreurs, ce que ne fait pas postgresql

Ça ressemblerait presque à de l'objet par prototype ce truc mine de rien

J'ai pas compris ta phrase, je ne suis qu'un décideur

Bonjour l'Elite...
 
J'ai un besoin particulier que j'aimerai résoudre via java mais je n'arrive pas à mettre la main sur la solution (si elle existe...).
 
J'aurai besoin de récupérer la taille (hauteur et largeur max) d'un visuel dans un PNG.
J'entends par là que le PNG carré possède un visuel noyé dans de la transparence. C'est la taille de ce visuel qui m'intéresse (visuel de toute forme).
 
Vous avez déjà vu ça? Une piste? un nom de méthode?

tu vas le chercher par le gradient du canal alpha ?

Ouep je me suis résigné à faire la méthode mais je me demande si c'est super optimisé    
 

tu peux le faire en une seule passe.