Oui, mais pas spécialement implémenter des outils propriétaires. Glassfish implémente la jsr dont-j’ai-oublié-le-numéro qui permet de gérer n’importe quel serveur d’applications java, je trouve que maven peut l’utiliser directement. Je trouve l’incorporation d’outils propriétaires dangereuse et sans limite claire, d’autant qu’il n’y a à mon avis pas de nécessité à incorporer ça dans Glassfish, ça peut être extérieur.

Voir https://maven-glassfish-plugin.dev.java.net/ . Je pense qu’on peut maintenant faire tout ça de manière standard (ce n’est pas spécifique à Glassfish).

1. JCP est bien plus fermé qu’OSGI:
Tu ne rentre dans le comité exécutif du JCP que si tu es un grand industriel: “The EC represents both major stakeholders and a representative cross-section of the Java Community”.
Pour les grades de membre voici les tarifs: http://jcp.org/en/participation/membership

OSGI n’a pas de grade plus haut que “full member” et est ouvert sur paiement de la licence: http://www.osgi.org/About/Join
IBM est full-member. Donc si vous payer le prix, vous aurez autant de pouvoir de décision sur les specs.

2. OSGI se devrait plus d’être comparé à une JSR. OSGI est un ensemble de spécification pas un processus

3. “OSGI propose des fonctionnalités dont peu de monde a besoin. Par exemple, l’arrêt/relance de bundle à chaud”
Vous redémarrez votre serveur à chaque fois que vous déployer votre application ?
Vous n’avez jamais trouvé nécessaire de re livrer qu’une partie de votre application sans refaire tout un process de déploiement ?

4. “IBM a besoin de log4j, il va créer son bundle. Idem pour Eclipse”
Hummm… vous êtes sur ?

Par exemple, pour une meilleure lisibilité du code il est problématique d’avoir une table “T_ACHETEUR” dans la base de données, sa classe Java pour le mapping “P03_01_HumanBeingEntity” et une entitée JPA “buyer”.
Techniquement, c’est possible… mais lorsque le fonctionnel est complexe et les entités nombreuses, une nausée est vite arrivée chez le développeur.

Dans mon cas, la BDD était le fil rouge, le processus (dev Java) s’adapte à la BDD et pas l’inverse.

Afin de garder la logique de la nomenclature et faciliter sa maintenance, nous avons modifiés:
1- le nom des tables dans notre SGBDR favori
2- le nom des classes java
3- le nom de nos entités (@Entity(name = “myEntityName”))
4- nos requetes *QL

Le point 1 a pour partie sensible de ne pas faire de faute de frappe (jusque là, ca va)
Le point 2 a la même partie sensible que le point 1, le refactoring Java est simplifié par des EDI comme Eclipse et la compilation nous alerte et pointe les oublis et autres erreurs humaines.
Le point 3 a la même partie sensible que le point 1
Le point 4 ne pourra être testé que par des tests unitaires (mais une appli est rarement couverte à 100%) ou en recette (rarement couvert aussi à 100%).

Dans le cas du point 4, comment s’assurer rapidement d’une non régression?
La vérification des entités de NamedQuery permet d’éviter des oublis de non modification dans nos requêtes JPQL, sans attendre l’exécution de la requête.

@Alain, bien souvent, on mappe une table à une entité et réciproquement:
@Entity
@Table(name=”EXEMPLE”)
public class MaClass {
…
}

Je ne comprends pas le rapport avec les NamedQueries car qu’on les utilise ou non, JPQL se base sur le nom des entity et non pas des tables.

Conclusion de tout ça : hibernate fait du PreparedStatement pour les query dynamiques, donc ce n’est pas vrai de dire qu’une NamedQuery est plus performante.

Néanmoins, ca me semble apporter déjà une vérification qui est mieux que rien! Une fois un client, m’a demandé de changer le nom de chaque table, mais pas la structure… Une vérification sur le nom des entités est toujours la bienvenue!
Et le chargement au démarrage et non au fil de l’eau, me fait rappeler l’esprit de l’optimisation “-server” des JVM. Mais je crois que dans le cas des NamedQueries, je classifierai cela parmi les pico optimisations.

Par contre, j’ai besoin d’éclaircissements sur un point plus important: est ce que JPA+NamedQuery et (Hibernate+Driver JDBC autorisant PreparedStatement) font le boulot en double avec leur cache?

Si elles sont dites plus performantes, c’est qu’elles remplacent souvent a posteriori (en cas de problème) un mapping non réfléchi

Il n’y a pas de secret, l’entropie d’un système reste la même quelque soit votre solution :
- soit vous déléguez à hibernate&co la partie compliquée, au risque de mal l’utiliser
- soit vous passer le temps nécessaire pour arriver à une solution plus réfléchie

Erwan