Reprise du message précédent :

Elle vient de loin, ça c'est sûr.

Elles sont pas créées, elles sont déclarées dans la signature. Suivant la config, Eclipse peut gueuler si on fait un override qui ne jette pas lui-même l'exception.

Ca c'est le cas excusable encore, la grosse majorité c'est des throws anarchiques parce que le mec a copié/coller du code, qu'il l'a fait évoluer sans impacter ou bien qu'il est juste neuneu.

Question qui aurait peut-être sa place sur web, mais les outils font partie de l'écosystème Java.
 
J'ai une appli dont les vues sont basées sur des templates Velocity. Sur un même URI, en fonction de ce qu'accepte le client, je renvoi une page entière HTML (client web dont le JS est désactivé) ou du JSON avec les données nécessaire pour construire le fragment de la page qui doit être modifié (cas inverse).
 
Ce que j'aimerais, c'est utiliser mes templates partiels Velocity en clientside, histoire de pas reconstruire en JS côté client ce qui est déjà fait avec un "algo" identique en serverside.
 
J'ai rien vu à ce sujet sur l'intarweb, mais vous aurez peu-être des idées / conseils ?

Dites, ca sert à quelque chose d'intercaler un CheckedOutputStream quand on fait de l'I/O si on appelle jamais getChecksum() ?

En particulier quand on veux zipper, je soupçonne l'auteur d'avoir pris un exemple de code foireux trouvé sur le net.
M'est d'avis que si tu te sers pas du checksum généré ça ne fait que rajouter du temps cpu inutilement.

 
J'ai deux pistes : https://github.com/vapour/jsVelocity (peu d'activité, mais semble quand même la meilleure solution) et http://velocity2js.sourceforge.net/ (rien depuis 2007...).
 
J'ai l'impression de m'embarquer dans une galère là    
 

Bon, il s'avère que ZipOutputStream utilise déjà un CRC en interne
 
Donc merci pour rien, je peux pas changer l'implem du checksum.

y'a des moteur de template qui existent en java ET en js avec la meme syntaxe, genre mustache et un autre dont le nom m'échappe, donc si tu n'es pas fortement attaché a Velocity (t'es maso ?), c'est une option.

the real moins moins > Tu pourrais préciser pourquoi tu aimes si peu Velocity?

c'est moche, verbeux, complètement pas flexible (pas de directives custom), et complètement pas flexible^2 voire pas safe (t'as aucun controle de comment les objets du contextes sont exposés à la template, tu peux appeller n'importe quoi comme methode (foo.setTruc('lol') foo.save()), il bouffe le whitespace n'importe comment, et c'est moche.

 
Du coup, t'aurais quelque chose à me conseiller ?

ben euh:
 

 
(l'autre c'est handlebars je crois)

Moche et verbeux, euh, je vois pas trop par rapport aux autres, mais soit.
Pour les directive, tu peux faire toutes les directives custom que tu veux.
Le seul truc que je t'accorde, c'est qu'effectivement, pouvoir faire plus que des simples appels type OGNL est potentiellement dangereux.
La gestion du whitespace est cohérente et documentée.
 
'fin bref...

 
Tant que t'es là à défendre Velocity, t'as pas une idée pour mon problème ?
Tu penses qu'au contraire je pars dans une mauvaise direction ?
 
--: je regarde mustache, le nom lui donne d'emblée un bon point

 
Je ne defend pas specialement Velocity, mais j'apprecie la critique quand elle est fondee.
 
Sinon, pour ton probleme. On avait un requirement initial similaire (Version avec et sans JS). Du coup, on generait le fragment HTML en server-side avec Velocity, et on injectait le resultat dans lors des appels ajax.  
Mais cette solution n'est pas vraiment maintenable a long terme car on veut plus de dynamisme avec la version JS, et la liste d'information renvoyee pouvait etre nettement plus petite. Donc on est partie sur des templates pur JS quand on en avait besoin (generalement avec KnockoutJS car on l'utilisait deja pour le binding).

 
Ça requière dans tous les cas de ne pas taper sur le même URI, puisque dans les deux cas tu souhaite rendre du HTML. Dans l'idée, mon trigger js / non-js est sur l'header accept, d'où la nécessité de renvoyer du JSON.
 

 
Donc tu maintient deux jeux de templates potentiellement identiques sous deux moteurs différents ?
 

 
On tapait dans la meme URL. On ne renvoyait juste pas le meme Viewable en fonction de la requete.
 

 
Non. Maintenant on a un template Velocity pour le squelette de la page, avec des placeholders pour attacher des templates JS dont on a besoin en cas d'appel JS.

 
"Même URL" + "en fonction de la requête"    
Je vois que deux moyen dans ce cas, soit le accept soit ajouter un paramètre genre /foo?render=json, ce qui équivaut à mon sens à modifier l'URL.
 
1. Je peux être dans l'erreur.
2. Je cherche pas à être lourd ou insistant, mais à bien comprendre comment vous procédez, ça peut certainement me servir.
 

On utilisait effectivement le accept pour faire la differenciation.

 
Autoquote pour la bonne cause : aide au choix d'un moteur de template.
 

Hello,

j'ai un soucis de déploiement d'un war par Jetty sous Linux. Spring framework plante sur un Permission denied dans un File.createNewFile au démarrage (appelé par BeanUtils.instantiateClass() ).
Quelqu'un a une idée d'où il tente de déployer ses beans, que je mette les droits adéquats ?
Sachant qu'a priori, le répertoire de Jetty et les sous-réps (webapp, context, etc) ont des droits d'écriture correct.
Merci.

edit: c'est bon, c'est résolu. C'était des chemins dans notre appli qui étaient encore en format windows et qui foutaient la zone.

Bonsoir,
 
Je suis en train de finir le livre du siteDuZero sur Java, et en voyant mon code du TP « le pendu » et celui de l'auteur ça fait peur   . Pour la suite, il vaut mieux que je prenne un livre style « exercices en Java » pour en manger et essayer de comprendre un peu plus la POO, ou de prendre un livre « design patterns pour Java » histoire d'essayer de mieux organiser mon code dès le départ ?
 
Je serais tenté par la deuxième solution, mais j'ai ouvert le livre du GOF l'autre jour et j'ai pris peur  

bouffer du pattern pour le plaisir d'en bouffer c'est franchement indigeste.
 
perso, j'essaierai de m'améliorer en douceur puis d'attaquer les patterns petit à petit.

D'accord, merci.
 
J'ai trouvé ce lien avec des exercices corrigés. Ça a l'air pas mal. C'est surtout la POO qui me donne du mal (son organisation, quand mettre une classe abstraite, une interface...)

Dites.
 
On utilise yourkit pour analyser des dumps de jvm mais ces dumps font environ 5Go et ça prends une éternité pour l'ouvrir, même sur notre grosse machine solaris, ça fait plus d'une heure qu'il est en cours d'ouverture. Vous connaissez d'autres outils plus performants?

plus performant sur 5GB et comparé à Yourkit, je ne sais pas...
Mais Memory Analyzer s'en sort pas mal comparé à VisualVM sur des 2GB.

 
Je reviens là dessus, dans le cadre des migrations / évols, vous procédez comment ? J'ai une tâche maven sur l'updateSql, mais ensuite, qu'est ce qui exécute ce script d'update ?
 
Utilisateur à la mano ? Tâche Hudson ? Autre ?

Ca dépend.
Pour les environnement de DEV et FAT, on utilise la tache liquibase:update sur nos DB.
Mais pour la prod, comme on n'a pas la main sur les serveurs, on génère le SQL avec liquibase:updateSQL et on le livre séparément à l'équipe opérationnelle (qui elle, fait tout à la main, sans lire les intructions, et oublie la moitié de la config une fois sur deux ).

OK, c'est cohérent avec ce que j'avais en tête

Yop, les gens, j'ai une question securite:
 
J'ai deux applis deployees sur le meme domain (/domain/app-1 et /domain/app-2). Elles utilisent la meme base utilisateur, et la securite est gere avec Spring Security.
Dessus, on a un SSO, qui fait que tout utilisateur logger sur /domain/x est automatiquement authentifie sur /domain/**. Le tout est REST, donc rien en session.
 
Maintentant, on me demande de faire communiquer les deux applis, pour que app-2 puisse aller chercher des infos de app-1.
A priori, on se dirigeait vers des appels rest d'une appli a l'autre, mais je ne vois pas comment soit:
* Ne pas rendre les URL de ses appels accessible de l'extérieure.(sachant que restreindre par IP n'est pas une option).
* Passer les infos necessaire a creer un contexte de securite dans l'appli appelee.
 
Des idees?

J'ai une question de noob, mais y'a jamais grand monde sur les topics dédiés... C'est d'ailleurs pas tellement une question mais plus une demande d'info sur les contextes de sécurité en Java/JEE.
 
J'ai un mapping utilisateurs / rôle en DB, des EJB sécurisés par des rôles, et pour le cas qui m'intéresse tout de suite, des utilisateurs qui tapent dans tout ça par le WAR.
Ce que je veux, c'est récupérer le rôle à partir du nom d'utilisateur (qui est une source sûre pour l'exemple). Je pense que c'est le principe du SecurityContext, mais j'ai du mal à trouver des ressources pour bien comprendre le mécanisme. J'imagine qu'il faut que j'en implémente un custom qui tapera dans ma DB (ou un accès par les EJB ?) et qui sera configuré dans le web.xml, mais je sais pas comment lui passer le user puisque je le récupère déjà par le contexte (getUserPrincipal(), sur un connecteur Waffle/LDAP).
 
De même, je sais pas si c'est le rôle du WAR de porter ce genre de mécanisme.
 
Si vous avez des pointeurs sur le sujet

Euh, tu veux connaitre les roles d'un autre utilisateur que celui qui est connecté, ou bien de l'utilisateur courrant? Parce que dans le deuxième cas, c'est ton connecteur Waffle qui devrait peupler ton Principal avec les roles de l'utilisateur.

Rien à voir, mais qqun aurait déjà fait mumuse avec ça par hasard ?  
 
http://code.google.com/p/lanterna/
 
Le but du jeu pour moi là tout de suite c'est de fournir un jar double-clickable avec une ui minimal pour des users lamba -- j'ai l'appli (si on peut parler d'appli) qui tourne bien un CLI, et si je pouvais sugar coater avec un truc qui necessite pas d'ouvrir un terminal ça serait sympa...

putain qu'est-ce que ça peut me faire chier de pas pouvoir utiliser java.io.Console avec un inputstream de mon choix (i.e System.setIn()) -- je dis pas que y'a pas de bonnes raisons mais c'est casse-burne, je vais devoir wrapper mes appels à Console maintenant.. et probablement donc  les virer, tout simplement, et reproduire sa méthode readLine() ...

 
Je récupère le rôle du visiteur (authentifié par Waffle), donc oui, ta seconde proposition me parait également la plus logique. Faut donc que je regarde comment pluger le connecteur Waffle avec ma DB parce que d'emblée, j'ai rien vu de tel.
 
Merci pour ta réponse

 
Je vais quand même essayer de détailler l'ensemble, je pense que je pars dans des directions hasardeuses.
 
Notre appli doit récupérer l'identifiant de la session courante Windows des visiteurs. Avec cette info, on récupère sur l'Active Directory / LDAP les infos du visiteur. On rapatrie également les droits du visiteur sur notre appli, droits qui ne sont malheureusement pas liés à un quelconque groupe ou tag sur le LDAP mais qui sont gérés par l'appli (association utilisateur/rôle).
 
Actuellement, on procède comme il suit :
1. Récupération du ticket Kerberos par une Valve Waffle.
2. Jersey récupère le nom du Principal de la requête et se charge des tâches "d'enrichissement" (infos LDAP et appel de notre couche métier pour la récup' des droits). On fait ça à partir d'un Provider maison, en suivant cette méthode.
 
C'est plutôt élégant, mais l'étape 2 est répétée à chaque requête du visiteur, ce qui est un peu lourd. Je pourrais utiliser une session pour éviter le rejeu, mais c'est pas encouragé par REST et Jersey, c'est donc à ce moment que je me pose la question de quelle couche de mon appli devrait avoir la responsabilité de la qualification du visiteur.
 
Je vois les cas suivants :
A. Géré par ma Valve (ou autre mécanisme Waffle), mais j'ai peu de ressources là dessus et j'ai un doute quant à la pertinence du lien entre le Waffle et mon métier.
B. J'arrête de me prendre le chou, je laisse tel quel et je stock les infos en session.
C. Autre chose que je ne vois pas.
D. Obiwan.
 

Je débarque peut-être mais c'est quoi ce truc ? l'interet par rapport au fait de déclarer "abstract class" au lieu de "interface" ?  
 
https://www.surveymonkey.com/s/9VPJZQQ

Lu en diagonale, mais je vois ça comme un pseudo mixin.

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é.