2011-04-18 6 views
1

je le code suivant:ClassCastException question

Object backingBean = facesContextHandler.getBackingBean("UserCredentialsBean"); 
UserCredentialsBean userCredentBean = (UserCredentialsBean) backingBean; 

Alors que je déboguer je suit dans mes expressions vue d'Eclipse:

backingBean.getClass() -> myPackage.UserCredentialsBean

backingBean instanceOf myPackage.UserCredentialsBean -> false

Donc le moulage ci-dessus échoue ...

Comment cela peut-il être?

Mise à jour: "symptôme" supplémentaire: Je reçois ce problème après expiration de la session

Toutes les idées?

+0

Avez-vous une trace de pile? –

+0

Comment l'aide de trace de pile ??? –

+0

Je pense qu'il pourrait être utile d'avoir une trace de pile. Il est possible que l'OP ait manqué quelque chose dans son analyse, ou peut-être qu'il y ait plus de détails quelque part ... Plus d'infos, meilleure chance que quelqu'un puisse aider –

Répondre

4

Question intéressante. Je ne peux penser qu'à deux possibilités.

1- Objet nul. instanceOf échoue généralement pour un objet nul. Assurez-vous simplement que le bean est initialisé.

Problème de chargeur de classe. Si deux objets de même classe sont chargés par deux chargeurs de classe différents, alors instanceOf échouera.

Ce n'est pas une liste tout compris, juste deux choses que je pouvais penser.

+0

backingBean n'est pas nul. Eclipse affiche ses attributs en tant qu'objet UserCredentialsBean avec des données remplies. –

+0

En ce qui concerne le problème de chargeur de classe ... Je devrais penser à comment cela pourrait se produire n'importe quel problème de ClassLoader. –

+0

Ensuite, vous devrez peut-être regarder dans le problème du chargeur de classe. C'est juste l'application JSF et vous essayez d'obtenir un bean backing dans votre applcation. ?? –

2

Problème lié à ClassLoader. Très probablement, l'application a été redéployée (une nouvelle instance de chargeur de classe a donc été créée), mais l'ancien objet est resté soit dans la session (disque sérialisé?), Soit en mémoire.

Le nom de la classe est le même, mais l'instance du chargeur de classe est différente. Instanceof examine le nom complet de la classe ET l'égalité des classloaders.

P.S. C'est en fait un problème assez commun. Il est souvent visible quand un thread de fond se réveille seulement pour découvrir que l'application a été redéployée, le classloader du thread est parti et ensuite il lance NoClassDefFound ou ClassCast au grand amusement des développeurs qui ne réalisent pas toujours qu'il s'agit en fait d'un zombie du déploiement précédent, et essayer de trouver un bug dans leur code.