Reprise du message précédent :
hum, petite question Google Guice :  
 
J'ai l'impression que ce n'est pas possible de faire 2 instances d'une même class avec des injections de dépendances différentes.
 
Par exemple, sur Spring, j'aurais fais beanA et beanB, sur la même class, sans problème.
 
Mais avec Guice, j'ai l'impression d'être dans l'impossibilité de mettre 2 fois la même class dans l'injecteur.
 
Je suppose que c'est surtout parce que Guice est vraiment orienté injection et uniquement injection. (Mais peut être que j'ai loupé un truc dans la doc.)

Mots-clé : verifyerror, caca, "erreur de merde", prozac

Alors on a cette erreur sur une de nos deux machines de prod. On a déjà comparé les checksum des deux .class de la classe "Detail" et ce sont les mêmes.

A la ligne en question on fait Detail d = new Detail().

La signature de la méthode est public double getDetailMontant().

Même runtime sur les deux machines 1.6.0.29 ou truc dans le genre.

On a le probleme que sur cette classe autant qu'on le sache.

Des idées avant que l'on planifie un redéploiement ?

edit: ce sont des classes perso, y'a pas de lib en jeu ici.

 
[RTFM]
http://code.google.com/p/google-gu [...] s_of_objec
[/RTFM]

 
ce que je ferais d'abord c'est un check VisualVM/JConsole sur les 2 machines pour s'assurer que les runtimes et classpath sont identiques.
si c'est un appserver, est-ce que vous déployez avec du versioning d'app ?

On a vérifié ça avec un truc en ligne de commande, jinfo <pid du bootstrap> je crois... et c'est la meme chose modulo le nom de la machine.
Le serveur c'est jonas, quant au déploiement je sais pas, on a un prestataire externe qui s'en occupe donc je connais pas les détails. Pourquoi?

je l'avais bien vu, mais je n'ai pas réussi à faire ce que je voulais avec. Je vais réessayer du coup...

car avec le versioning tu pourrais avoir des déchets

Pourquoi le logo Java représente une tasse de café ? C'est parce qu'on a le temps de s'en prendre un à chaque chargement ou quoi ?
Bref, si vous avez l'info

wikipedia est cassé ?

edit: ah ben non : http://fr.wikipedia.org/wiki/Java_ [...] ngage_Java

Merci. J'ai également fait une recherche (mais après avoir posté ici )

rhôô... à quasi deux heures près tu pouvais glisser ton troll dans la bonne journée... c'est ballot.

Bon bah de toute façon la jvm a pété cette nuit, et après redémarrage c'est ok.

Bonjour,
Qqun pour m'aider avec on probleme de Log4J svp ?  
 
http://forum.hardware.fr/hfr/Progr [...] m#t2114257
 
 

dites les gens, j'ai des objets à partager entre plusieurs JVMs, je pensais à un cache distribué simple (pas de persistence nécessaire). Les JVMs sont de simple programmes, ce ne sont pas des AS.
 
Une idée de techno simple à implémenter dans les JVMs ? je pensais à EHCache mais en distribué c'est via Terracotta et mon souci c'est que cela nécessite une JVM supplémentaire apparemment.
 
Et je voudrais m'affranchir de toute DB...

Question con à propos de ce tuto :
 
http://viralpatel.net/blogs/2010/1 [...] ample.html
 
Le mec appelle son implémentation de DAO "ContactDAOImpl", mais dans l'esprit, ça devrait plutôt s'appeler "ContactDAOHibernate" ou un truc du style, non ?

oui

En DB c'est une pitié à gérer, personne pour un cache distribué ?

Tu peux aussi voir du coté  
- de cajo pour de la communication inter JVM
- de kilim pour du message passing haute performance
Sinon, c'est quoi le pb d'avoir une JVM supplémentaire ?

ça a l'air bien intéressant tout ça... je testerai ça dans les prochains jours.
j'ai l'impression que bien wrappé, kilim peut me suffire.

Ce n'est pas réellement un problème, c'est le côté Ops qui est embêtant car c'est une JVM de plus

• à monitorer (monitor JMX et monitor process),
• à intégrer dans notre menu opérateur,
• à intégrer dans le boot/shutdown/status dans notre système de boot global,
• créer les procédures stop/start/recovery,
• définir les niveaux d'alertes...

tout ça pour synchroniser dans le meilleurs des cas une 50aine d'objets entre 2 JVMs métier.

donc, si la soluce peut passer en s'intégrant dans le petit stack des JVMs métier, ça m'arrange car tous les points Ops sautent (si ce n'est un chapitre dans la doc de la JVM métier)

Je cherche un moyen de remonter dans jenkins des utilisations de types que l'ont considère comme prohibé dans notre appli.
 
Je pensais utiliser IllegalTypeCheck :
http://checkstyle.sourceforge.net/ [...] llegalType
 
J'active, je rajoute quelques classes dans la conf, ça tourne, mais:
 
- par défaut, les classes avec "Abstract" dans le nom remontent... Pour le moment ça m'interesse pas, je surcharge la regexp et c'est ok.
 
- si j'exclue une classe com.bidule.Truc mais que mon code utilise com.machin.Truc, il me pète une erreur aussi  
 
Du coup c'est inutilisable en l'état, un des objectifs étant de décourager l'emploi d'une classe homonyme d'une autre avant sa suppression.
 
Vous avez une solution? Dans pmd/checkstyle/findBugs si possible

ça se configure avec une regex ? T'es sure qu'elle est bonne ta regex ? (j'ai envie de dire que probablement elle ne l'est pas )
je viens de lire la doc, c'est un peu débile leur rationale pour exclure par defaut les "Abstract"... d'ailleurs comme beaucoup de choses dans Checkstyle, ça semble plus se baser sur de l'analyze textuelle que sur un AST...

Alors la regexp c'est optionnel, mais par défaut elle est à

^(.*[\\.])?Abstract.*$

ce qui me remonte des erreurs non souhaitées, donc je fous

^(.*[\\.])?Toto.*$ à la place parce que sonar me laisse pas mettre de vide et que d'ailleurs je sais pas comment il réagirait.

Pour les classes à exclure c'est une liste de types, et la conf semble accepter aussi bien "Vector" que "java.util.Vector" par exemple donc je supposais qu'il était plus fin qu'une simple analyse textuelle

Ah ptin
 

 
Il fout dans son set com.machin.Truc ET Truc quoiqu'il arrive. wtf?

Après je connais pas trop les ast et le principe de fonctionnement mais ca n'a pas l'air trop délirant?
http://www.docjar.com/html/api/com [...] .java.html

Bon évidemment, c'est signalé depuis 2007
 
http://sourceforge.net/tracker/ind [...] tid=397078

dites je débute avec maven et je coince sur une connerie lors de ma ligration ant->maven.

mon projet: src/main/java/pouet contient Pouet.java et pouet.xml

• avec ant, pouet.xml est bien packagé dans mon jar;
• avec maven, il ne l'est pas.

j'ai bien:

mais ce n'est pas suffisant.
j'ai tenté avec un assembly mais sans succès.

j'ai loupé qque chose, mais quoi ?
edit> c'est sans doute **/* des binaires compilés mais mon xml est dans les sources évidemment

normalement, les resources, c'est dans src/main/resources (mais pas dit que ça change grand chose)

est ce qu'il existe un outil permettant de gérer de nombreux fichiers pom, nottament les nombreuses dépendances etcetera ?
 
par exemple là je dois upgrader une lib de mon projet et changer son numéro de version, et doit le faire dans une vingtaine de fichiers pom

http://mojo.codehaus.org/versions-maven-plugin/

je vois pas l'intérêt de mettre un smiley comme ça sauf à tout faire pour ne recevoir aucun remerciement

si la dépendance est commune, il faut la mettre à un seul endroit, dans le pom parent. Si tu ne peux pas, tu défini une propertie pour la version que tu ne défini qu'à un seul endroit.

"ptet google un coup et sors toi les doigts du cul"

tu n'es pas indispensable au point de pouvoir te permettre d'être aussi déséagrable à chaque réponse
je préfère encore que tu gardes tes réponses et tes smileys pourris

 
je vais voir si ça pose problème avec le fait que sur ce projet c'est souvent ant qui parse des poms et autres trucs pas très catholiques
c'est nawak, faudrait faire du ménage

la properties il faut tout de même la mettre dans un pom parent non ?

edit : oui donc en effet c'est dans le pom parent, et si tous les projet ne dependent pas de cette lib ...

C'est peut-être déjà passé vu que c'est débarquement (novembre ), mais comme certains ici utilisent Play!
 
http://blog.typesafe.com/typesafe- [...] -framework
 
C'est plutôt une bonne nouvelle quant à la pérennité de la version Scala du framework, Typesafe étant fondée par le créateur du langage et de Akka.

C'est plutôt le contraire qui inquiète un peu (j'ai l'impression) : la pérennité de la version java
Dans play framework 2.0, les templates sont en scala. Bref, ça donne l'impression que scala va prendre de plus en plus de place & peut être pousser java un peu dehors.
 
 

 
Pour en avoir discuté avec Guillaume et Sadech, la version Java ne va pas partir de si tôt. Ils sont bien conscients que si Scala peut apporter des avntages pour les developpeurs expérimenté, ce n'est pas le cas du dev de base. Et ils comptent bien vendre du support, donc ils ont intérêt à avoir la plus grande base d'utilisateurs possible.

Qu'est-ce qui empêche que le framework soit codé en Scala, tant qu'il est utilisable sans problèmes et sans une interface bizarre depuis Java?

Bah rien. Le seul point qui est sensible, c'est justement l'interface depuis Java. Ils ont deux interface distinctes car l'approche Scala diffère pas mal de l'approche Java (notament au niveau de la partie ORM avec Anorm vs Ebean)