(Spring avec servlet+JSP) et AspectJ?

Version imprimable

03/07/2010, 23h51
Annsen

(Spring avec servlet+JSP) et AspectJ?

Bonjour!
J'utilise spring depuis peu. Ma question concernant l'architecture de mon application:
J'adapte une application web (anciennement conçue comme suit: daos + manager + servlets + JSP) au conteneur spring.
J'ai réadapté tous les daos et managers (framework JPA et Hibernate pour le mapping) et j'en suis à présent au servlets.

Est il possible de conserver les servlets en les considérant comme des objets de domaine et en les déclarant objet spring de scope "prototype" avec le framework AspectJ (comme je crois que cela peut se faire avec Spring pour les objets à instancier) ou est ce qu'il est non recommandé voir impossible de procéder de cette manière?
04/07/2010, 21h18
thebloodyman

Salut,

Si tu tiens vraiment à utiliser des servlets, tu peux les configurer comme des Beans Spring. Regarde du coté d'org.springframework.web.HttpRequestHandler.
C'est une interface à faire implémenter par tes servlets.
Par contre rien avoir avec les aspects.
06/07/2010, 13h23
Annsen

Merci bcp thebloodyman!
en fait je m'étais référée à http://www.developpez.net/forums/d64...p-servlet-jsp/
mais c'est le seul et unique avis que j'ai trouvé sur le sujet, c'est ce qui m'a inquiétée.
06/07/2010, 14h21
thebloodyman

J'ai lu le post.
En effet, ca ressemble au bazooka qui tue la mouche :aie:

Spring propose de nombreuses classes et interfaces pour répondre aux problématiques courantes rencontrées par ses utilisateurs.
Le @Configurable a son utilité mais davantage dans les cas atypiques ou Spring n'a pas prévu d'artefacts de contournement.
06/07/2010, 15h46
Annsen

Je viens peut être de trouver une solution:
le chargement manuel de l'applicationContext web ds les servlets avec:
WebApplicationContext wapc = WebApplicationContextUtils.getRequiredWebApplicationContext(this.getServletContext());
suivit de l'appel de beans:
NomManager nomManager = (NomManager )wapc.getBean("nomManager");
06/07/2010, 16h01
thebloodyman

oui c'est pas mal aussi:ccool:

La solution HttpRequestHandler est pertinente lorsque tu veux que ta servlet devienne un véritable bean Spring. Ca t'évite par exemple de devoir programmatiquement valoriser les dépendances dans ta servlet, ca te permet de faire du spring aop ou de l'autowired... etc...
06/07/2010, 18h05
Annsen

Merci!... et effectivement c'est un détail super important...! d'autant qu'on m'a conseillé de gérer les transactions depuis les managers avec les aspects.
12/07/2010, 13h30
Annsen

Nouveau problème: Inexplicable DuplicateMappingException

J'ai finalement procédé d'une manière à charger le contexte d'application de Spring au chargement du contexte de Servlet (avec l'écouteur de servlet fourni par Spring: ContextLoaderListener).

Structure de mon projet:
projet parent:
rien dedans excepté la version du projet et les dependency

projet core:
src/main/java
- Beans
- Daos
- Managers

src/main/ressources (tous était contenus dans le sous répertoire META INF autrefois, mais cela générait trop de DuplicateMappingException, un problème qui s'est réglé, je ne sais comment, lorsque le les ai sorti du META INF).
- les fichiers de mapping: .hbm.xml
- l'application-context-core
- le persistence.xml

src/test/java
- mes classes de test

src/test/ressources
- le databaseConnexion.properties (avec données de la bdd)
- le log4j pour les logger

Le projet core compile parfaitement, le jar est créé, les classes de test marchent bien.

projet web
src/main/java
rien pour le moment

src/main/ressources
mon databaseConnexion.properties que j'aurais voulu mettre dans src/test/ressources mais qui devient, je ne sais pour quelles raisons, inaccessible lorsqu'il s'y trouve.

src/test/java
src/test/ressource
vides

src/main/webapp
/WEB-INF
/jsp
-2jsp
applicationContext-web.xml (qui ne fait qu'importer l'application-context-core)
web.xml qui contient le contextLoaderListener.

Comme je le disais la compilation du core se passe très bien mais lors de la compilation du web (+tentative de déploiement avec jetty) j'ai à tous les coup des DuplicateMappingException des objets du core. Un peu comme si le mapping se chargeait deux fois... je me suis demandée si c'était par hasard le context spring qui était chargé une fois, puis chargé à nouveau lors du chargement du context de servlet... bref c'est une erreur que je ne m'explique pas.
Donc voila si cette erreur parle à quelqu'un je serais très heureuse de pouvoir bénéficier de son avis!
The Bloodyman...?
12/07/2010, 19h26
thebloodyman

Salut,

Pour info, dans tes projets Maven, fais bien attention à l'orthographe du dossier resources . Il n'y a qu'un 's'.
Ça peut expliquer des ressources non prises en considération parfois.

Citation:

(tous était contenus dans le sous répertoire META INF autrefois, mais cela générait trop de DuplicateMappingException, un problème qui s'est réglé, je ne sais comment, lorsque le les ai sorti du META INF).

La convention JPA est d'utiliser META-INF. Avant de changer l'emplacement des ressources jpa,tu choppais la même exception.
Pourquoi ne pas essayer de résoudre le prob au niveau du core ? C'est un scope déja plus restreint ! ;)

Citation:

src/main/ressources
mon databaseConnexion.properties que j'aurais voulu mettre dans src/test/ressources mais qui devient, je ne sais pour quelles raisons, inaccessible lorsqu'il s'y trouve.

Si databaseConnexion.properties dans src/test/resources est inaccessible a l'exécution,c'est normal puisque tout ce qui est dans src/test/ n'est pas inclus dans le war.

Pour ton exception, la comme ca j'ai pas de réponse.
Il y a plusieurs causes possibles.
Mais je ne pense pas que cela soit un problème de Spring.
Ma fois, monte le niveau de log pour Spring et Hibernate et regarde ce qui se passe (les doubles traitements ou duplications possibles).

Citation:

j'ai à tous les coup des DuplicateMappingException des objets du core

L'exception DuplicateMappingException peut avoir plusieurs causes : en général duplication de classe/entité ou duplication de propriétés
Le message d'exception complet est toujours mieux :aie:

Si c'est bien un prob de classe/entité, j'envisagerais 3 pistes :

Citation:

Un peu comme si le mapping se chargeait deux fois.

1.Ca peut-être un prob de cache de jetty.
Vérifie que ton jetty déploie l'appli web vers un dossier temporaire vierge.

2.Si tu utilises à la fois des annotations et des hbm, ca peut être un prob si le
le persistence.xml n'est pas configuré en conséquence (je ne peux pas te donner + d'infos, j'ai jamais bossé avec ce genre de config) .

3.Si tu utilises que des hbm, je te proposerais d'inspecter le war qui est généré
pour comprendre d'où vient le prob.
Décompresse ton war et essaye de voir si t'aurais pas 2 hbm pour les mêmes entités, voir 2 persistence.xml.
N'hésite pas à décompresser chaque jar suspect à l'intérieur de ton war si nécessaire ou de faire des recherches sur l'ensemble des ressources décompressées.
12/07/2010, 23h07
Annsen

ThebloodyMan merci beaucoup pour toutes ces pistes!
Je vais toutes bien les creuser. Finalement je ne bouge pas de ce post, tu es de trop bon conseil.:ccool:

oui d'ailleurs des précisions sur l'erreur:

Code:

1
2
2010-07-12 17:47:38.339::WARN:  Failed startup of context org.mortbay.jetty.plugin.Jetty6PluginWebAppContext@d6ee28{/,D:\FieldforceManagement\ffm-parent\ffm-web\src\main\webapp}
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'addressFactory': Injection of persistence fields failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in class path resource [application-context-core.xml]: Invocation of init method failed; nested exception is org.hibernate.DuplicateMappingException: Duplicate collection role mapping net.atos.ffm.hibernate.ContactType.clientContacts

... et ce qui s'en suit:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
at org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.postProcessAfterInstantiation(PersistenceAnnotationBeanPostProcessor.java:311)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:959)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:472)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380)
	at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264)
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:164)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:429)
	at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:728)
	at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:380)
	at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:255)
	at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:199)
	at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:45)
	at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548)
	at org.mortbay.jetty.servlet.Context.startContext(Context.java:136)
	at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1234)
	at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
	at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:460)
	at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:124)
	at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
	at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
	at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
	at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
	at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
	at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
	at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
	at org.mortbay.jetty.Server.doStart(Server.java:222)
	at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
	at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132)
	at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:384)
	at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:320)
	at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:205)
	at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184)
	at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:579)
	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:498)
	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265)
	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191)
	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149)
	at org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223)
	at org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1)
	at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:904)
	at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304)
	at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:63)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
	at org.codehaus.classworlds.Launcher.main(Launcher.java:31)