Hot deploy EJB avec Spring dans JBoss

**Fladnag** · 11/01/2010, 14h33

Bonjour,

cela fait maintenant une bonne semaine que je parcours le net pour trouver une solution a mon problème sans réel succès. Cependant, je ne suis pas un pro de jboss et peut être que je ne cherche pas là où il faudrait.

Mon projet est constitué d'EJB avec Spring déployé dans un serveur JBoss.

Lorsque je démarre mon projet JBoss et que je déploie mon application, tout fonctionne bien, je peux accéder a mes EJB

Si je redéploie mon EAR (même sans changer une ligne de code), JBoss décharge (undeploy) l'application et la recharge (deploy) a nouveau.

Cependant, j'obtiens toujours une erreur ClassCastException ensuite lors de l'accès a mon EAR (methode getBean) :
java.lang.ClassCastException: $Proxy102 incompatible with mon.projet.XXXXInterne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
2010-01-11 14:17:12,603 DEBUG [org.springframework.beans.factory.support.DefaultListableBeanFactory] Returning cached instance of singleton bean 'DelegateXXXX'
2010-01-11 14:17:12,611 ERROR [org.jboss.ejb.plugins.LogInterceptor] EJBException in method: public abstract mon.projet.XXXXServiceRemote mon.projet.XXXXServiceHome.create() throws javax.ejb.CreateException,java.rmi.RemoteException, causedBy:
javax.ejb.EJBException: java.lang.ClassCastException: $Proxy102 incompatible with mon.projet.XXXXInterne
	at org.jboss.ejb.StatelessSessionEnterpriseContext.<init>(StatelessSessionEnterpriseContext.java:85)
	at org.jboss.ejb.plugins.StatelessSessionInstancePool.create(StatelessSessionInstancePool.java:49)
	at org.jboss.ejb.plugins.AbstractInstancePool.get(AbstractInstancePool.java:184)
	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invokeHome(StatelessSessionInstanceInterceptor.java:95)
	at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:145)
	at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:132)
	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:107)
	at org.jboss.ejb.SessionContainer.internalInvokeHome(SessionContainer.java:637)
	at org.jboss.ejb.Container.invoke(Container.java:981)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:615)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:818)
	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:419)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:615)
	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:309)
	at sun.rmi.transport.Transport$1.run(Transport.java:168)
	at java.security.AccessController.doPrivileged(AccessController.java:275)
	at sun.rmi.transport.Transport.serviceCall(Transport.java:164)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:506)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.handleRequest(TCPTransport.java:838)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:912)
	at java.lang.Thread.run(Thread.java:801)
Caused by: 
java.lang.ClassCastException: $Proxy102 incompatible with mon.projet.XXXXInterne
	at mon.projet.XXXXBean.onEjbCreate(XXXXBean.java:66)
	at mon.projet.EJBServiceBase.ejbCreate(EJBServiceBase.java:103)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:615)
	at org.jboss.ejb.StatelessSessionEnterpriseContext.<init>(StatelessSessionEnterpriseContext.java:78)
	... 31 more

On dirais donc que le "undeploy" de JBoss garde la référence de l'ancienne classe dans un ClassLoader. Comment supprimer ou vider ce cache ? (Je cherche a faire fonctionner un environnement de développement, pas de production)

J'ai également un deuxieme probleme :
actuellement mon projet est déployé sous forme d'un EAR (ou d'un dossier EAR, ca donne le meme résultat)

Idéalement, je voudrais pouvoir remplacer a chaud l'implémentation du code de certains EJB sans avoir a eteindre/redémarrer le serveur JBoss, voir meme sans avoir a faire les operation undeploy/reploy sur tout les EJB, mais uniquement l'EJB qui m'interesse (car il y a environ 100 EJB...)

Or actuellement, le seul moyen que j'ai trouvé pour que JBoss recharge mon projet, c'est la modification de META-INF/application.xml, ce qui a pour effet de recharger tout les EJBs.

Peut on faire mieux ?

Les détails techniques :
JBoss 4.2.2.GA
EJB 2.1
Spring 2.5

Merci d'avance ;o)

**troubleshooting** · 29/04/2010, 11h50

Même problème pour moi, as-tu trouvé une solution?

**Fladnag** · 29/04/2010, 12h12

Ca date un peu ^^

J'ai trouvé une demi solution oui...

Le probleme vient des différents caches géré par Tomcat et les produits annexes qui vont garder une implémentation de la classe différente (en interne, meme si elle n'a pas été modifiée) de celle que tu redéploie.

Il faut donc que ton application propose un moyen de vider TOUT ses caches et libérer toutes ses instances avant de faire le redeploy (ce qui revient presque a éteindre le serveur JBoss ;o)

Là ou j'avais le problème c'était notamment sur Spring puisqu'il cache les Bean.

Heureusement on peut vider le cache Spring en 2 étapes :
* Exposer Spring en JMX avec un mbean
* Utiliser JMX pour vider le cache Spring

Pour cela, il faut que tu ajoutes les lignes suivantes dans le beanRefContext.xml de ton application :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
    <!-- definition des BeanFactory -->
    <bean id="XXXXBeanFactory" class="org.springframework.context.support.ClassPathXmlApplicationContext">
        ...
    </bean> 
    <bean id="YYYYBeanFactory" class="org.springframework.context.support.ClassPathXmlApplicationContext">
        ...
    </bean>
 
    <!-- exposition de chaque BeanFactory en JMX -->
	<bean id="jmxExporter" class="org.springframework.jmx.export.MBeanExporter">
        <property name="beans">
            <map>
               <entry key="Application:name=XXXX"><ref bean="XXXXBeanFactory"/></entry> 
               <entry key="Application:name=YYYY"><ref bean="YYYYBeanFactory"/></entry> 
			   ...
            </map>
        </property>
    </bean>
</beans>

Une fois cela fait, si tu as acces a la console JMX et tu peux vider manuellement le cache (je ne me souviens plus du nom de la méthode parce que j'ai plus l'environnement démarré sous la main et que j'ai scripté son appel dans une tache Ant, mais c'était un nom explicite du genre "Clean" ^^)

**troubleshooting** · 29/04/2010, 13h42

Super, merci pour ces détails.

D'après ta réponse, j'imagine que les autres conteneurs EJButilisant tomcat auront ce problème non?

**Fladnag** · 29/04/2010, 14h39

Oui, apres il faut voir au cas par cas.

Nous avions également un cache interne a l'application qu'il a fallu exposer en JMX egalement pour pouvoir le clean, mais je crois qu'apres ca marchait relativement bien.

**troubleshooting** · 29/04/2010, 15h08

Ok, merci pour ces infos!

**Tristan107** · 10/08/2010, 16h43

Il y a peut-être plus simple...

J'avais la même erreur, mais en retirant l'ear ou le war de JBoss et en attendant le déchargement complet avant de poser le nouvel ear ou le nouveau war dans le répertoire deploy, il n'y a plus de problème.

**Fladnag** · 10/08/2010, 17h08

Dans le cas ou ton EAR fait 300Mo tu te prend 10mn dans la tête a chaque redeploy ?

Le but est bien de faire du HOT deploy, a savoir recharger uniquement une portion de l'application.

Je l'ai mis en place et ca fonctionne, il faut juste faire attention a avoir un MBean qui permet de vider les caches de l'application a chaque hot deploy

Hot deploy EJB avec Spring dans JBoss

Wildfly/JBoss Java

Discussions similaires

Partager

Partager