Reprise du message précédent :

 
Ce sont des postes entreprises, tous avec la même config' normalement. J'ai vérifié, et je ne trouve aucune saloperie de ce genre (de toute façon, ça détournerait aussi les connexions avec javaws 5 ou java).
 
De même, aucun firewall local.

Ou alors un truc qui appelle ou pas Socket::setSocketImplFactory, ou qu'il l'appelle en parallèle et est schedulé différement sur les quelques machines défaillantes (par ex si c'est les seules multicores ou l'inverse), soyons fous

Ce truc pourrait être javaws lui-même, qui ouvre effectivement des sockets pour télécharger les mises à jour des .jar...
Surtout que j'ai lu que ce téléchargement a été refondu dans javaws6, ce qui pourrait aussi expliquer la différence de comportement avec javaws5  

C'est une piste intéressante, je vais creuser dans cette direction.

Trouvé !

Plus qu'à trouver un rapport de bug qui explique ça, j'imagine que je ne suis pas le premier à tomber sur ce truc.
(sur les postes où ça marche, c'est bien en "détection des paramètres du navigateur" )

J'ai eu plusieurs fois ce type problème étrange, d'où ma proposition des de checker de ce côté.
Le meilleur dénominateur commun sur les postes incriminés était l'installation d'un second navigateur en plus de celui préconisé par la boite. Dans ce cas, les lectures de paramètre du navigateur sont vraiment hasardeuses (la notion du navigateur par défaut ne me semble pas prise en compte, et j'ai même l'impression qu'après avoir bidouillé là dessus, plus moyen de revenir à une config stable autrement qu'en connexion directe).

On a tous un navigateur en plus de celui de la boîte.
 
À partir de cet indice, devine quel est le navigateur de la boîte.
 
Ceci dit, ton retour d'expérience me rassure, je ne suis pas tout seul (même si je peine à trouver des infos à ce sujet sur le net)

Si ça intéresse qqn ici, j'ai 2 clé d'essai starcraft 2 (7h de jeu/ 14 jours après activation, selon ce qui se termine en 1er)
 
si ça motive personne, je les jette en pature sur le topic SC2

mauvais topic ?  

Pas forcément interessé à tout prix, mais bon à la limite pour tester ce jeu annoncé comme énorme (jamais joué au premier du nom, je suis plutôt Alerte rouge côté stratégie)

 
 
Grandement intéressé ici

 
  anéfé

Je m'excuse si c’est une question inappropriée pour ce topic mais j'ai un petit souci avec les Servlets dans la spécification JEE 6,je voudrais simplement savoir quand est ce qu’il est approprié de les utiliser ?  
J'ai cherché un peu partout sur le net mais je n’ai pas retrouvé de réponse à cette question,j'ai juste trouvé des tutos qui expliquent leur fonctionnement
Par exemple dans mon cas,je dois garder les réponses d'un client à mon questionnaire au cours de sa session et effectuer des traitement dessus,est ce que l’utilisation des Servlet est obligatoire ou est ce qu'un backing bean suffit?  
 
Merci.

Y'a pas qqun qui avait besoin de ça ici, y'a qques temps ? (à part moi)
http://code.google.com/p/jtype/

Tu m'as l'air de descendre trop bas pour ton utilisation. Les Servlets, c'est ce qu'il y a de plus bas pour manipuler des requêtes HTTP. A priori, tu ne devrais pas avoir à descendre plus bas que les JSP ou JSF. Et même, si tu crées un site avec plusieurs pages, plutôt utiliser un des nombreux frameworks web existants, comme par ex Stripes, Struts 2 ou Tapestry.

 
Merci,je m'en suis rendu compte trop tard j'ai utilisé les servlets pour récupérer les réponses du client.
C'est assez fastidieux mais je ne connaissais pas ces techniques.

Questions Maven + Intellij
 
1. Je package mon projet par le gestionnaire Maven d'Intellij (9.0.3) => encoding fucké (à l'affichage de mes frames par exemple)
Même opération par la console, pas de soucis. Mon pom contient bien  
 

<properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

 
WTF?
 
2. Je veux accéder aux rapports de test par l'IDE, sauf que le répertoire target est dans les Excluded folders. Je le retire de là, mais comme il est supprimé à chaque clean, il reprend son statut excluded. Je vois rien dans les settings pour corriger ça, ni rien dans la vue du run pour accéder directement au rapport.
 
3. Là, c'est peut-être une erreur d'approche, mais bêtement, je voudrais pouvoir débugguer aussi lors de la tâche test. Mes points d'arrêts ne sont pas pris en compte quand je lance un Debug "Mon projet [test]"
 
Merci d'avance
 
 
 

project.build.sourceEncoding ça serait un peu du maven-1 ça par hasard

 
Moui, j'ai du mal à trouver autre chose en fait. Je précise comment le jeu de caractère de mes sources ? Je spécifie juste l'encoding dans le maven-compiler-plugin ? Ou alors :
 

<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-resources-plugin</artifactId>
        <version>2.4.3</version>
        <configuration>
          ...
          <encoding>UTF-8</encoding>
          ...
        </configuration>
      </plugin>

 
?
 
Tant que t'es là, t'as pas une piste pour le reste    
 

<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-resources-plugin</artifactId>
        <version>2.4.3</version>
        <configuration>
          ...
          <encoding>UTF-8</encoding>
          ...
        </configuration>
      </plugin>

maven compiler, c'est pour l'encoding des sources
maven resources, c'est pour l'encoding des ressources.

Ça m'étais venu à l'idée.
Ce que je me demande, c'est si y'a pas un truc pour spécifier que c'est de l'UTF-8 partout (comme - l'ancien - project.build.sourceEncoding), plutôt que d'avoir une granularité au plugin.
 
Bien, ça nous laisse que deux questions ouvertes ça

<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-resources-plugin</artifactId>
        <version>2.4.3</version>
        <configuration>
          ...
          <encoding>UTF-8</encoding>
          ...
        </configuration>
      </plugin>

ha bah t'as ptet raison avec cette propriété:
http://docs.codehaus.org/display/M [...] e+Encoding
 
pour le dossier target qui est en ignore, jpense t'as pas trop le choix; tu pourrais au pire disabled l'import-du-project-maven-automatique, si t'as énablé ça, mais moi j'aime bien ...
 
pour le debug des tests, je sais pas, chez moi ça marche; t'as importé/ouvert ton projet comment ? Moi depuis idea 8 ou 9, je fais que ça:
 
open -b com.jetbrains.intellij pom.xml
(enfin j'ai un script dans ~/bin qui fait "open -b com.jetbrains.intellij $1" )
.. et open foobar.ipr une fois que le projet a été ouvert/importé une premiere fois depuis le pom

J'y vais au clickodrome : Open project, et je sélectionne le pom.
Par contre, dans mon .iml, j'ai bien <module org.jetbrains.idea.maven.project.MavenProjectsManager.isMavenModule="true" type="JAVA_MODULE" version="4">

Edit : et ça t'embête pas de devoir utiliser le filesystem pour consulter les test reports plutôt que rester dans l'IDE ?

oui et non, je lance mes tests depuis l'ide, sans passer par maven, dans ce cas...
HAAA mais c'est dans ce cas la que tu peux pas debugger ?

Oui
 
Pas de soucis quand je fais un debug "classique" dans l'IDE. Par contre, quand dans ce même IDE je lance le goal "test" en mode debug, j'ai pas d'arrêt au breakpoints. C'est peut-être normal, mais le comportement m'a intrigué.
 
D'accord pour le lancement des tests dans l'IDE nativement (donc pas besoin des test reports maven), d'accord pour le mode debug dans le cadre d'une exécution normale , mais le comportement m'a surpris, je pensais l'intégration plus poussée.

jamais essayé en fait; je suppute qu'il faudrait ptet tripatouiller les settings de la vm forkée pour pouvoir s'y connecter en debug (cfr les ecrans de config maven>runner)

Oui mais dans ce cas, c'est une nouvelle run/debug configuration custom à créer avec les bons paramètres de VM, qu'on appellerais en fesant un run... Pas logique, pas le comportement attendu quand j'ai un "debug" dispo dans le menu contextuel.
 
Pas bien grave hein, je m'en passerais.
 
merci de tes réponses

nan mais va voir settings>maven>runner, t'es des settings pour la vm forkée... cela dit, oui, je sais pas pourquoi t'aurais a faire ça à la main.. t'as regardé dans leur issue tracker voir si c'était un probleme connu ?

Question simple.
Dans une déclaration d'applet d'une page html.
Qui récupère l'archive jar de l'applet (attribut archive="truc.jar" du tag applet) ?
Le navigateur, ou un classloader de la JVM ?

Je dirais le navigateur et après évidemment la JVM prend le relais pour l'exécution.

 
OK, j'ai jeté un œil, on a cette approche (l'argumentation contre cette pratique est pas déconnante) : http://devnet.jetbrains.net/message/5253622
Et la configuration en question http://maven.apache.org/plugins/ma [...] gging.html
 
Pour le coup, j'aurais eu tendance à taper sur Intellij avant de regarer dans al conf Maven...
 
 
 

Une conversation effleurée sur bla²@prog (avec avis donné de nraynaud, mais succin et pas forcément limpide pour moi), certainement déjà abordée ici mais pas trouvé par la recherche : gestion des erreurs par une librairie, best practices et vie en société.
 
Ma lib lève des exceptions, je :
- throws jusqu'au programme consommateur (et si oui, j'encapsule dans un MaLibException ?) ?
- loggue (et donc ma lib a des dépendances à cet usage) et la méthode de traitement renvoie false / un NullObject / whatever ?
- autre chose / autre cas de figure important sur le sujet que juste la gestion des exceptions ?
 
A propos de mon premier tiret, dans le cas d'une lib qui ne connait pas encore les exceptions levées par son traitement (chaînage de libs par exemple), j'encapsule dans MaLibException, je throws Exception ?

C'est simple, en concevant ta lib, la première question à te poser est comment tu veux qu'elle soit utilisée, et ce que tes clients vont vouloir faire avec. Le test driven development est tout indiqué, cela t'aidera à définir tes interfaces. Est-ce que les choses simples sont faciles ? Est-ce que les choses compliquées sont possibles ? Sachant que si tes tests nécessitent 50 lignes de code pour appeler ta lib, il y a de fortes chances que les clients nécessiteront au moins ces 50 lignes à chaque fois qu'ils l'appelleront: ça sera une expérience désagréable.
Pour ce qui est des exceptions, je suis pour créer une série d'exceptions métier liées à ta lib.
Pour ce qui est de logger, je ne suis pas sûr qu'il y ait de réponse définitive. Je préfère une lib fiable et bien testée à une lib qui logge tout ce qu'elle fait, laissant au client le soin de logger. Maintenant, il y a des cas où sans log, c'est quasi impossible de comprendre ce qui se passe, notamment lorsqu'il y a des événements asynchrones (passage de messages entre threads par ex). Dans ce cas laisser la possiblité de logger peut être une bonne idée.

tldr; ça dépend.

Pour les tests, on est d'accord, même si c'est pas trop la question.
 
Au sujet des exceptions sur le wrapping en exceptions custom, je pensais me faire descendre en flammes, je suis étonné que tu proposes ça elmuch. Mais à ce détail près, on propage donc quoi qu'il arrive jusqu'au consommateur final.

euh y'a du pro de config de tomcat dans le coin? J'ai pas regardé en fait, ça doit être con, mais dans mes logs j'ai des catalina.2010-08-06.log catalina.2010-08-05.log etc, ce qui semble indiqué qu'il rolle, mais j'ai aussi catalina.out qui fait 2.2GB avec des logs qui datent de juillet. wtf ?

il fait une copie qui rolle pas j'ai l'impression, j'ai remarqué le même truc

C'est vendredi, problème à la con, forcement ( )
 
J'ai un daemon  qui se lance via un main dans eclipse qui marche.
Le même daemon, en ligne de commande, lancé via Java Service Wrapper de Tanouki ne se lance pas. En lançant le debug, le truc se lance et puis rien. Il ne s'arrête pas, il fait un truc, mais quoi, on ne sait pas. On mets en pause le thread, il ne se passe rien. Bref, il est perdu dans les limbes  
   
 
En regardant le code où ça part en cacahouète, il y a un singleton qui fait un jolie MaClass.getInstance().
 
En regardant u peu se que déclenche ce getInstance, on a des champs (static) initialisé par d'autre singleton.

public class FakeClass {
     static AutreSingleton singleton =  AutreSingleton.getInstance();
 
}

 
ou bien encore qui charge carrément des contexts spring

public class FakeClassBis {
    static ApplicationContext context = new ClassPathApplicationContext(...);
}

   
 
Une idée sur comment trouvé le pourquoi du comment de la mise en abime ? En mettant un point d'arrêt sur tous les getInstance de l'appli ?

je reviens dans 5 minutes, je crois que j'ai pigé, je teste juste un truc.
J'ai pas remarqué sur mes autres apps, donc je commençais a soupçonner Hudson, mais c'est ptet juste parce qu'il logge *beaucoup* que je l'ai vu ...
(2gb en 1 mois )

ok, conf/logging.properties
avant:

 
apres:
 

 
Donc comme je le dis gentiment dans mon comment, il semble que le fait qu'un ConsoleHandler soit configuré suffise pour capture stdout/stderr (j'imagine que la constructions de ConsoleHandler demarre la capture?); donc je le vire de .handlers (root handler=là ou vont les logs s'ils ont pas un handler specifique à leur categorie)
Et donc resultat: logs -> logs/catalina.TIMESTAMP
stdout/stderr -> logs/catalina.out

Utilisateurs d'Hudson, levez la main s'il vous plait.