Discussion :

[VincHawthorne]

Bonjour !

Je viens vers vous car je n'arrive pas à faire apparaitre Glassfish parmi la liste des serveurs possibles dans eclipse.
J'ai la dernière version d'eclipse et j'ai téléchargé le zip de Glassfish 7.

quand je fais : window --> preferences --> server --> runtime environnements --> add
ici Glassfish n'est pas proposé dans la liste, et du coup je ne peux pas ajouter mon serveur ><



Est-ce que vous sauriez m'aider sur l'utilisation de Glassfish 7 sur eclipse ?

Pour le coup quand j'ai voulu créer un serveur Tomcat aucun soucis ...

[PhilippeGibault]

Peut-être faut-il un plugin spécial pour Eclipse.

Pour JBoss, il faut, par exemple, un plugin spécial (JBoss Tool).

[PhilippeGibault]

[VincHawthorne]

Merci beaucoup pour vos retours !

Dans le tutoriel que je suis (Koor) c'est effectivement ce qu'il fait, mais j'ai l'impression que cette technique ne fonctionne plus maintenant. L'installation du plugin ne fonctionne plus car le répertoire pointé n'existe plus, il a été archivé a priori.

Mon objectif est de créer un projet avec l'utilisation de JSF, peut être que du coup l'utilisation de glassfish n'est pas ce qu'il y a de plus idéal pour eclipse ...
Ce qui semble étrange car il me semble que c'est eclipse qui gère glassfish ...

[PhilippeGibault]

Commençons par la base:

Le Web de base est basé sur la servlet.

Pour faire fonctionner un projet web de base, il faut un générateur de servlet. Le plus connu est Tomcat mais on peut citer Jetty.

Après, il y a des framework qui architecture le code et se charge d'instancier les beans utilisés par l'application.
Ces frameworks font ce que l'on appelle de l'injection de dépendance.

Le framework spécifié
Le framework spécifié pour faire de l'injection de dépendances est EJB.
Il a la particularité de devoir utiliser un générateur d'EJB.

En résumé, le projet doit être déployé sur un générateur EJB.

Dans les générateurs d'EJB, il y a JBoss et Glassfish.

Le concurrent
En réalité, plus personne n'utilise les EJB, car justement, il faut obligatoirement déployer sur un générateur d'EJB.

On utilise plutôt Spring. Spring a la particularité de pouvoir marcher avec un simple générateur de servlet (comme un Tomcat).

Mieux, avec Spring Boot, on peut fabriquer un main java qui va lancer le serveur Tomcat avec l'application, ce qui facilite le déploiement, notamment par Docker.

JSF
Là aussi, il y a des choses à dire.

JSF est un framework MVC.
Et effectivement, on n'a pas besoin des EJB (donc de Glassfish) pour faire un projet JSF.

En fait, utiliser Spring pour faire un projet JSF marche très bien.

JSF a beaucoup de qualités, néanmoins, il n'est plus utilisé aujourd'hui.

Effectivement, faire du JSF demande de code Java côté serveur et client.

Or, au moins pour des raisons économiques, on découple le client et le serveur. Le client et le serveur sont deux applications distinctes et indépendantes.

Le client est fait avec un framework javascript (Angular, Bootstrap, Vue) et le serveur en Java (basé en général sur Spring).

[VincHawthorne]

Merci beaucoup pour ces explications ! Cela aide à y voir plus clair !

Mon objectif est de réaliser une appli web sur un projet interne de ma boite.
De mon côté je n'ai jusque là que manipuler java sur des projets assez basiques et sans interface graphique.

On m'a parlé des JSP du coup je me suis un peu renseigné, et de fil en aiguille je suis arrivé sur JSF qui semblait être le level au dessus.

Je ne maitrise pas les technologies front comme javascript, angular etc... Je ne pense pas avoir le temps de me former dessus.

Du coup pour mon besoin, le mieux serait de partir sur Spring en utilisant les JSP et html/css (que j'ai déjà manipulé) pour le front ?

[PhilippeGibault]

Spring + JSF mais le front dans ce cas dépendra du code Java, ce qui n'est pas une bonne chose.

De plus, il est possible de faire du Spring Boot, ce qui permettra de ne pas se faire chier avec un serveur Tomcat.

De plus, même si il est basé sur JQuery (qui lui aussi est passé de mode), il y a Primefaces:
https://www.primefaces.org/

[OButterlin]

Euh... "Plus personne n'utilise les EJB"... N'importe quoi !

Les grosses applications trouvent toujours un intérêt dans les EJB, et notre boite les utilisent massivement. Ce n'est certes plus en odeur de sainteté pour les jeunes générations vu que le ticket d'entrée est relativement conséquent, au même titre que C# et autres outils .NET de Microsoft.
Pour la terminologie, on ne parle pas de générateur de servlet ou d'EJB mais de conteneurs dans un serveur d'application EE.
Tomcat n'est qu'un conteneur de servlet là où Wildfly (ou Glassfish) est un serveur d'applications certifié EE10 (à partir de la version 27). On est loin du mini serveur Tomcat... qui fera pourtant l'affaire pour une application Spring.

Spring est le concurrent direct de la norme EE, il a longtemps été en avance sur Java EE mais ce n'est plus le cas depuis la version EE8.
Ceci dit, ça reste un très bon framework... mais pour la couche métier, on est loin des EJB... mais ça fait le job.

Pour ce qui est de JSF, c'est un excellent framework (depuis JSF v2) pour des applications web RIA, surtout couplé à une bibliothèque comme Primefaces pour les composants.
Enfin débarrassé des pages JSP au profit de Facelet (xhtml), ça change la vie, le templating devient un jeu d'enfant et fait partie de la norme, plus besoin d'ajouter un moteur de template comme Tiles.

J'ai regardé et essayé les framework javascript (Vue.js en particulier que je trouve bien né et moins lourd qu'Angular) mais bon, quand on manipule beaucoup de données, ce n'est pas aussi performant qu'un chargement côté serveur (c'est une techno qui engendre pas mal d'aller/retour pour exploiter une page complexe).
Ne nous méprenons pas, je ne dis pas que ces framework javascript sont mauvais, ils sont adaptés à certains types d'applications web, mais pas toutes.
La séparation des rôles front / back semble une bonne idée de prime abord, mais à l'usage, ça peut vite devenir une usine à gaz.
Il faut savoir choisir sa techno en fonction de ses besoins, pas d'une mode.

Bref, pour le problème de base, si tu ne trouves pas de plugin Eclipse pour faire tourner un serveur Glassfish, tu peux éventuellement passer sur un serveur Wildfly qui est très bien pris en charge par Eclipse via certaines options dans JBoss Tools.
Si tu veux continuer à explorer JSF, je te conseille fortement d'utiliser Primefaces avec, c'est une bibliothèque vraiment impressionnante

[marc.collin]

Merci beaucoup pour ces explications ! Cela aide à y voir plus clair !

Mon objectif est de réaliser une appli web sur un projet interne de ma boite.
De mon côté je n'ai jusque là que manipuler java sur des projets assez basiques et sans interface graphique.

On m'a parlé des JSP du coup je me suis un peu renseigné, et de fil en aiguille je suis arrivé sur JSF qui semblait être le level au dessus.

Je ne maitrise pas les technologies front comme javascript, angular etc... Je ne pense pas avoir le temps de me former dessus.

Du coup pour mon besoin, le mieux serait de partir sur Spring en utilisant les JSP et html/css (que j'ai déjà manipulé) pour le front ?

au lieu d'utiliser jsp, regarde plutôt thymeleaf beaucoup plus puissant et très très bien intégré à spring boot.


tu peux ajouter htmx si tu veux faire une interface plus dynamique (au lieu de faire des fetch de tes fragments).

[marc.collin]

Euh... "Plus personne n'utilise les EJB"... N'importe quoi !

en fait pas tant que ça, il suffit de regarder les offres d'emploi
ayant eu la chance de faire que de nouvelle application dans ma carrière à plus de 90% du temps.. je me rappele même pas la dernière fois que ça utilisait du jee...

Pour ce qui est de JSF, c'est un excellent framework (depuis JSF v2) pour des applications web RIA, surtout couplé à une bibliothèque comme Primefaces pour les composants.
Enfin débarrassé des pages JSP au profit de Facelet (xhtml), ça change la vie, le templating devient un jeu d'enfant et fait partie de la norme, plus besoin d'ajouter un moteur de template comme Tiles.

quitte à faire utiliser une techonologie serveur j'opterais autrement plus pour thymeleaf que du jsf. Plus simple, léger

J'ai regardé et essayé les framework javascript (Vue.js en particulier que je trouve bien né et moins lourd qu'Angular) mais bon, quand on manipule beaucoup de données, ce n'est pas aussi performant qu'un chargement côté serveur (c'est une techno qui engendre pas mal d'aller/retour pour exploiter une page complexe).

tu peux faire aussi du server side rendering au besoin avec vue, react, angular

par manipulation de grosse donnée tu veux dire quoi?
pas trop utile d'afficher 100 000 données à l'utilisateur, le paging est là pour ça

Ne nous méprenons pas, je ne dis pas que ces framework javascript sont mauvais, ils sont adaptés à certains types d'applications web, mais pas toutes.
La séparation des rôles front / back semble une bonne idée de prime abord, mais à l'usage, ça peut vite devenir une usine à gaz.

être une usine à gaz, c'est justement ce qui a toujours été reproché à Jee, jsf

Rien n'empêche même avec un framework orienté serveur de séparer séparer cette partie avec le backend

un petite application spring boot avec thymeleaf qui communique avec api gateway via webclient, ... ou bien directement avec une application monolithique

[PhilippeGibault]

Sur les EJB:
Je les ai utilisé seulement 1 fois en milieu professionnel, et ça c'est mal passé.
En plus, ils codaient vraiment mal.

Les EJB, en soit, ce n'est pas mauvais. Mais Spring est encore en avance. Au moins pour une raison: on n'a plus à se faire chier à déployer sur un serveur EJB, comme JBoss. On lance ça comme un vulgaire programme main, grâce à Spring Boot.

Et quand on a mal fait la conf maven et que ça ne se déploie plus sur le serveur JBoss (ce qui s'est entre autre passé là où j'ai utilisé les EJB professionnellement), c'est juste une horreur.

Au moins, avec Spring/Spring Boot, c'est juste un main à lancer ce qui facilite le debuggage.

L'autre fois où j'ai utilisé les EJB, c'est en milieu universitaire, au CNAM.

Autrement, j'utilise toujours Spring ou rien en milieu professionnel.

Sur JSF:
JSF, et je le pense vraiment foncièrement, est un excellent framework. Il a vraiment beaucoup de qualités, et en plus, il permet de faire facilement un code lisible ce qui est vraiment appréciable.

Le problème, c'est qu'aujourd'hui, une interface se doit d'être "poubellisable".
Et on doit pouvoir refaire une interface sans avoir à refaire tout le serveur.

D'ailleurs, cet argument est à mon sens l'une des raisons qui fait que Spring a repris de j'avance par rapport aux EJB.

C'est pour ça qui faut différentier le serveur et le client qui deviennent deux applications distinctes.

Je suis principalement développeur Back (c.a.d Java) mais depuis peu, je me suis remis au Front.
Et Angular est très bien. De plus, Anular est, dans sa logique, très proche de JSF.

thymeleaf
Je ne le connais pas plus que ça.

Il ne faut pas tout remonter
Ça, c'est vrai. C'est pour ça que l'on fait de la pagination, mais c'est vrai quelque soit le framework front/back, et la façon de développer (Angular, JSF...).

[OButterlin]

Il est toujours pitoyable de lire des critiques d'une technologie quand les personnes ne les maîtrisent pas...

En vrac :


Venir avec un problème de paramétrage Maven alors qu'il suffit de référencer le serveur d'application cible pour avoir d'office les bibliothèques cibles à disposition me laisse pantois.


Thymleaf meilleur que JSF ? Et bien, si tu en es convaincu, tant mieux, mais plus simple que :

- déclarer un bean géré par le conteneur et dans le scope voulu
- l'utiliser directement dans les pages xhtml

j'ai du mal à comprendre où on peut encore optimiser...


"Pas besoin de se faire chier à déployer sur un serveur" bah...là aussi... quel argument !
A un moment donné, il faut bien déployer sur un serveur pour avoir un back-end.
Déployer un EAR sur un serveur d'application EE ou déployer un war sur un conteneur web type Tomcat, dans les deux cas, c'est ultra simple. Par contre, on n'a pas accès à la même chose.
Tomcat, c'est un jouet pour little players, Wildfly ou Glassfish, là on est sur du costaud en terme de fonctionnalités, qui plus est, modulaires.
On peut tout autant déployer des micro-services que des objets métier distribués et accessibles à distance.


Vous en êtes resté au versions antédiluviennes pré EJB3 et pré JSF2 et vous propagez les anciennes critiques : c'est trop compliqué, c'est lourd, ça marche pas etc...
Votre avis n'a pas d'intérêt, essayez de vous ouvrir aux nouveautés de ces technos avant de les critiquer si vous voulez être crédibles !

"Une interface doit être poubélisable" ? Quel intérêt de se faire chier avec n'importe quel framework, faites des images écran et animez-les dans un powerpoint, c'est fait pour ça.
Pour les vraies applications, on repassera à quelque chose d'un peu plus compliqué mais qui répond effectivement aux besoins des utilisateurs sur du long terme.

Bon, inutile de dire que nous ne partageons pas la même conception d'une application professionnelle, je dirais donc pour conclure : Accordons-nous sur notre désaccord.

Je ne critique pas Spring (que je connais), je préfère EE 10 que je trouve largement mieux, c'est tout.

[marc.collin]

Il est toujours pitoyable de lire des critiques d'une technologie quand les personnes ne les maîtrisent pas...

le hic c'est que l'industrie ne semble pu trop misé sur le jee.... peu d'offre d'emploi,
application complexe et coûteuse
difficulté à migrer
après est-ce que tous ceux qui délaisse cela sont incompétent?

Thymleaf meilleur que JSF ? Et bien, si tu en es convaincu, tant mieux, mais plus simple que :

- déclarer un bean géré par le conteneur et dans le scope voulu
- l'utiliser directement dans les pages xhtml

j'ai du mal à comprendre où on peut encore optimiser...

puisque je fais presque du from scratch, ceux que je cottoies et qui ont touché à jsf, ne veulent juste pu y retoucher
tu as pas mal rien à faire avec spring boot...

"Pas besoin de se faire chier à déployer sur un serveur" bah...là aussi... quel argument !
A un moment donné, il faut bien déployer sur un serveur pour avoir un back-end.

je t'apprend rien et cela a été dit, tu peux très bien avoir ton serveur embarqué et juste lancé le tout via un java - jar

Déployer un EAR sur un serveur d'application EE ou déployer un war sur un conteneur web type Tomcat, dans les deux cas, c'est ultra simple. Par contre, on n'a pas accès à la même chose.
Tomcat, c'est un jouet pour little players, Wildfly ou Glassfish, là on est sur du costaud en terme de fonctionnalités, qui plus est, modulaires.
On peut tout autant déployer des micro-services que des objets métier distribués et accessibles à distance.

c'est tellement simple surtout les mise à jour de serveur que les forums sont remplie de problème...... et qu'une fois que les entreprises ont toujours à ça, ils ne veulent pu y retouche
cela reste autrement plus compliqué que spring

sans compté les coûts de weblogic, websphere....

d'ailleurs convient de serveur commercial ont fermé leur porte?

Vous en êtes resté au versions antédiluviennes pré EJB3 et pré JSF2 et vous propagez les anciennes critiques : c'est trop compliqué, c'est lourd, ça marche pas etc...
Votre avis n'a pas d'intérêt, essayez de vous ouvrir aux nouveautés de ces technos avant de les critiquer si vous voulez être crédibles !

ejb3 c'est autour de 2006, je doute fors que certain y soit resté... même les ejb3 mêmes si beaucoup de travail a été fait... cela demeure toujours plus complexe que sous spring

justement, le marché c'est spring avec ses nombreux modules... graalvm

si tu veux de la nouveaué, il y a micronaut, Quarkus... mais encore là c'est pas encore aussi complet que spring

"Une interface doit être poubélisable" ? Quel intérêt de se faire chier avec n'importe quel framework, faites des images écran et animez-les dans un powerpoint, c'est fait pour ça.
Pour les vraies applications, on repassera à quelque chose d'un peu plus compliqué mais qui répond effectivement aux besoins des utilisateurs sur du long terme.

Bon, inutile de dire que nous ne partageons pas la même conception d'une application professionnelle, je dirais donc pour conclure : Accordons-nous sur notre désaccord.

Je ne critique pas Spring (que je connais), je préfère EE 10 que je trouve largement mieux, c'est tout.

même netflix a migré à du spring boot pour son core java... on est quand même loin d'un système utilisé par 23 utilisateurs

c'est beau être un fan finie... mais un moment donné faut cesser de renié la réalité....

le marché s'est éloigné de JEE... même les banques, assurances qui misait là-dessus quitte le navire

[PhilippeGibault]

Je confirme, niveau professionnel, en général, c'est soit Spring/Spring Boot soit rien.

Excepté 1 fois, où d'ailleurs ça a été ma pire expérience, je n'ai jamais utilisé professionnellement les EJB, même les EJB3.

Je n'ai fait autrement que des EJB au CNAM, pour un cours universitaire.

EJB3 n'est pas mauvais en soi (je ne connais pas EJB2 et EJB1), mais:
1) Ils ont copié Spring.
2)Avec Spring Boot, et la façon dont on déploie des applications aujourd'hui, avec Docker notamment, Spring/Spring Boot a pris de nouveau une avance.

Le 2 fait d'ailleurs que on n'a plus à s'emmerder avec un JBoss ou autre pour déployer son application.

[PhilippeGibault]

Une interface doit être poubellisable...
Je vais préciser qu'une application serveur aussi, voir même une BDD.

C'est d'ailleurs pour ça que l'on parle d'architecture Hexagonale.

Prenons une histoire qui j'espère n'arrivera pas.

Oracle, après avoir pressé le citron client sur sa BDD décide de pressé le citron client sur Java.

Pour faire des économie, le chef (économique) de la DSI décide de sortir Java de la DSI et de passer au C#.

Il faut donc re-écrire le serveur.

1) Cas de JSF
La logique des pages est côté serveur. Il faut donc re-écrire le client ainsi que le serveur.

2)Client Angular et serveur REST (en Spring ou EJB)
Là, le client peut être gardé. Il ne fait que d'appeler des services REST. L'importance est juste qu'il doit voir les mêmes contrats de service REST.
On peut reécrire le serveur (en sortant Java) et garder le client.

La solution 2 est moins cher que la solution 1.

Ici, même si j'espère que cette histoire ne se produira jamais, car j'aime Java, c'est le serveur qui est poubellisable.

[PhilippeGibault]

Et j'ai utilisé EJB3 ainsi que JSF2 avec Primefaces.

[PhilippeGibault]

"Pas besoin de se faire chier à déployer sur un serveur"

Même si je ne suis pas Ops, je maintiens mon propos. Avec Spring Boot, on construit un Jar. Par docker, on fabrique un Jar qui va lancer une classe Main.
Et c'est ça qui va être lancé.

Donc, on ne se fait plus chier avec un serveur Tomcat (war) ou un serveur JBoss (EJB).

Après, oui, il y a un Tomcat derrière. Mais c'est bien plus simple à démarrer (et à deboguer aussi...)

[marc.collin]

Une interface doit être poubellisable...
Je vais préciser qu'une application serveur aussi, voir même une BDD.

C'est d'ailleurs pour ça que l'on parle d'architecture Hexagonale.

Prenons une histoire qui j'espère n'arrivera pas.

Oracle, après avoir pressé le citron client sur sa BDD décide de pressé le citron client sur Java.

Pour faire des économie, le chef (économique) de la DSI décide de sortir Java de la DSI et de passer au C#.

Il faut donc re-écrire le serveur.

1) Cas de JSF
La logique des pages est côté serveur. Il faut donc re-écrire le client ainsi que le serveur.

2)Client Angular et serveur REST (en Spring ou EJB)
Là, le client peut être gardé. Il ne fait que d'appeler des services REST. L'importance est juste qu'il doit voir les mêmes contrats de service REST.
On peut reécrire le serveur (en sortant Java) et garder le client.

La solution 2 est moins cher que la solution 1.

Ici, même si j'espère que cette histoire ne se produira jamais, car j'aime Java, c'est le serveur qui est poubellisable.

dans le cas 1, tu pourrais très bien séparer en 2... avoir une applications jsf qui communique avec une autre application via rest

dans ton cas 2 certe le client peut être gardé, mais il faut pas oublié les coûts de maintenance... toujours vrai avec du react, vue... le passage à une version supérieur ne se pas toujours aussi aisément... et si tu sautes trop de version... ça peut devenir complexe et coûteur à migrer

[PhilippeGibault]

Je comprends les arguments, mais on dira que dans un premier temps, c'est théorique. Néanmoins, ça va aussi avec un domaine plus large: L'urbanisation des SI.

[marc.collin]

Merci beaucoup pour ces explications ! Cela aide à y voir plus clair !

Mon objectif est de réaliser une appli web sur un projet interne de ma boite.
De mon côté je n'ai jusque là que manipuler java sur des projets assez basiques et sans interface graphique.

On m'a parlé des JSP du coup je me suis un peu renseigné, et de fil en aiguille je suis arrivé sur JSF qui semblait être le level au dessus.

Je ne maitrise pas les technologies front comme javascript, angular etc... Je ne pense pas avoir le temps de me former dessus.

Du coup pour mon besoin, le mieux serait de partir sur Spring en utilisant les JSP et html/css (que j'ai déjà manipulé) pour le front ?

pars sur spring avec thymeleaf, c'est ce que spring utilise pour la majorité de leur exemple