Reprise du message précédent :
Means OSEF ou epic win

Ca dépend de l'humeur.

"bien", quoi.

 
Damien ?

Du coup, on bave un peu devant SAF en attendant.

Euh non.

 
Et qui marche sur toutes les plate-formes, qui télécharge le truc à travers des proxys sans configuration, et qui fait le café pendant l'installation ?

sous windows, tu peux regarder dans la base de registre, mais ça dépend du logiciel, si il s'est inscrit dans le registre.
 
sous les autres système, tu peux tenter de lancer le soft (genre mvn -version)
 
Tu peux aussi tenter de regardé dans le path par défaut du logiciel et si ce n'est pas le cas, lui demander où qu'il est.

"ouxé qu'il est"
 
Sinon, lechewal, t'es obligé de passer par du Java, t'as pas un installer ? Souvent, les softs d'install font ça bien.

ça serait bien qu'il fasse le café pendant la phase de conf, de façon qu'il soit déjà coulé pendant la phase d'install.

si dans une collection je veux des elements de 2 types, 2 interfaces qui n'ont pas de parent commun, y'a pas une feinte, je suppose ?

Object? (mais c'est crade)

euh...tu peux toujours les taper dans une collection quelconque mais après pour aller les rechercher et invoquer une de leur méthode ça va être galère... (en naviguant dans les méthodes disponibles et en choisissant la bonne...)
 
tu as un exemple sous la main à nous soumettre je suppose ?

Tu précises pas ce que tu veut faire de ta collection, quelles garanties tu veut, et si t'es prêt à investir en coût à l'exécution (pour un type union je crains que tu ne puisse rien faire d'autre qu'une collection d'Objet si tu veut rien dépenser).

alors en l'occurence je veux une List<java.awt.image.BufferedImageOp OU monInterfacePlusSimple>
 
pour appliquer, vous l'aurez compris, des filtres en sequence sur une image. Au  moment d'appliquer les filtres, je fais une crasse genre instanceof. Ce que je veux c'est la garantie que je n'ai QUE ces 2 types la et rien d'autre.
 
Enfin bon, si y'a pas une astuce en collection c'est pas la mort, je peux wrapper, faut juste que j'expose une methode d'addition sur la collec qui va faire ça pour moi

 
J'aurais fait le wrapper aussi.
Sinon c'était un type générique Union<T1, T2>, qui fait à peut près l'effet d'un wrapper mais réutilisable contre-mais moins facile à comprendre.
Les bidouilles sur les collec' elle même ensuite trahiraient leur contrat et/ou serait impossible vu qu'on peut pas hériter 2x du même type avec des param différents

je suppose que tu as une bonne raison pour ne pas que les BufferedImageOp ne soient pas wrappées à ta sauce pour ne plus avoir à terme qu'une List<MyOwnImageOperation> ?

Quelqu'un utilise ou connait un autre plugin que celui-ci http://www.eclipsetotale.com/tomcatPlugin.html#A3 pour lancer Tomcat depuis Eclipse ? car chez moi il ne fonctionne pas du tout (malgré moulte configuration).

WST qui est dispo dans la distrib' J2EE ou dans les packages d'update

 
+1

Ah, nickel, merci

oui
 
 

bah alors, il te reste les instanceof il me semble  
(dans ton cas, ça va puisque tu n'as que 2 types possibles...)

ben les instance of me conviennent pour qd je vais iterer la liste et appliquer les filtres, mais ce que je voulais voir c'est si y'avait un truc pour déclarer ma collection de maniere plus safe que List<Object>

je crois que je protègerais cette List en créant un ImageOperationList et en surchageant les [add|put](T) pour thrower dès que tu veux [add|put] autre chose que T1 ou T2.

De ce fait, tu seras sûr lors des instanceof

non ?

l'autre solution, c'est de wrapper à l'insert.  
 
tu fais un objet qui wrappe une liste.
 un addImageOp(), un addMonInterfacePlusSimple() et un applyPipelineOn(targetBuffer)

ouais, un truc dans le genre. merci.

ouais, j'ai ça en tête aussi, mais le détail que j'ai oublié de préciser c'est que la collection est convertie par un bidule depuis un fichier de config (pour faire simple, parce qu'en vrai la config est dans le JCR)   donc ça gère les Collection standard quoi.. mais je peux fournir des adapteurs, donc y'aura de ça aussi....

   
Pour une fonction native jni y a des limitation au niveau du nb de parametres de la signature ?

 
FFFFFFFFFUUUUUUUUUUUU  

un probleme de conf de logging?

Moi je dois être le seul abruti qui comprend pas ce qui va pas

Ben il a du chercher un moment pourquoi son log4j faisait pas ce qu'il voulait.
Tout ca parceque sa librairie embarque un fichier de conf donc dans le classpath.
Enfin je suppose

OUAIS§§§
 
comment contourner le soucis pour que mon log4j à moi soit pris plutot que celui là ?

Tu prends la dernière version (0.9.8) qui n'a pas ce problème
Sinon tu édites le JAR en le renommant en .zip, tu vires le log4j.xml, tu rezippes et tu rerenommes en .jar
Sinon t'encaisses et t'arrêtes de faire chier les gens

changer l'ordre du classpath pourrait marcher aussi non ? ça doit prendre le 1er fichier log4j du classpath je suppose

Ouais mais y a des cas (genre dans WebSphere) où c'est bien casse-couilles de changer l'ordre du classpath. Enfin ouais, de toute façon, y a plusieurs possibilités, le tout c'est d'en trouver au moins une qui soit applicable dans son environnement de prod

Même pas sûr, cette semaine j'ai essayé de trouver un framework de validation (Hibernate Validator et OVal) qui ramène slf4j.
J'ai galéré pendant 2 heures parceque le ClassLoader chargait bien la facade de log4j mais ne chargait pas la bonne interface pour celui-ci.
La classe et son interface avaient le même nom quelque soit le package et ca a quand même produit un truc bizarre.
 
D'ailleurs, quelqu'un connait-il un bon framework de validation (autre que de modèle comme Hibernate Validator ) pour aussi valider les paramètres de méthodes et qui soit facilement intégrable à Spring?  
J'ai essayé Oval (avec la conf recommandée en tant que qu'interceptor) mais soit ca buggue au démarrage du contexte Spring pour cause de proxying de classe final déjà proxy, soit ca marche pas.    
Une autre piste?

   
 
Pour ma défense elle a tout juste un mois la version

Ah ouais, c'est actif comme projet