Discussion :

[Yux]

Bonjour,

Je débute avec Spring et je cherche à réaliser une application Spring MVC.

Au niveau de l'architecture de l'application, je souhaite packager dans un jar toute la logique métier et également la couche d'accès aux données. Je souhaite embarquer ce jar dans le war de mon application web.

Mon problème est que j'utilise Spring dans toutes les couches de l'application, et j'ai du mal à définir la meilleure approche concernant le contexte Spring. Faut-il créer un applicationContext.xml unique sous WEB-INF ou dois-je créer un fichier de contexte "autonome" pour le jar, sachant qu'à priori c'est faisable techniquement (j'ai lu un post de Julien Dubois à ce sujet mais je ne parviens pas à remettre la main dessus pour le moment...).

Voilà, si vous pouvez m'aider sur cette partie conception, ce n'est pas évident d'appréhender un framework aussi riche techniquement que Spring...

Merci pour vos futures réponses

[Tommy31]

La déclaration des dao peut se faire dans le jar. C'est pas plus mal ainsi.
C'est ce qui se fait implicitement si tu utilise le mécanisme déclaratif par annotations.

Mais même si tu n'opte pas pour une ventilation des déclarations de contexte dans différents jar, il est fortement conseillé de découper le contexte par couche ou domaine : modèle, dao, service, controleur, sécurité, web. Donc plusieurs fichiers xml dans ton répertoire.

[djo.mos]

Salut,

Mon problème est que j'utilise Spring dans toutes les couches de l'application, et j'ai du mal à définir la meilleure approche concernant le contexte Spring. Faut-il créer un applicationContext.xml unique sous WEB-INF ou dois-je créer un fichier de contexte "autonome" pour le jar, sachant qu'à priori c'est faisable techniquement (j'ai lu un post de Julien Dubois à ce sujet mais je ne parviens pas à remettre la main dessus pour le moment...).

Je serais curieux de voir comment tu pourrais faire celà, i.e. créer un AppCtxt autonome par jar ?
Par exemple, comment pourras tu créer l'appCtxt du jar des services alors qu'ils dépendent des DAOs définis dans un autre appCtxt dans le jar des DAOs ?

Perso, je procède par annotations : j'annote les différentes briques (DAOs, Services, Controllers), puis dans le war de l'application je définis un appCtxt où j'active le scan du classpath avec un package de base adéquat, et y ajoutant la défnition des DataDources et autre paramètres globaux, et hop, Spring me fait le wiring de tout ça

[Tommy31]

Je serais curieux de voir comment tu pourrais faire celà, i.e. créer un AppCtxt autonome par jar ?
Par exemple, comment pourras tu créer l'appCtxt du jar des services alors qu'ils dépendent des DAOs définis dans un autre appCtxt dans le jar des DAOs ?

C'est possible, cependant je ne l'ai jamais fait. En fait, tu définis un fichier xml de descriptif de contexte dans chaque jar, sous un espace de nommage distinct.

Le lien, tu le fais dans l'application qui créé le contexte et qui référence l'ensemble des resources de contexte du classpath. Le conteneur résout alors les dépendances sur cette connaissance.

Les noms de bean déclarés dans un jar doivent être les mêmes que ceux définissant l'injection, bien sur.

Perso, je procède par annotations : j'annote les différentes briques (DAOs, Services, Controllers), puis dans le war de l'application je définis un appCtxt où j'active le scan du classpath avec un package de base adéquat, et y ajoutant la défnition des DataDources et autre paramètres globaux, et hop, Spring me fait le wiring de tout ça

Ca être le mieux

[Yux]

Salut, merci pour vos réponses.

Si je comprends bien, un seul applicationContext.xml pour le war, avec scan des packages et autowiring des classes annotées. J'étais aussi parti là-dessus, mais je trouvais un peu bizarre de packager des classes Spring dans un jar sans leur associer un fichier de contexte. Enfin, c'est personnel...

[julien.dubois]

Ce qui est couramment fait est de :
- Séparer sa conf dans plusieurs fichiers xml -> on a ainsi une configuration pour chaque couche.
- Par contre, au runtime, il y a un ApplicationContext pour la couche métier, et un ApplicationContext (enfant du premier) pour Spring MVC.
-> pour la couche métier, les différents fichiers sont fusionnés et ne donnent qu'un ApplicationContext.

Ceci dit :
- Il y a en effet des clients qui font un ApplicationContext par couche. De mon point de vue c'est un peu compliqué, il suffit de faire un découpage par fichier pour avoir une conf propre (même si au runtime ils sont fusionnés)
- dm server fait ce genre de chose, d'un certain côté : chaque bundle OSGi a son propre ApplicationContext. Donc cela reprend ton idée.

[Yux]

Julien, merci pour cette réponse détaillée

Je passe en résolu.