Reprise du message précédent :

Le but c'est d'enrichir les interface existantes (principalement celles des collections) sans casser toutes les implémentations existantes.
L'avantage, c'est que du coup, on introduit pour pas cher les mixin.
Le désavantage, c'est que si tu as un clash de signatures entre deux "default" de deux interfaces dont tu hérites, actuellement y a aucun moyen de savoir lequel sera utilisé.

Tu peux hériter que d'une abstract class, et ajouter des méthodes à une interface existante (genre Collection) pête tous les implémenteurs existants.

Le comportement logique serait de refuser de compiler et de demander une implémentation explicite (ou de déclarer que les interfaces sont incompatibles, parce-que je sais pas quelle serait la gueule du super() vu qu'il faut dire laquelle des (n) super méthodes appeler)

@tous ha bah wé d'accord

bé ouais, ça a tjs été le problem de l'héritage multiple, et une des raisons pour lesquelles "des gens" voulaient pas en entendre parler dans Java non ?

(si la raison pour laquelle ça se fait implementer c'est vraiment juste pour l'api collection, c'est un peu bancal quand meme…)

Héritage multiple  

 
Par exemple. Ou bien de définir un ordre de précédence en fonction de la déclaration des interfaces dans la définition de la classe (comme dans Fantom).  
Mais ca ne résoud pas le problème de la tonne de lib déjà existantes et précompilées. Je les vois mal dire au gens "laissez tomber maven & co", faut tout repackager des sources de chaque lib pour java 8".

Ça c'est super merdique à faire fonctionner correctement, parce que tous les niveaux doivent appeler super() correctement sinon ça forward pas à des classes qui n'ont aucun rapport, et la résolution de l'ordre d'appel n'est pas trivial et ne dépend pas uniquement de l'ordre de déclaration des interfaces (t'as aussi le problème des classes parents des defs). C'est un gros problème en Python, si t'as une hiérarchie en V (pas en diamant, qui pose d'autres problèmes) les branches du V qui ont des méthodes en conflit n'appellent pas super() et tu drop ta chaîne.

Refuser le cas (complètement) ou demander une implémentation explicite (qui va appeler les super-méthodes ou non) me semble bien plus sain, au final.

Question : on n'a jamais monitoré nos JVM. Et pouf, là comme on a plein de problème, on aimerait bien monitorer. on utilise bien jconsole mais ce c'est pas l'idéal sur le long terme .  
 
Vous utilisez quoi, chez vous ?

combien de JVMs ?

Du code custom... le principe est simple: se connecter sur le port JMX et pomper qques infos clés de MBean choisis.
Après, on gère les alertes (vers la console de production), les calendriers des disponibilités, on dessine des graphes, ... le tout avec une interface web très légère.

Grosso modo, on monitore la santé d'une JVM, les applications déployées (+enabled/disabled), la charge de notre serveur BPEL-like.

La prochaine version qui va arriver monitorera les connection pools, la charge et les retards MQ et les stats business et utiliser le framework Jolokia afin de dumper notre code de connexion/récolte custom.

Le but final est de visualiser notre architecture complète sous forme de graphe avec chaque élément monitoré visualisable

Volume actuel: 60+ JVMs dont 50 sont des appserveurs (WAS, GFish, Tomcat).

Mais bon, si tu veux monitorer simplement la santé des JVMs de manière standard, il y a des softs tout faits bien plus rapides à mettre en place (nagios par ex)  

Alors, ça dépend de l'environnement : DEV : 3 vms, integration : 7 vms, prod : un peu plus de 13 vms.  
 
Le truc un peu relou : ce ne sont que des serveurs windows. On peut installer ce qu'on veut que sur les serveurs de DEV. Et sur les autres environnement, ça sera très long pour que ça soit fait. (et ça ne sera surement pas fait, car l'outil de la boîte c'est hyperic, sauf que le client ne l'a pas configuré...). Par contre, les routes sont ouvertes dans tous les sens, donc rien ne m'empêche de monitorer un serveur d'INT à partir de la DEV (bon, par contre, la PROD, c'est plus mon problème, je n'en prend pas la responsabilité)
 
En regardant nagios, je suis tombé sur RHQ, un produit jBoss & comme on utilise des jboss AS, ça peut être plus facile à mettre en oeuvre.
 
 
Ton retour est intéressant, merci

pour ma part, je ne croise pas les environnements, j'ai donc 3 consoles: une dans chaque env.
 
il y a de bonnes idées apparemment dans RHQ

interessant !
 
Sinon y'a JavaMelody qui pourrait ptet interesser OP?

http://code.google.com/p/javamelod [...] _Jar_files
On ne peut monitorer que des webapps ?

Ha pardon, oui je crois. Et c'est moche en plus. Je pensais que ça aurait évolué depuis le temps...

pour le monitoring, il y a 2 écoles: ceux qui tapent la sonde active dans l'appserver et ceux qui la tape à l'extérieur.
 
il y a à boire et à manger dans les 2 cas, perso je préfère une sonde extérieure.
 
il y a aussi ça: http://www.jeeobserver.com/

Yo les 1337, j'ai un soucis avec le second level cache d'Hibernate (EHcache). Depuis quelques temps, lors de la première requête, j'ai le droit à une exception:

Caused by: java.lang.NoSuchMethodError: org.hibernate.cache.CacheException.<init>(Ljava/lang/ExceptionV
 at net.sf.ehcache.hibernate.SingletonEhCacheProvider.buildCache(SingletonEhCacheProvider.java:99)
 at org.hibernate.cache.impl.bridge.RegionFactoryCacheProviderBridge.buildEntityRegion(RegionFactoryCacheProviderBridge.java:104)
 at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:280)
 at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1872)
 at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:906)
 at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:57)
 at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:63)

Quelqu'un a une idée ? Hibernate Core 3.6.7 et EHcache 1.6.2)

vu le NoSuchMethodError, je dirais une différence de version d'API entre la compilation et le runtime... mais je suppose que tu y as déjà pensé.
(et tu me répondras sans doute que rien n'a changé entre avant et après ?)

Ouaip

J'ai l'impression que c'est un problème d'accès à la base avant qu'Hibernate/EHcache ait fini de s'initialiser. Si j'attends un peu avant le premier accès, je n'ai pas l'exception. Le soucis, c'est que je m'attendrais plutôt à ce que la requête déclenche l'initialisation, ou du moins soit repoussée jusqu'à ce que la phase d'init soit terminée.

Vu le code de ehcache, ( http://www.docjar.com/html/api/org [...] .java.html )pour moi tu as deux problèmes :  
 
- Un cache qui est en erreur
- la remonté de l'erreur qui ne se fait pas à cause du NoSuchMethodError
 
Ce que je ferais :  
Mettre un point d'arrêt dans ehcache pour avoir la vrai exception que lance ehcache  
 
Ou
 
Vérifier dans le classpath au runtime les versions d'hibernate. C'est vraiment étrange qu'il ne trouve pas une méthode qui pourtant existe depuis pas mal de version... (limite, je te décompilerais le jar d'hibernate pour vérifier le .class ou vérifier qu'il n'y a pas une class identique dans une autre dépendance...dès fois qu'un gros malin est voulu redéfinir la class)

C'est pas spécialement une question Java, mais vous versionnez les configs serveur d'application ?

Une appli tourne sous JBoss, on a besoin d'un minimum de configuration (datasources, logging, propriétés...). La solution simple serait de versionner uniquement les fichiers de conf qui diffèrent de la version initiale (le Jboss naked), mais versionner l'intégralité du serveur éviterait de mettre en place une procédure d'install (replacer le fichier youpi par celui du repo, etc...)

De ce que je vois, versioning d'un serveur d'application :
- lourdeur du repo (même si les diffs ne se feront que sur peu de fichiers) ;
+ le serveur en tant que module du projet, c'est garantir la création d'une config complète pour pas cher en tant qu'artéfact de ce module

Avis ?

Edit : question bonus => quelle structure de module Maven vous adopteriez dans le cas de tout le serveur en versioning ?

je ne versionne pas actuellement nos appserveurs mais les serveurs sont virtualisés et on les snapshote chaque nuit (procédure standard) par contre, ça ne versionne pas.
 
par contre, j'ai un diff totomatique (toutes les 5 minutes) du fichier de config de nos glassfish qui remonte une alerte warning en cas de modification détectée. Ainsi qu'un nightly diff entre notre CVS et le serveur de scripts afin de s'assurer que la moindre modification est bien versionnée.
 
nous avons pas mal de modifications d'architecture qui vont arriver et ces fichiers de config seront versionnés comme les scripts.
 
je ne suis pas fan de versionner des binaires mais au bout du compte pourquoi pas.
 
aucune idée pour maven par contre

Intéressant
 
J'avais aussi pensé à Puppet, que j'avais déjà utilisé pour du perso, mais c'est lourd à mettre en place et ça dépasse clairement le cadre de la fourniture.
 
C'est d'ailleurs le cas de ta solution, tu te portes garant de l'état de tes serveurs de prods via les les diffs et snapshot, mon idée est plus d'automatiser la production (dans le sens livrable, pas déployé).
 
A titre d'info, tu bosses dans quoi pour avoir ce type d'infrastructure à gérer (MP si tu préfères, tu peux aussi ignorer la question ) ?

MP.

 
Après le week-end, quelques autres avis sur cette question ?
Les réponses de TBone, bien qu'intéressantes et tout, ne sont pas applicables dans mon cas.
 

Ma précédente question ne vous a pas spécialement inspiré j'espère avoir plus de chance avec celle-la.
 
Quota :    
 
TL;DR : existe-t-il un moyen pour persister un champ statique dans une entité JPA ?
 
Exemple avec une entité Camion. Je souhaite que celle-ci dispose d'une méthode transient qui renvoi l'état d'un camion. Cette état est calculé en fonction des valeurs de champs de l'entité ainsi que celle d'un seuil appelé pouetPouet, constant pour toute les entités Camion mais que je souhaite paramétrable, d'où mon désir de le persister.
 
Un champ statique d'une entité n'est pas persisté, reste deux solutions :
1. Créer une entité wrapper pour ce seuil, ce qui m'embête un peu vu qu'il ne prendra qu'une valeur à un instant T.
2. Définir le seuil en tant que property de mon appli, c'est le cas actuel que je veux refactorer, puisqu'il m'oblige à calculer l'état dans mon entité à partir d'un appel 'extérieur' à celle-ci (en gros, je trouve que faire un System.getProperty() ou autre truc du genre dans une méthode d'un Entity est crado, mais c'est peut-être là la solution et là que je me trompe).
 
Idées ?

Y a un truc qui me chiffonne dans ton raisonnement. Je ne sais pas dans environnement business tu travailles, mais moi, dans la plupart des cas, si j'ai un paramètre configurable comme le tien, l'un des pré-requis essentiel est de toujours pouvoir savoir quel était sa valeur à l'instant T pour pouvoir revenir en arrière et prouver que les calculs effectués sont corrects. Donc, du coup, j'opterais pour unr variante de ta première option qui gare aussi un timestamp pou savoir quand la-dite valeur a été changée, et ainsi ne retourner que l'entité qui à le plus grand timestamp pour l'usage courant.

 
Bin voilà, ou comment me féliciter d'avoir posé la question ici...
Tu as complètement raison au sujet de la traçabilité des calculs, qui m'était passée au dessus pour ce paramètre (alors qu'on l'applique ailleurs). Ta solution proposée colle de plus parfaitement à ce qu'on veut faire.
 
Un gros merci

Yo les webeux, j'ai un big soucÿ sous GWT. L'appli ne fonctionne que sous Firefox, sous Chrome j'ai la plupart du temps une page blanche (et je n'arrive même pas à fermer l'onglet, le JS a l'air d'être parti en boucle infinie), de même que sous IE. Vendredi, la même appli tournait sous Chrome, mais je soupçonne qu'ellle tournait du fait que le JS était encore dans le cache. Après vidage du cache, la plupart du temps j'ai une page blanche, parfois (mais rarement) j'ai un peu plus que la page blanche, mais les données ne s'affichent pas.
Par quel bout prendre le débogage ? Ca urge de chez urge

idée conne : t'as ajouté Chrome en target de ton appli ?

euuuhhh, c'est p-ê pas si con, parce que je ne sais pas de quoi tu parles, là.
Juste une précision: jusqu'à peu, l'appli fonctionnait sous Chrome, mais comme les devs ne testent que sous FF, ils ne se sont pas aperçus de la perte de compatibilité.
Autre chose, lorsque j'essaye ede rafraichir la page, le curseur est en permanence en attente, comme s'il ne recevait pas de réponse du serveur, mais il n'y a pas de timeout. ON ne peut d'ailleurs pas fermer l'onglet.

 
Bon, donc, 2 solutions :
 
- les devs ont désactivé la compil sous Chrome pour accélerer les temps de compil en dev, et y'en a un qui a commité le fichier .gwt.xml avec le paramètre à la con. Pour savoir si c'est ça, il fauit vérifier que la permutation Chrome est présente ou pas.
 
Pour savoir : normalement, en GWT, on commence par charcher un fichier qui s'appelle "..../NomDuModuleGWT/NomDuModuleGWT.nocache.js
 
Ce fichier détermine la permut à charcger en fonction de la locale et du user-agent (entre autres). Ca lui donne un nom de fichier à la con (genre A2143253DC42E.cache.html), qui est ensuite chargé.
 
Donc, tu regardes dans la console Chrome, ce qui est chargé ou pas. Si tu trouves aucun fichier avec ce genre de nom, c'est qu'ils ont pas compilé pour Chrome, et y'en a un qui va se faire engueuler.
 
 
Seconde solution : il y a un problème de compatibilité avecChrome dans leur code. A moins qu'ils ne fassent des trucs très exotiques, c'est hautement improbable. Mais on ne sait jamais => console JavaScript, ça te donnera une indication. S'il y a une erreur, il faut qu'ils testent en DevMode sous Chrome. S'ils ne reproduisent pas, il faut compiler sans obfuscation (en mode pretty, tant qu'à faire), ça donnera une indication précise sur la méthode/classe Java dans laquelle ça pète.

revenir à une version précédente où ça marche & chopper le commit qui fait tout foirer ?

gfive> ok, je regarde, notamment un pb de CSS manquant, probt dû à un ui.xml foireux.
 
Je soupçonne pour le moment celui-ci, notamment autour du datePicker ou le calendar (les dernières modifs):
 

ah lutain, pas de bol : UIBinder, c'est justement un des bouts de GWT que j'ai jamais touché.
 
Bon, cela dit, y'a normalement rien de sorcier là dedans..
 
Le truc qui m'étonne, c'est le namespace de l'élément DateBox, à la limite : tous les autres ont "g", lui il a "dp".
 
Mais sinon, tu peux pas voir ce que tu as comme erreur dans la console JS de Chrome? (si tu as une erreur, evidement)

Pour ce qui est du namespace, c'est celui indiqué en ligne 4. Par contre, je ne savais pas qu'on devait définir la compatibilité avec tel ou tel navigateur. On n'a rien fait de spécifique la-dedans, du coup je pensais que par défaut, le code javascript généré par GWT était compatible avec tous.

En fait, le compilateur crache un ensemble de fichiers js par permutation (au minimum un par navigateur). Dans les fichiers de description de modules gwt (fichiers en .gwt.xml) tu peux spécifier les cibles de ta compilation. Par contre, les propriétés sont héritées : il suffit qu'un des modules dans l'arbre d'importation shunte la permut chrome pour qu'elle ne sorte pas.

TIL
http://java.net/projects/javaee-spec/pages/JEE

y a des combats à mener...

Ça aurait autant sa place dans Soft que prog, mais la 0day Java, vous avez du détail autre que les articles d'Ars ?
 
Vous faites quoi pour vos postes clients ?

https://issues.apache.org/jira/brow [...] l-tabpanel

Si j'ai bien suivi, ça ne concerne que Java WebStart en Java 7. En tout cas, vu le peu de sérieux avec lequel Oracle a traité la question, ça va accélérer la migration vers C# dans les DSI.