Migration Java SE vers Java EE

Bonjour, je me demande si quelqu'un a deja fait l'experience ou a des informations sur l'idee (saugrenue) de migrer une application Java SE vers Java EE. Grossierement, le project consiste a mutualiser un code existant (plusieurs centaines de milliers de lignes) pour reutiliser les ojects de gestion. Bien entendu, le code doit rester compatible avec la version Java SE. Ce sont des entites contenant la logique de persistance relativement facile a migrer vers une solution de type JPA.
Par contre, je bloque sur toutes les methodes statiques du genre "public static InventoryProfile findProfile(String name)" pour passer au modele EJB. Revoir la totalite du code existant n'est pas possible (delai environ 1 mois) et utiliser autre chose n'est pas permis, le chef a deja achete le bouquin Java EE 6 et a decide que ce serait la solution :(

Bah procéder par délégation, extraire le code de la méthode statique, le transformer de façon à ce que ça colle avec les notions EJB, puis dans la méthode statique faire appel à l'EJB. La logique doit se trouver au niveau de l'EJB, la méthode statique doit rester dans la partie JavaSE.

Citation:

---

Envoyé par sinok

Bah procéder par délégation, extraire le code de la méthode statique, le transformer de façon à ce que ça colle avec les notions EJB, puis dans la méthode statique faire appel à l'EJB. La logique doit se trouver au niveau de l'EJB, la méthode statique doit rester dans la partie JavaSE.

---

Je suis bien d'accord, mixer le controleur, la logique et l'entite en une seule classe, c'est pas beau! Il faut extraire et transformer. Cependant c'est facile a dire, facile a faire quand c'est les autres qui se tape le boulot mais ce coup ci je ne suis plus le chef de projet, je suis le programmeur... N'arrivant pas a exprimer mon desarroi devant ce type de probleme, j'ai mis le clavier en face de mon collegue. Je me suis marre quand il est reste pendant une minute sans bouger, les mains au dessus du clavier, ne sachant plus comment faire.:mouarf:
Sachant que cela represente un code de plus de 300000 lignes, je tourne ma question differemment: ai je un autre choix que de creer un outil de refactoring qui va analyser le code, extraire le code de la méthode statique, le transformer de façon à ce que ça colle avec les notions EJB, etc... ou alors dois-je passer mes jours et mes nuits pour faire cela a la main avec toutes les risques d'erreurs que cela implique?
Ce que je recherche, c'est un retour d'experience et/ou de la documentation, des outils, etc..

Et est-ce que refactorer le code pour passer tes services statiques métier à Spring (qui se reposerait sur Java EE/JPA) plutôt qu'aux EJB est une solution envisageable ?

Je pense que le coût de refactoring serait bien moins élevé.

J'avais une application Swing+JDBC que j'ai tranformée en Applet Swing + jdbc via internet. Puis en ce moment, je travaille sur un client GWT qui fait des appels REST vers le serveur.

Mes objets métiers sont les mêmes côté client et serveur, cependant à travers le réseau, ils sont sérialisés/désérialisés à ma façon, à l'aide de xml customisé.

Par contre mes objets métiers ne sont pas des Entities. J'utilise des classes de types CRUD pour mapper mes objets métiers avec mes entities. C'est long :), mais facile à tester avec Junit, et donc à refactoriser/augmenter petit à petit.

Bonjour,

le choix technique étant fait, peut-être pourriez-vous nous clarifier quelques éléments:

- qu'entendez-vous par compatibilité EE/SE ? la même base de code doit être utilisée pour les deux?
Le passage en modèle EJB va être très impactant car la façon de travailler entre ces beans est assez différente. ( lookup JNDI par exemple )
- Est-ce que les deux types de clients vont travailler en même temps ( client web, client swing par exemple ) ? qu'est-ce qui sera commun aux deux, le cas échéant?
- Concernant les méthodes statiques, pourquoi ne pas simplement faire déléguer la méthode de traitement EJB à celle-ci ?

Séb

Nous avons eu a porter (ou plus exactement reecrire vu tout ce qui a changé) une application swing vers JSF.

se serait a refaire, je dirais tout de suite non. une aplication web ne vaut et ne vaudra jamais la qualité d'une application desktop et ca sur de nombre point : temps de developpement, rapidité, debuggage, taille, ergonomie...

Personnellement je conseil d'explorer la voie Java Web Start.

@fbaligand
Utiliser Spring aurait certainement ete une solution plus judicieuse mais le style ici est plutot "on code d'abord et on verra apres". Apres le cowboy coding, le cowboy designing :aie:. Je suis assez pessimiste sur l'issue de ce projet mais je sens que l'experience va etre assez interessante.
@Desboys
Pour l'instant, c'est un portage exacte du code de l'application Java SE vers Java EE, le resultat final etant un tronc commun ayant le meme source et les partie communication (RMI/Remote EJB) et Persistence(ORM maison/Entite EJB) separees par quelques interfaces judicieusement placees entre chaque couches.
L'utilisation des annotations permet d'avoir le meme code sans difficulte majeure. L'idee n'est pas suffisament louffoque pour que je puisse mettre mon veto. Cependant, sachant qu'il y a des appels a des composant Swing tel que JDialog dans le source des objets metiers, je sens que cela va etre tres chaud.

Le projet reste avec une application Swing cote client mais il n'est pas prevu de reutiliser le code client a l'identique:roll:.