Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous

Identifiant
Mot de passe

Mot de passe oublié ?

Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Stratégie de migration d'une application Java SE vers une application Java EE

Avez vous des retours terrain ?

Le 26 septembre 2009 à 12:25, par psecheresse

28PARTAGES

Voter pour

0

Voter contre

0

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

Vous avez lu gratuitement 0 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Votre nom : Votre e-mail :

Décrivez l'erreur que vous souhaitez porter à notre connaissance :

Commenter Signaler un problème

Expert éminent sénior

Le 26/09/2009 à 21:40

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.

Voter pour

0

Voter contre

0

Membre à l'essai

Le 27/09/2009 à 1:14

Citation

Envoyé par sinok

Voir le message

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.

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..

Voter pour

0

Voter contre

0

Membre à l'essai

Le 07/10/2009 à 14:23

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é.

Voter pour

0

Voter contre

0

En attente de confirmation mail

Le 07/10/2009 à 19:12

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.

Voter pour

0

Voter contre

0

Membre averti

Le 07/10/2009 à 19:13

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

Voter pour

0

Voter contre

0

Rédacteur

Le 07/10/2009 à 22:20

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.

Voter pour

0

Voter contre

0

Membre à l'essai

Le 08/10/2009 à 7:20

@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

. 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

.

Voter pour

0

Voter contre

0

Commenter Signaler un problème