Reprise du message précédent :
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...

j'ai une question avec les dao generiques

dans le code j'ai un superbe

mais ce qui m'interesse c'est d'avoir une seule instance de dao qui prendra en parametre des objets de type tels que <T extends UnType>

mais du coup la methode getParameterizedClass() risque de renvoyer du Class<UnType> non ?

mon but c'est déclarer ma class dao

de façon à pouvoir l'autowirer dans du

sauf que là ça me semble peut probable que getParameterizedClass()  renvoit du Class<TypeQuiEtendUnType>

à priori je suis obligé de faire une methode load du style ?

en fait le fait de vouloir absolument déduire la class à partir du parametre du dao, ça oblige à implémenter réellement le dao pour chaque type

donc faire à chaque fois du

pour avoir un equivalent de new GenericDaoImpl<TypeQuiEtendUnType>() qui me parait être le seul moyen que

((ParameterizedType) getClass().getGenericSuperclass()).getActualTypeArguments()[0]

puisse être au courant d'un paramètre

ce qui au final réduit considérablement l'intéret d'avoir un dao générique, vu qu'il faudra l'implémenter à chaque fois

pour cette raison, faire un load en passant la Class<T> en parmetre me parait indispensable si on veut rendre générique au maximum

quel avantage a tu à ne pas mettre le parametre <M extends AbstractModel> direct sur la classe ?
 
admettons que tu fasses  
 
public class GenericDaoImpl <M extends AbstractModel> implements GenericDao <AbstractModel> {
}
 
je suis pas bien sur de ce qui se passe si on fait
new GenericDaoImpl()
 
et encore moins si on fait un spring bean avec un @Component sur la classe

ils vont enfin finir par rendre standard les accès base dans la vue    
 
il y a quelques années quand je connaissais pas bien java, je me rappelle que j'avais déjà tenté d'implémenter un truc dont le but était de pouvoir faire
 
monBean.save()
 
ça me paraissait logique
 
mais je me suis pris les pieds dans le tapis biensur, vu que j'avais que jdbc à disposition
 
 
par contre le code que j'ai vu en groovy jusque là sur un des projets ne m'a pas du tout donné envie de faire du groovy
il y avait tout ce que je trouve pourrit en java
nottament des closures à gogo
certains aiment bien avoir des méthodes anonymes pour avoir tout le code sous les yeux on dirait, moi je préfère avec un nom de classe ou de méthode qui dit clairement ce que c'est censé faire, et ne pas avoir besoin de lire le code