Reprise du message précédent :
Sur un Tomcat 6 tout frais, je viens de tester l'exemple Waffle Negotiate sans aucune conf, ça fonctionne

J'imagine que sur mes essais précédents, j'ai du mettre le brin quelque part avec les 42 autres méthodes utilisées, mais là ça le fait.

Pour le moment, le même essai sur un JBoss me renvoi une 403, donc je continue. En tout cas sur le principe, ça fonctionne enfin.

Edit : context.xml passe de META-INF à WEB-INF

/run-everywhere

Puisque t'es là, que t'as été chou et que je galère (encore)...
 
Récupérer le user principal (nom de session windows) d'un utilisateur qui se connecte    
Se connecter à LDAP (AD)    
Le faire sans utiliser de credentials en dur    
 
L'idée c'est qu'LDAP ici est utilisé pour récupérer des infos sur l'utilisateur connecté, en aucun cas couplé à l'authentification. Du coup, pour me (l'application) connecter à l'AD, j'ai deux solutions :
- utiliser des credentials en dur (les nôtres, ceux d'un compte local à la machine...) => c'est moche ;
- utiliser le compte de l'utilisateur Kerberos authentifié => je sais pas comment faire ;
- utiliser le compte système local puisque la machine qui héberge l'appli est enregistrée sur l'AD => je sais pas comment faire.
 
Si t'as des pistes sur les deux "je sais pas comment faire", je prend, parce que mes recherches donnent absolument rien...

Alors je sais pas si ça peut aider ; j'avais joué aussi avec ce genre de connerie dans une appli JEE (mais aussi standalone POJO tant qu'à faire) y a plus de 2 ans et j'y ai pas retouché (et j'ai pas accès au source). En cherchant rapidement sur des mots-clés de l'époque ("spn credentials java" ), chu tombé sur ce sujet : http://forums.dzone.com/java/1623- [...] ction.html
 
J'imagine que t'as déjà testé les réponses suggérées mais sait-on jamais.

Malheureusement oui, toutes les solutions SPNEGO données sur le thread me collent à un moment donné devant le même problème : le besoin d'un keytab en local, lié à la déclaration d'un SPN pour mon serveur / appli sur l'AD. Et pour le moment, toute intervention extérieure est proscrite (d'autant que c'est pas nécessaire avec les technos MS).

j'ai jamais touché a l'ad perso (uniquement openldap/opendirectory), et il me semble avoir compris que (par defaut?) c'est configuré de sorte que tu dois t'y connecter avec un compte admin … prtt.

Le compte admin est pas nécessaire en lecture (n'importe qui qui a une session sur le réseau peut requêter, moi y compris), par contre la lecture en guest / anonyme est désactivée

… d'ou la connexion avec un compte admin pour récupérer les "détails" du compte du user courant ?

Lapin...
 
Le user courant de l'appli (appelons-le USER), je récupère pas ses credentials entiers, juste le username dont je sais qu'il est sûr puisqu'il est passé par Kerberos. Donc lui, sauf utilisation de sa session Kerberos pour taper dans le LDAP (je ne sais pas si c'est possible ni comment), je ne peux pas utiliser ses credentials pour chercher son détail.  
 
Donc pour obtenir les détails de USER à partir de l'appli, je me connecte au LDAP avec mes credentials (appelons-les DEV), en dur dans l'appli, ça me plait pas (mais ça marche). DEV n'est pas admin du LDAP / AD, mais c'est suffisant pour la lecture d'info sur USER.
 
Ce que j'aimerais : chaque requête de recherche d'info se connecte au LDAP avec :
- soit les credentials USER, que je n'ai pas (voir plus haut) ;
- soit les credentials système de la machine qui héberge l'appli (appelons-les APPLI, même si mon pâté est terminé) puisqu'elle est sur l'AD, et c'est là que je bloque.

j'ai enfin trouvé comment faire pour changer ce putain de context root, afin que maven prenne pas par défaut le nom du projet

Vous traduisez comment undeploy en francais?

Déposer, désinstaller ? Je privilégierais le premier.

 
dédéployer

supprimer le composant du serveur ?

 
ployer

en fait ployer ça veut dire empaqueter, ranger, mais là on vire le truc en fait

oh my

Y'en a qui ont essayé TomEE ou TomEE+ en remplacement d'un JBoss, Glassfish, Websphere ou autre ? Des retours sur facilité de configuration / déploiement / comportement à la charge ?

non, mais j'aime bien l'approche

 
 
 
je trouve ça un peu tout laid, pas vous ?
 
en fait je trouve dommage de faire des if, et des classes anonymes juste pour s'économiser la création de classes séparées, alors que ça aide pas la lisibilité du code
On a certes tout le code sous les yeux, mais on a quinze levels de code, c'est du code pas modulaire, et c'est vraiment pas très lisible
 
d'ailleurs dans cet exemple il suffit de définir une seule commande commune, car les component on la même interface
 

 
du coup le if tout dégueux fait sur un label text   ,  il y en a plus besoin    
 
le problème c'est que le tutoriels font la méthodes dégueux avec aussi peu de lignes et de classes possibles, et forcément les gens codent comme ça dans les applis

Une question des plus intéressantes sur le topic classpath
 
A vot' bon coeur.

je dois remplir un bean avec un fichier excell

plutot que faire des

setMaProperties if colonne equals "la bonne collone execell"

je me disais que ça pourrait être sympa de faire un mapping direct avec la properties du bean

donc je pensais aux annotations
créer une annotion @ExcellColumn par exemple, à la façon des annotations hibernate

le point négatif c'est que ça fait un binding un peu violent pour des noms de colonnes qui pourraient être amenés à changer plus facilement qu'une colonne en base

donc je me demandais si il y avait un outil spring quelconque permettant de faire ça facilement

bon j'ai réussit avec les annotations
 

 
en fait ça me gène à moitié de mettre ces annotations sur le bean utilisé par hibernate
 
pour faire plus propre j'aurais tendance à faire un dto, même si je trouve ça un peu con, vu qu'ils seront identiques

Euh c'est moi ou elle ne sert foutrement a rien ton annotation ? Tu appelles ta méthode statique en lui passant le nom de la colonne à mapper? Tu fais un 1:1 entre nom de colonne et bean property, ou bien l'annotation sert à donner le nom de la colonne correspondant à la property annotée, mais la je vois pas ce que tu fais.

Et va falloir te décider sur l'orthographe d'excel, mais hint: ce n'est ni excell ni  

Le fichier aixailles est chargé dans un tableau.
La méthode est appellé par deux for imbriqués.
Le premier for parcours les lignes, et le deuxieme les colonnes.
le paramètre colonne est le nom de la colonne du fichier excell, et le parmetre value, la valeur de la cellule.
 
l'annotation sert à savoir quelle colonne exell correspond à quelle propertie de entity il faut setter

Excel avec un c et un l, please

dites, c'est vrai ca:
 

 
je croyais que le compilateur était suffisamment malin pour gérer ce genre de cas... me trompe-je?

Ben le problème, c'est que "size()" peut avoir des effets de bord. Si le compilateur tente d'optimiser ça, il risque de modifier le comportement du programme.

La question est devenue plus précise (et vachement intéressante   ), donc topic séparé : http://forum.hardware.fr/hfr/Progr [...] 6363_1.htm

yes je vois le principe... mais dans l'absolu, si tu itères sur un tableau par exemple, algorithmiquement dans la plupart des cas c'est que le tableau (ou en tout cas sa taille) ne va pas bouger, si?

 
Oui, on est d'accord là-dessus, mais ça implique de savoir que "size()" va juste retourner la taille de ton tableau, et ne va rien faire d'autre (écrire dans un fichier par exemple). Toi, tu le sais, et ça semblera sans doute évident à quiconque relira ton code, mais le compilateur ne peut pas le deviner (il n'y a pas de moyen de déclarer une méthode comme étant sans effet de bord en Java), du coup, il ne peut pas prendre le risque d'optimiser la boucle.

 
Approche potentiellement dangereuse : si le compilo détecte que size() est appelé sur une class de java.lang (par exemple) et pas une sous classe de l'utilisateur ou d'une de ses libs, donc une classe qu'on sait être sûr pour cet appel, vamos ?

 
Je suis pas sûr de comprendre ce que tu veux dire...
 
Mais dans tous les cas, le truc à retenir, c'est que le compilateur ne va jamais tenter d'optimiser en réduisant le nombre d'appel à une méthode. Plus généralement, il ne va pas chercher à optimiser grand chose, laissant ce boulot à la VM (la nature dynamique du langage fait que la VM a beaucoup plus d'infos pour optimiser efficacement le code que le compilateur)

 
tu veux dire que le compilateur ne fera rien, mais que la JVM, elle, peut optimiser le code? (et donc que l'assertion "déclarer une variable locale est mieux" n'est pas forcément vraie?)

Je ne connais pas les détails des optimisations faites par la VM, mais ça me semble tout à fait possible qu'elle soit capable de déterminer qu'une méthode n'a pas d'effets de bord et optimise ensuite en conséquence.

Et quid si dans le corps de ta boucle tu modifies la taille de la collections sur laquel tu iteres?

 
Typiquement le genre de cas que je verrais bien géré en JIT.
 

Problème, c'est typiquement le genre de cas que le JIT ne sait pas traiter correctement. Dès que la complexité cyclomatic augment un peu trop, le JIT jette l'éponge.

 
Moué. j'ai un peu l'impression qu'on peut trouver tout et son contraire sur le sujet.
 
J'ai peut-être mal exprimé ma pensée, mais c'est un peu à ça que je faisais référence, et l'explication me parait cohérente (à défaut de pouvoir dire si elle est effectivement juste).

c'est pas possible de le déterminer d'une façon sure

en java on peut même accéder aux champs privés par réflexivité, ou avec des thread différents

je pense que là ça relève de la compétence de chacun de connaitre java et de savoir ce qu'il fait, tout comme par exemple chacun doit savoir si il doit utiliser des synchronize ou non dans certains cas pour pas avoir de mauvaises surprises

merci pour vos avis en tout cas, c'est intéressant...