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

bon j'ai vraiment trop de mal avec les générics

j'ai bien une classe avec
 public interface GenericDao {
  <M extends AbstractModel> void delete(M model)

mais je voudrais que GenericDaoImpl soit membre de mon GenericService<T>

et là fatalement ça chie dans la colle, parcequ'il veut absolument que T extends AbstractModel

en fait il me faudrait caster <M extends AbstractModel>  en simple <T> quelque part, car si jamais j'implémente un autre dao qui n'a pas cette contrainte, alors je devrais pas avoir de dépendances sur le AbstractModel en dehors du dao

edit:
 
bon ça me soulait alors j'ai fait

public interface GenericDao {
  <M> int count(Class<M> modelClass);

et dans mon implémentation je caste les M en AbstractModel  

par exemple <M> void delete(M model){

AbstractModel  x = (AbstractModel) model;
}

parceque à la base ma couche controleur était parametrée avec T
puis il a fallut que j'utilise un dao déjà codé qui était parametré avec T extends AbstractModel
 
et là ça coince, car mes interface de service étaient parametrées avec T et non T extends AbstractModel, d'ou la nécéssité de faire un cast, mais c'est un peu la merde

j'aimerai mettre en place Hibernate Envers à la place d'un truc maison d'historisation
 
mais ce qui serait bien c'est de pouvoir aussi logguer qui fait les changements, suivant qui est loggué dans l'appli
 
il y a moyen d'utiliser des listeners customisés pour exécuter du code juste avant une insertion
donc là je voyais comme solution de mettre le user dans le thread local, afin de ne pas avoir à le trimbaler dans toutes les méthodes, et de le récupérer dans le listener de cette façon
 
est ce qu'il existe dans spring des moyens intégrés de faire ce genre de trucs ?

J'ai 2 serveurs jetty loadbalancés via apache/mod_proxy.

Je tente d'implémenter un "prepare for shutdown" (p4s): quand mon jetty est flaggué "p4s", il refuse toute nouvelle connexion et ne s'arrêtera que lorsque les threads courants sont terminés. Soit.

Que dois-je répondre lorsque je décide de refuser une nouvelle connexion ?
J'ai tenté un hsResponse.setStatus(HttpServletResponse.SC_SERVICE_UNAVAILABLE); // hsResponse étant HttpServletResponse

Mais si il refuse bien la connexion, le loadbalancer le prend tel quel et le balance au client sans le soumettre au second jetty

Une idée ?

aucune idée
 
tiens c'est marrant que les annotations étendent automatiquement la classe Annotation sans qu'il y ai besoin de le spéficier à la déclaration avec public @interface
 

qu'est ce que c'est nul en java de pas pouvoir de passer de méthodes en paramètre

on doit utiliser des trucs tous laids avec interfaces ou classes abstraites

ce que tu gagnes en puissance, tu le perds en clarté, lisibilité et maintenabilité.
 
et il faut se rendre compte que tous les développeurs n'ont pas le même niveau (je n'ai pas la grosse tête, je ne me considère que comme programmeur "satisfaisant" ) et donc si c'est pour que 3 pelés et 2 tondus puissent gérer le code une fois en prod c'est perdu. AMHA.

Tu perds quoi en "clarté, lisibilité et maintenabilité" exactement quand tu passes de 5 lignes de boilerplate pour une instance de type anonyme à un bloc autour d'une expression?

j'ai sans doute généralisé mais tout n'est pas forcément boilerplate -> clean.

le soucis c'est que si tu as du code comme
un objet X avec des fonctions f1() f2()
 
 
si tu as un code qui doit revenir plusieurs fois comme  

tu te dis que tu voudrais en fait bien pouvoir factoriser ce bout de code commun
donc manifestement il y a que la fonction appellée sur x qui change, f1() et f2()
 
mais tu peux pas la passer en argument
 
par contre on peut faire un pattern command
 

 
avec

et plus deg encore  
 

 
donc tout ça pour passer une fonction en paramètre
 
ce qui serait plus légé c'est plutôt
 

 
bien sur par reflexion on peut, mais il doit falloir faire intervenir une string "f2" pour récupérer le nom de la méthode, ce qui permet pas de se rendre compte de problème à la compilation  
le problème en java c'est qu'il y a toujours quelqu'un qui va vouloir trouver la parade, et ça donne en fait du code complexe avec classe anonymes etcetera

Et sinon, Scala, c'est vachement bien

faudra que je jette un oeuil

 
Gros +1, et la Typesafe Stack est très prometteuse.

je comprend pas encore grand chose. Je vois bien 2/3 concepts, mais pas plus.  
C'est quand même pas très simple...j'essaye de m'y mettre avec play 2, mais je galère bien.

http://www.playframework.org/

 
J'avais justement relurké la semaine dernière \o/
Pour ce qui est de Scala par Play!, je commencerais quand même pas dans ce sens. T'as le templating et le framework qui masquent le langage en lui même, ça doit induire pas mal de confusion.

vous avez un exemple concret qui significatif par rapport à java ?

type matching par exemple
http://www.touilleur-express.fr/20 [...] e-et-some/

 
 
Et encore, ton lien ne rend pas complètement hommage à la feature
Mon préféré c'est le pattern matching sur les champs de ton objet :
 

case class Foo(bar: Int, baz: String)

def test(foo: Foo): String = foo match {
    case Foo(1, s: String) => "Un Foo avec comme bar 1 et comme baz " + s
    ...
}

j'aime vraiment pas la syntaxe par contre
 
sans doute à cause de l'habitude, mais le code groovy c'est pareil, je trouve ça pas très lisible

C'est pas pour être relou (et après cette relance promis, j'arrête), mais je pense que vous passez à côté de quelque chose de formidable.
 
http://forum.hardware.fr/hfr/Progr [...] 6363_1.htm
 
A première vue, on pourrait penser que ce topic est comme les autres, un noob qui rencontre un problème de classpath finalement. Ça serait une erreur. Si les 10 premières minutes de film semblent confuses et réchauffées, on s'aperçoit rapidement que le personnage principal est pris au piège d'une machination diabolique où deux puissants s'opposent sans penser aux conséquences pour le monde.
 
Une histoire sur les différences qui nous unissent, sur la volonté, mais aussi sur le désespoir vis-à-vis d'un monde qui ne nous comprend pas (que nous ne comprenons pas ?) . Si Intouchables a eu un Cesar, mon post doit pouvoir obtenir une réponse.
 
http://forum.hardware.fr/hfr/Progr [...] 6363_1.htm
 
Merci d'avance  

est-ce que tu ne ferais pas face à une (des) limitation(s) du classloading classique tout simplement ?

C'est possible, encore faudrait-il que je vois à quelle(s) limitation(s) tu fais référence
 
On passe sur le topic en question ?

yup

150 jours hommes plutard ...  

je cherche à avoir une gestion d'annotation qui fonctionne selon
 
 
pas mal cette page  
http://weblogs.java.net/blog/cayho [...] prope.html
 
ça répond pas à mon problème, dans la pratique, mais conceptuellement ça y répond tout à fait
 
mon problème c'est que j'ai des annotations maison, et que c'est prise de tête pour savoir si les fous sur des attributs, ou des méthodes, ou si on veut les deux
 
finalement avec un
 

 
le problème serait réglé
en effet si je fais un PropertyDescriptor(Class, property), qui va permettre un acces clef en main au méthodes getters et setters, ça n'empêche que si je veux mettre mon annotation sur un attribut, alors cette classe n'empêche pas que je devrait faire un
 

 
suivi, si l'annotation est null, d'un  

 
c'est naze

et lombok ?

oui intéressant
 
mais je me vois pas utiliser ça sauf pour des projets perso pour le moment

perso ça me pique moins les yeux que l'autre implem' linkée plus tôt

c'est à dire ?
 
si ce que fait lombok était intégré de base dans une prochaine release de java j'aurais aucun scrupule à l'utiliser
 
la rétissance que j'évoque dans le message avant, porte plus sur le côté "librairie exotique"
On a tendance à pas trop aimer le changement quand il est imposé, ce dont je me suis bien rendu compte en devant reprendre du code groovy

bonjour les gens,

J'ai une classe MyLogger qui est instanciée par des Threads qui est un logger bifide: il loggue dans Log4J (log global) et loggue en même temps dans un thread.log spécifique.

Donc A<Thread>.info("pouet" ); -> MyLogger.info("pouet" ); -> MyLogger.log(INFO, "pouet" );

Ca marche bien, si ce n'est que je dois jongler un peu pour que mes lignes de logs ne viennent pas toutes de MyLogger qui appelle techniquement les méthodes de logging.
(je crée une Exception vide, je navigue dans les StackTraceElement pour savoir qui appelle réellement, c'est du logging business pas technique et je ne pisse pas des tonnes de lignes donc je ne perds pas de temps)

Je travaillais par réflexion pour appeler la bonne méthode de logging:

Mais j'avais pas mal de bruit dans le log pour la classe appelante genre:
 20120327|060203.785|INFO|GeneratedMethodAccessor20393.invoke:?|mon message

Je tente de résoudre le "GenerateMethodAccessorXYZ.invoke" par:

(je sais, toPriority() est deprecated, je tente de fermer des portes avant de cleaner ça )

la javadoc est celle-ci:
public void log(String callerFQCN,Priority level,Object message,Throwable t)
This is the most generic printing method. It is intended to be invoked by wrapper classes.
Parameters:
callerFQCN - The wrapper class' fully qualified class name.
level - The level of the logging request.
message - The message of the logging request.
t - The throwable of the logging request, may be null.

J'ai un souci pour comprendre le callerFQCN: j'ai tapé le fully qualified name de la classe business

Si j'ai Toto qui loggue via MyLogger, je m'attends à:
 20120327|060203.785|INFO|Toto.method:23|mon message

Mais Toto dérive de SuperToto et je reçois dans le log:
 20120327|060203.785|INFO|SuperToto.method:23|mon message
 
Si je ne précise pas le FQCN, c'est évidemment ceci que je reçois:
 20120327|060203.785|INFO|MyLogger.log:132|mon message

Une idée de ce que j'ai merdouillé ?

Vous savez pourquoi lorsque l'on fait un refactor/move d'une classe des fois eclipse (ou le plugin svn) bouge l'historique de la classe avec et des fois non? (c'est alors vu comme un nouvel élément à ajouter au repo)

c'est pas le dossier que tu déplaces ?

j'ai un blem avec hibernate, envers et sqlserver
j'ai une colone qui s'appelle DESC
desc est un mot clef donc ça foire et il faut le protéger avec [DESC] ou `DESC` dans la déclaration en annotations ou en hbm.xml
 
mais hibernate envers qui créé des tables d'audit à partir des beans audité semble prendre systématiquement le nom non protégé
 
qqun à une idée ?
 
ps: je pense biensur changer le nom de cette colonne, car je m'en suis sortit une première fois, mais là c'est le retour de baton

bon j'ai changé en desc0  

et en modifiant avec un @Column("DESCRIPTION" ) ?

j'ai une question hibernate
 
en général hibernate et certaines librairies associées, préfèrent que soit utilise des ID techniques.
Par exemple avec hibernate envers il y a pas vraiment le choix.
 
Je me demandais si il existait une surcouche ou une lib qui permet de gérer en plus des ids fonctionnelles ou si il faut forcément faire son truc maison
 
par exemple ça s'avère reloud, si par exemple à la saisie d'une valeur, il faut aller chercher dans la base si un objet avec cet id fonctionnel n'existe pas, alors que si la clef fonctionnelle sert de clef technique, un simple saveorupdate suffit ou un delete

 
bah j'ai fait @Column("DESC0" )
 
en fait c'est une table de réferentiel, et les autres champs étaient nommés dans le spec  
truc_much_DESC
truc_much_DESC1
truc_much_DESC2
truc_much_DESC3
 
je trouvais que ça servait à rien de mettre truc_much car ça revenait quasiment à répéter le nom de la table dans chaque champ, alors j'ai gardé que la dernière partie
et le coup du mot clef réservé je l'ai pas vu venir
 
@Column("[DESC]" ) fonctionnait pour le bean de la table principal, mais envers créé automatiquement des mapping et des tables d'audit en interne, en se basant sur le bean audité (il créé pas de code java, c'est dynamique), et là il semble plus prendre en compte la protection du nom
 

 
bon les solutions les plus simples sont souvent les meilleurs
J'ai juste viré l'id generated en long, et hibernate envers supporte les clefs composites contrairement à ce que je croyais.
 
c'est quand même bien plus simple comme ça

 
Cela peut dépendre de comment tu le fait, et avec quel plug-in SVN (subclipse/subversive). Les deux plug-in n'ont pas le même support pour les différentes vues d'Eclipse (c'est en partie la faute à la feature "Team", mais c'est une autre histoire).
D'expérience, le support est le meilleur lorsque tu travailles soit dans l'éditeur, soit dans la vue "Package Explorer", les autres vues n'ont pas toujours les bon listener enregistré.