Reprise du message précédent :
Ok donc le serveur on le fait soit même genre Apache, Tomcat (et JBoss) mais faut aussi les APIs J2EE non ? faut installer le J2EE SDK sur le serveur aussi, non ?

 
non c'est pas la peine.

Ben comment l'appli va utiliser les APIs du J2EE ??? y a autre chose à installer ?

mais elles sont incluses dans les libs du serveur gros mahi !

Dans Tomcat, Apache et JBoss ???

euh, apache n'a rien à voir.
déjà apache c'est une "marque", pas un produit. tu parles peut etre de "apache httpd", qui n'est qu'un "bete" serveur web, donc n'a absolument rien à voir avec java.
ensuite, oui, tomcat et jboss, etant deux implementations d'un moteur de servlet/jsp/server web et serveur d'application, respectivement, ont les libs du j2ee.
 
faudrait quand meme ptet comprendre que j2ee ce n'est QUE ça: une série de spécifications agrémentées d'un paquet d'APIs... je conçois mal comment les serveurs pourraient implementer ces specs sans avoir ces libs

Oué désolé pour Apache.
 
Sinon je comprend mieux J2EE je pense now d'après ce que tu me dis ! :-D
 
J2EE c'est pas un soft ni un outil en soit, c juste un standard avec un ensemble d'APIs auquel adhere Tomcat et JBoss qui ont les libs du J2EE dont ils ont besoin !
 
Je voyais pas justement comment ça pouvais marcher ss installer un truc J2EE ms en fait c'est déjà inclu dans Tomcat ou JBoss.
 
C'est pour ça que faire une appli JSP/Servlet avec Tomcat en respectant les normes (arborescence /WEB-INF....) ça suffit pour être dans la norme J2EE !
 
Merci !
 
(PS : corrigez moi si j'me trompe...)

ben jpense que c'est bon là ouais
enfin "etre dans la norme J2EE" ça veut pas dire grand chose...

par contre je comprends toujours pas dans quel cas vous utilisez les EJBs ! Vous avez pas un ex d'utilisation, un cas d'école svp ?

 
pour mieux separer la presentation du contenu, MVC tout ca, cf ci dessus    

Ben on peut utiliser MVC avec simplement une servlet, des JSP, des classes métier et des javabeans et donc sans les EJBs..... c'est pas juste pr MVC, c'est pour je cite "la gestion des sessions, de la persistance, de la distribution" mais là c chinois pr moi :-/

va falloir que tu te mettes au chinois alors parce que si tu ne comprend pas ce que c'est, tu ne peux pas comprendre l'intérêt des EJB.
 
Je te conseille le chapitre sur les EJB de Thinking in java. C'est pas trop long et pour peu que tu le relises 2 ou 3 fois, ca résume bien le fonctionnement.
 
Sinon, on parle souvent de tomcat, jonas, jboss, mais y a pas que ca : ca c'est les solutions open sources. Y a aussi les implémentations propriétaires Websphere et Weblogic qui sont des implémentations compètes de J2EE.
 

 
Bonjour,
 
J'entends souvent parler de websphere, ou de weblogic lors de la recherche de mission. J'ai déjà fait une mission avec pour techno websphere mais je n'y ai jamais touché. En ce moment je suis sur un projet qui utilise Tomcat (bon là, j'y ai touché).
 
Ma question, l'utilisation de l'un ou l'autre change-t-il les développements ? faut-il faire quelquechose de spécial suivant que l'on ait sous Tomcat, Websphere ou Weblogic ?  
Pour l'instant pour mon projet Tomcat je n'ai codé de particulier rien de spécifique à tomcat qui n'aurait pas pu être utilisé ailleurs. Du coup je me demande quel savoir faire doit-on avoir, lorsqu'on nous demande de connaître Websphere ou Weblogic ?
 
A chaque que je vois une mission avec websphere ou weblogic je panique tellement ces trucs ne me disent rien.  
 
Je vous remercie par avance.

en théorie, c'est pareil d'un point de vue développement, c'est l'administration qui change.
 
La réalité c'est probablement que chacun doit avoir ses points forts niveau perfs et des points plus ou moins respectueux de la norme.

Je rajouterai surtout que certains serveurs s'accompagnent d'IDE bien foutu, qui accélèrent les développement. Je pense en particulier à WebSphere Studio, avec ses perspectives et l'appli UTC, qui permet de tester très simplement les beans.

mouais.²²²

ouais : les "gros" serveur d'applications viennet avec tout un tat d'outils. A la fois pour développer mais aussi pour déployer, controller, administrer les EJB. En plus de ca, y a certaines optimisations possibles qui sortent de la norme EJB et qpécifique à ces serveurs.
 
Encore une fois : attention de pas mélanger les moteurs de servlet (tomcat) et les serveurs d'applications (Websphere, Jboss+tomcat, etc ...)

 
D'un autre côté, le jour où tu as un problème relativement spécifique, ton  expérience se résumera à peau de balle et tu auras du mal à débugger ton truc sans ton éditeur favori ...

 

tu en parleras à un pote avec qui j'ai passé 3 jours sur msn parce que Mr se servait de WebSphere Studio et que ca merdait dans des fichiers dont il ne connaissait pas l'existence... tu pourras me dire que c'etait une burne, mais ca ne change rien au fait que ces trucs te facilitent la vie mais te cache tout du fonctionnement...
 
edit: bon ben en fait je suis pas le seul à le penser.

connaître un outil, c'est aussi connaître son fonctionnement. là c'est encore un mec qui a pas lu le manuel.
 
autant je suis contre commencer en ligne de commande, autant il y a un moment où il faut rentrer dans les détails dans le cadre de l'apprentissage.

 
c'est pour ca que finalement, je lui ai dit de se sortir les doigts du cul... parce que expliquer chaque fichier xml et son role, il suffot de lire les manuels.  
Mais le fait est que ces IDE couples au serveur cache beaucoup, et facilite l'erreur (toujours quand on ne s'interesse pas au fonctionnement)

j'ai un tuto là : http://www.tusc.com.au/tutorial/html/chap3.html
 
(je sais pas trop s'il a déjà été posté, pas grave)
 

 
par contre, je suis inquiet, car je vois du jboss directement dans le code (enfin presque) ça veut dire qu'on peut pas simplement changer de serveur d'application ?
 
 
edit : par contre, on esquive la syntaxe merdique XML

bha oui ...
tu fais du xdoclet => tu fous la conf dans le code => vu que les spécificité des serveurs d'appli sont souvent au niveau de la conf, ton code n'es plus portable ...
 
y a les partisant d'xdoclet qui vont me tomber sur la gueule mais j'ai même pas peur

non, tu as tout à fait raison.

cela dit, vu que tu changes pas de serveur toutes les semaines, bah wala.  
les tags @jonas me paraissent plus louche par contre, vu qu'ils n'apportent rien qui n'est pas déjà donné par les tags @ejb
et les tags @jboss qui sont là ne font qu'apporter un plus specifique à jboss mais ça ne devrait pas empecher l'appli de tourner ailleurs, a moins qu'un autre serveur ait aussi besoin de ce setting... (et utiliser xdoclet n'empeche pas d'utiliser en // des fichiers de configs ecrits à la main)

C'est quoi struts et ça sert à quoi?

c'est un framework pour develloper des applications web (j2ee) qui te permet de suivre le modele MVC (modele, vue, controlleur)... enfin, tout est ecrit sur le site http://struts.apache.org/

Est ce que quelqu'un pourrait me donner une définition simple mais complète des EJB de J2EE et des JSP

1) un modèle d'architecture à base de composants
2) un framework  
3) une langage de dynamisation de pages web

Comment tu peux expliquer un framework???

en gros, une plateforme sur laquelle s'appuient des applications pour fonctionner.
Dans le cas de J2EE (en faisant très très court) ca comprend à la fois des APIs, et un environnement d'execution normé

le truc tout dépassé là ?

 
Il est pas dépassé, il est utilisé massivement par l'industrie

ha, "si un tas de connard est d'accord avec quelquechose, ils ont forcément raison" ?

et faudrait prendre quoi a la place? JSF?

jetter toutes ces conneries de web
ouvrir une socket et faire passer dessus un protocole applicatif en rapport avec les besoins de l'application. et ouvrir des applications lourdes dessus.
 
Quitte à créer 3-4 protocoles pour les besoins.

j'en profite pour demander si quelqu'un a jeté un coup d'oeil aux différents travaux de "clients riches" (comprendre applications plus ou moins "lourde" côté client mais "controlée" côté serveur). ex : XUL, WCTRE d'IBM, SwingML et autres aliens du genre ...

Est ce que quelqu'un connait un bon site pour commencer en J2EE, JSP, EJB...

putain le cross-post