ClassCastException al convertir a la misma clase

Question

Tengo 2 proyectos diferentes de Java, uno tiene 2 clases: dynamicbeans.DynamicBean2 y dynamic.Validator.

Por otro proyecto, me carga tanto de estas clases de forma dinámica y almacenarlos en una Object

class Form { 
    Class beanClass; 
    Class validatorClass; 
    Validator validator; 
} 

entonces seguir adelante y crear un objeto Validator usando validatorClass.newInstance() y lo almacena en validator entonces crear un grano objeto también usando beanClass.newInstance() y agréguelo a la sesión.

portletRequest.setAttribute("DynamicBean2", bean); 

Durante el ciclo de vida del proyecto Form, me llaman validator.validate() que carga el objeto bean previamente creado a partir de la sesión (Estoy corriendo Websphere Portal Server). Cuando intento devolver este objeto a DynamicBean2, falla con ClassCastException.

Cuando me tire el objeto de nuevo fuera de la sesión utilizando

faces.getApplication().createValueBinding("#{DynamicBean2}").getValue(faces); 

y comprobar la clase de ella usando .getClass() consigo dynamicbeans.DynamicBean2. Esta es la clase en la que quiero lanzarla; sin embargo, cuando intento, obtengo ClassCastException.

¿Alguna razón por la que estoy recibiendo esto?

Answer 1

No estoy siguiendo exactamente su descripción del flujo de programa, pero generalmente cuando obtiene ClassCastExceptions no puede explicar que ha cargado la clase con un cargador de clases y luego intenta convertirlo a la misma clase cargada por otro cargador de clases. Esto no funcionará; están representados por dos objetos de Clase diferentes dentro de la JVM y el lanzamiento fallará.

Hay un article about classloading in WebSphere. No puedo decir cómo se aplica a su aplicación, pero hay varias soluciones posibles. Puedo pensar al menos en:

1. Cambie el cargador de clases de contexto manualmente. Requiere que realmente pueda obtener una referencia a un cargador de clases apropiado, lo que puede no ser posible en su caso.

   Thread.currentThread().setContextClassloader(...); 
   

2. Asegúrese de que la clase está cargado por un cargador de clase superior en la jerarquía.

3. Serializar y deserializar el objeto. (¡Yuck!)

Sin embargo, probablemente exista una forma más adecuada para su situación particular.

Answer 2

Los objetos de clase se cargaron en diferentes cargadores de clases, por lo tanto, las instancias creadas desde en cada una de las clases se consideran 'incompatibles'. Este es un problema común en un entorno donde se usan muchos cargadores de clases diferentes y se están pasando objetos. Estos problemas pueden surgir fácilmente en Java EE y entornos de portal.

La emisión de una instancia de una clase requiere que la clase vinculada al objeto que se va a transmitir sea la misma que la cargada por el cargador de clases de contexto de hilo actual.

Answer 3

Obtuve el problema A2AClassCastException al intentar crear una lista de objetos desde XML utilizando Apache Commons Digester.

List<MyTemplate> templates = new ArrayList<MyTemplate>(); 
Digester digester = new Digester(); 
digester.addObjectCreate("/path/to/template", MyTemplate.class); 
digester.addSetNext("/path/to/template", "add"); 
// Set more rules... 
digester.parse(f); // f is a pre-defined File 

for(MyTemplate t : templates) { // ClassCastException: Cannot cast mypackage.MyTemplate to mypackage.MyTemplate 
    // Do stuff 
} 

Como se indicó anteriormente, la causa es que el digestor no utiliza el mismo ClassLoader como el resto del programa. Ejecuté esto en JBoss, y resultó que commons-digester.jar no estaba en el directorio lib de JBoss, sino en el directorio lib de una aplicación web. Copiar el jar en mywebapp/WEB-INF/lib también resolvió el problema. Otra solución fue casll digester.setClassLoader (MyTemplate.class.getClassLoader()), pero se siente como una solución bastante fea en este contexto.

Answer 4

Tuve el mismo problema al usar varias instancias de JBoss en diferentes máquinas. Para mal, no me encontré con esta publicación antes.
Había artefactos desplegados en diferentes máquinas, dos de ellos cargadores de clases declarados con nombre idéntico. Cambié uno de los nombres del cargador de clases y todo funcionó bien => ¡Cuidado con la copia & Pegar!

¿Por qué la ClassCastException no menciona los cargadores de clase involucrados? - Creo que sería una información muy útil.
¿Alguien sabe si habrá algo como esto disponible en el futuro? Necesitar comprobar los cargadores de la clase de 20-30 artefactos no es tan agradable. ¿O hay algo que extrañé en el texto de excepción?

EDIT: edité el archivo META-INF/jboss-app.xml y cambié el nombre del cargador, la idea es tener un nombre único. En el trabajo, utilizamos el identificador de artefactos (único) combinado con la versión insertada por maven ({$ version}) durante la compilación.
Usar campos dinámicos es solo opcional pero ayuda si desea implementar diferentes versiones de la misma aplicación.

<jboss-app> 
    <loader-repository> 
    com.example:archive=unique-archive-name-{$version} 
    </loader-repository> 
</jboss-app> 

puede encontrar alguna información aquí: https://community.jboss.org/wiki/ClassLoadingConfiguration

Answer 5

que tenían el mismo problema, y ​​finalmente encontró una solución en java.net:

Copiar todos los archivos de org.eclipse.persistence jarglassfish4/glassfish/modules a WEB-INF/lib. Luego ingrese en su glassfish-web.xml y configure class-delegate en false.

¡Funcionó para mí!

Answer 6

Tuve un problema similar con JAXB y JBoss AS 7.1. El problema y la solución se describen aquí: javax.xml.bind.JAXBException: Class *** nor any of its super class is known to this context. La excepción que se dio fue org.foo.bar.ValueSet no se puede convertir a org.foo.bar.ValueSet

Answer 7

Tuve el mismo problema en un EJB de wildfly, el EJB devolvió una lista de objetos y tiene un control remoto y una interfaz local. Utilicé la interfaz local por error, lo que funcionaba bien hasta el momento en que intentas lanzar los objetos en la lista.

interfaz remota/local:

public interface DocumentStoreService { 

    @javax.ejb.Remote 
    interface Remote extends DocumentStoreService { 
    } 

    @javax.ejb.Local 
    interface Local extends DocumentStoreService { 
    } 

El bean EJB:

@Stateless 
public class DocumentStoreServiceImpl implements DocumentStoreService.Local, DocumentStoreService.Remote { 

La correcta envoltura de la primavera en todo el EJB:

<bean id="documentStoreService" class="org.springframework.ejb.access.LocalStatelessSessionProxyFactoryBean"> 
    <property name="jndiName" value="java:global/dpc/dpc-ejb/DocumentStoreServiceImpl!santam.apps.dpc.service.DocumentStoreService$Remote"/> 
    <property name="businessInterface" value="santam.apps.dpc.service.DocumentStoreService$Remote"/> 
    <property name="resourceRef" value="true" /> 
</bean> 

Nota del $ a distancia, puede cambiar esto a $ Local y encontrará la interfaz Local muy bien, y también ejecutará los métodos sin ningún problema (desde aplicación separada en el mismo contenedor), pero los objetos del modelo no se calculan y provienen de un cargador de clases diferente si utiliza la interfaz local por error.

Answer 8

Otra opción:

me pasó en WebLogic, pero supongo que puede suceder en otros servidores, así - si (solo) "Publicar" y por lo tanto algunas de las clases está recargado. En cambio, haz "Limpiar" para que todas las clases se vuelvan a cargar juntas.

Answer 9

Tuve el mismo problema con una búsqueda EJB de otro EJB. Resolví agregar @Remote (MyInterface.class) a la configuración de clase EJB