We ran into an issue this week which we think might be a Spring version incompatibility issue.  We have an EAR deployed a WebLogic S 9.2 instance and using Spring 2.0.3.  This app was working fine until we deployed the WSO2 Registry application. Suddenly we were getting class cast exceptions in another application when the EJB Initialized.  Specifically, it was happening in the Spring initialization. 

It appears as though WSO2 registry is utilizing Spring 1.2.7.  We have tried both applications on a different server instance and are getting the same results.  Below you can see part of the trace we get in our service.  The only place we can find this org.wso2.registry.jdbc.JDBCRegistry is in the war file of the registry app.
 
We have other applications with mix versions of Spring in the same WebLogic instance and we do not  have this problem. 

One theory we’ve been kicking around is that the Registry puts some stuff on ThreadLocal.  The thread goes back in the thread pool, then gets allocated to our other application request.  Spring looks for something on ThreadLocal and finds it and attempts to cast it without using an “instanceof” check.  This causes a class cast exception.

Invocation of init method failed; nested exception is java.lang.ClassCastException: org.wso2.registry.jdbc.JDBCRegistry

            at org.springframework.beans.factory.access.SingletonBeanFactoryLocator.useBeanFactory(SingletonBeanFactoryLocator.java:404)
           at company.util.springframework.factory.SpringBeanLocator.getBeanFactory(SpringBeanLocator.java:47)
           at company.webservice.spring.SpringUtil.getBeanFactoryInstance(SpringUtil.java:40)
           at company.endpoint.ejb.ServiceEndpointEJB.initialize(ServiceEndpointEJB.java:151)
           at company.endpoint.ejb.ServiceEndpointEJB.ejbCreate(ServiceEndpointEJB.java:81)
           at company.endpoint.ejb.serviceEndpointEJB_rovu6e_Impl.ejbCreate(serviceEndpointEJB_rovu6e_Impl.java:150)
           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 weblogic.ejb.container.pool.StatelessSessionPool.createBean(StatelessSessionPool.java:178)
           at weblogic.ejb.container.pool.StatelessSessionPool.getBean(StatelessSessionPool.java:105)
           at weblogic.ejb.container.manager.StatelessManager.preInvoke(StatelessManager.java:143)
           at weblogic.ejb.container.internal.BaseEJBObject.preInvoke(BaseEJBObject.java:213)
           at weblogic.ejb.container.internal.StatelessEJBObject.preInvoke(StatelessEJBObject.java:64)
           at company.jdf.endpoint.ejb.serviceEndpointEJB_rovu6e_EOImpl.executeRemote(serviceEndpointEJB_rovu6e_EOImpl.java:42)
           at company.jdf.endpoint.ejb.serviceEndpointEJB_rovu6e_EOImpl_WLSkel.invoke(Unknown Source)
           at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:550)
           at weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:224)
           at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:440)
           at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
           at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:147)
           at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:436)
           at weblogic.rmi.internal.BasicServerRef.access$300(BasicServerRef.java:58)
           at weblogic.rmi.internal.BasicServerRef$BasicExecuteRequest.run(BasicServerRef.java:975)
           at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
           at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)

 Has anyone seen anything like this before?