We Keep Coding

Spring Retryable annotation ClassNotFoundException

I would like to use #Retryable annotation for restTemplate. I've added:
<dependency>
<groupId>org.springframework.retry</groupId>
<artifactId>spring-retry</artifactId>
<version>1.2.1.RELEASE</version>
</dependency>
as well as #EnableRetry to config class. I've marked method:
restTemplate.exchange(url, HttpMethod.POST, request, String.class);
with (in a new thread)
#Retryable(maxAttempts=4,value=Exception.class,backoff=#Backoff(delay = 2000))
But I'm getting error from catalina:
27-Oct-2017 18:11:41.023 SEVERE [http-nio-8080-exec-1] org.apache.catalina.core.StandardContext.listenerStart Exception sending context initialized event to listener instance of class [org.springframework.web.context.ContextLoaderListener]
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.aop.config.internalAutoProxyCreator': Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.springframework.aop.aspectj.annotation.AnnotationAwareAspectJAutoProxyCreator]: Constructor threw exception; nested exception is java.lang.NoClassDefFoundError: org/aspectj/lang/annotation/Around
at
<ommitted>
Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.springframework.aop.aspectj.annotation.AnnotationAwareAspectJAutoProxyCreator]: Constructor threw exception; nested exception is java.lang.NoClassDefFoundError: org/aspectj/lang/annotation/Around
at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:154)
at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:89)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBeanFactory.java:1103)
... 61 more
Caused by: java.lang.NoClassDefFoundError: org/aspectj/lang/annotation/Around
at org.springframework.aop.aspectj.annotation.ReflectiveAspectJAdvisorFactory.<clinit>(ReflectiveAspectJAdvisorFactory.java:76)
at org.springframework.aop.aspectj.annotation.AnnotationAwareAspectJAutoProxyCreator.<init>(AnnotationAwareAspectJAutoProxyCreator.java:53)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:142)
... 63 more
Caused by: java.lang.ClassNotFoundException: org.aspectj.lang.annotation.Around
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1285)
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1119)
... 70 more
27-Oct-2017 18:11:41.038 INFO [http-nio-8080-exec-1] org.apache.catalina.core.ApplicationContext.log Closing Spring root WebApplicationContext
What I'm doing wrong ?
EDITED:
I moved a little bit forward. Found that Spring Retry makes use of AOP so I added:
<dependency>
<groupid>org.springframework</groupid>
<artifactid>spring-aop</artifactid>
<version>4.2.5.RELEASE</version>
</dependency>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjweaver</artifactId>
<version>1.8.8</version>
</dependency>
Now I'm getting different error:
27-Oct-2017 21:11:12.071 SEVERE [http-nio-8088-exec-5] org.springframework.web.servlet.DispatcherServlet.initServletBean Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'homeController' defined in file [(...)\HomeController.class]: Initialization of bean failed; nested exception is java.lang.NoClassDefFoundError: Could not initialize class org.springframework.aop.framework.ObjenesisCglibAopProxy
<ommitted>
Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.springframework.aop.framework.ObjenesisCglibAopProxy
at org.springframework.aop.framework.DefaultAopProxyFactory.createAopProxy(DefaultAopProxyFactory.java:60)
at org.springframework.aop.framework.ProxyCreatorSupport.createAopProxy(ProxyCreatorSupport.java:105)
at org.springframework.aop.framework.ProxyFactory.getProxy(ProxyFactory.java:109)
at org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.createProxy(AbstractAutoProxyCreator.java:468)
at org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.wrapIfNecessary(AbstractAutoProxyCreator.java:349)
at org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.postProcessAfterInitialization(AbstractAutoProxyCreator.java:298)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsAfterInitialization(AbstractAutowireCapableBeanFactory.java:421)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1558)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:539)
... 35 more
To isolate the problem I created small springMVC project and it's the same. To keep everything simple used only few dependencies. This is output from mvn dependency:tree:
[INFO] com.example:store:war:0.0.1-SNAPSHOT
[INFO] +- org.springframework:spring-webmvc:jar:4.0.3.RELEASE:compile
[INFO] | +- org.springframework:spring-beans:jar:4.0.3.RELEASE:compile
[INFO] | +- org.springframework:spring-context:jar:4.0.3.RELEASE:compile
[INFO] | +- org.springframework:spring-core:jar:4.0.3.RELEASE:compile
[INFO] | | \- commons-logging:commons-logging:jar:1.1.3:compile
[INFO] | +- org.springframework:spring-expression:jar:4.0.3.RELEASE:compile
[INFO] | \- org.springframework:spring-web:jar:4.0.3.RELEASE:compile
[INFO] +- javax.servlet:jstl:jar:1.2:compile
[INFO] +- javax.servlet:javax.servlet-api:jar:3.1.0:provided
[INFO] +- org.springframework.retry:spring-retry:jar:1.2.1.RELEASE:compile
[INFO] +- com.mashape.unirest:unirest-java:jar:1.4.9:compile
[INFO] | +- org.apache.httpcomponents:httpasyncclient:jar:4.1.1:compile
[INFO] | | +- org.apache.httpcomponents:httpcore:jar:4.4.4:compile
[INFO] | | \- org.apache.httpcomponents:httpcore-nio:jar:4.4.4:compile
[INFO] | +- org.apache.httpcomponents:httpmime:jar:4.5.2:compile
[INFO] | \- org.json:json:jar:20160212:compile
[INFO] +- org.springframework:spring-aop:jar:4.2.5.RELEASE:compile
[INFO] | \- aopalliance:aopalliance:jar:1.0:compile
[INFO] \- org.aspectj:aspectjweaver:jar:1.8.8:compile

It worked for me after adding the spring-boot-starter-aop dependency like below:
compile ("org.springframework.boot:spring-boot-starter-aop:1.5.10.RELEASE")

I will answer my own question 'cause it seems to be working now. All dependencies that are necessary:
<dependency>
<groupId>org.springframework.retry</groupId>
<artifactId>spring-retry</artifactId>
<version>1.2.1.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-aop</artifactId>
<version>4.3.11.RELEASE</version>
</dependency>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjweaver</artifactId>
<version>1.8.10</version>
</dependency>
check if there is no duplicate dependencies (f.e. by mvn dependency:tree, use <exclusions> where necessary). Be sure you decorated your config class with #EnableRetry. For some reason you need to separate the caller from the method itself. F.e.this:
#Retryable(maxAttempts = 4, value = {ResourceAccessException.class}, backoff = #Backoff(delay = 5000))
public ResponseEntity<String> tryToSendAndReturnResponseByRestTemplate(final RestTemplate restTemplate,
final HttpEntity<MyObjDTO>
request) {
return restTemplate.exchange(resolveUrl(ENDPOINT_ADDRESS), HttpMethod.POST, request, String.class);
}
goes to SenderManager class marked as f.e. #Service and in a different class f.e. PhoneDirector class you call:
senderManager.tryToSendAndReturnResponseByRestTemplate(restTemplate, request);
It should work. (If you need to specify what supposed to be returned if after 4 (only here) attempts you're still getting an exception, you can create another method (in SenderManager class) marked with #Recover, like this:
#Recover
public ResponseEntity<String> recoverWhenSendingMessageFailed(final ResourceAccessException e) {
return new ResponseEntity<>(e.getMessage(), HttpStatus.REQUEST_TIMEOUT);
}
But If you needed args from #Retryable (in #Recover method) remeber that arguments are populated from the argument list of the failed method in the same order as the failed method, and with the same return type

spring-retry uses spring aop, make sure you have aop added in your pom and try clean building the application.
for spring app :
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-aop</artifactId>
<version>4.1.4.RELEASE</version>
</dependency>
for spring boot :
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-aop</artifactId>
<version>2.0.3.RELEASE</version>
</dependency>

error 404 for rest service in netbeans, using tomcat7 and java JDK 8 [duplicate]

I am running a Maven project which is also a dynamic web project. I have used all Spring libraries in Maven. I created web.xml, but when I start my Tomcat 7 server I am getting the following message:
INFO: validateJarFile(C:\Users\mibvzd0\workspace\.metadata\.plugins\
org.eclipse.wst.server.core\tmp2\wtpwebapps\hapi_hl7\WEB-INF\lib\
servlet-api-2.4.jar) - jar not loaded.
See Servlet Spec 2.3, section 9.7.2. Offending class: javax/servlet/Servlet.class
I tried deleting the servlet from webapp/lib, but it didn't work. Let me know what should be done in my case.

The servlet API .jar file must not be embedded inside the webapp since, obviously, the container already has these classes in its classpath: it implements the interfaces contained in this jar.
The dependency should be in the provided scope, rather than the default compile scope, in your Maven pom:
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
<scope>provided</scope>
</dependency>

You get this warning message when the servlet api jar file has already been loaded in the container and you try to load it once again from lib directory.
The Servlet specs say you are not allowed to have servlet.jar in
your webapps lib directory.
Get rid of the warning message by simply removing servlet.jar from your lib directory.
If you don't find the jar in the lib directory scan for your build path and remove the jar.
C:\Program Files\Apache Software Foundation\Tomcat 7.0\webapps\project\WEB-INF\lib
If you are running a maven project, change the javax.servlet-api dependency to scope provided in you pom.xml since the container already provided the servlet jar in itself.

To fix it, set the scope to provided. This tells Maven use code servlet-api.jar for compiling and testing only, but NOT include it in the WAR file. The deployed container will “provide” the servlet-api.jar at runtime.
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>

You may find the following windows command line useful in tracking down the offending jar file. it creates an index of all the class files in all the jars in the folder. Execute from within the lib folder of your deployed app, then search the index.txt file for the offending class.
for /r %X in (*.jar) do (echo %X & jar -tf %X) >> index.txt

Maven Dependency Scope
provided : This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example,
when building a web application for the Java Enterprise Edition, you
would set the dependency on the Servlet API and related Java EE APIs
to scope provided because the web container provides those classes.
This scope is only available on the compilation and test classpath,
and is not transitive.

I've been struggling with this issue and I've tried numerous "solutions".
However, in the end, the only one that worked and it actually took a few seconds to do it was to: delete and add back new server instance!
Basically, I right clicked on my Tomcat server in Eclipse under Servers and deleted it. Next, I've added a new Tomcat server. Cleaned and redeployed the application and I got rid of this error.

Check Inside the Following Directory for the jar file el-api.jar :C:\apache-tomcat-7.0.39\lib\el-api.jar if it exists then in this directory of your web application WEB-INF\lib\el-api.jar the jar should be removed

when your URL pattern is wrong, this error may be occurred.
eg. If you wrote #WebServlet("login"), this error will be shown. The correct one is #WebServlet("/login").

Exclusions and provided dependencies will not work in child projects.
If you are using inheritance in Maven projects you must include this configuration on the parent pom.xml file. You will have a <parent>...</parent> section in your pom.xml if you are using inheritance. So you will have something like this in your parent pom.xml:
<groupId>some.groupId</groupId>
<version>1.0</version>
<artifactId>someArtifactId</artifactId>
<packaging>pom</packaging>
<modules>
<module>child-module-1</module>
<module>child-module-2</module>
</modules>
<dependencies>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet.jsp</groupId>
<artifactId>jsp-api</artifactId>
<version>2.1</version>
<scope>provided</scope>
</dependency>
</dependencies>

The JAX-WS dependency library “jaxws-rt.jar” is missing.
Go here http://jax-ws.java.net/.
Download JAX-WS RI distribution.
Unzip it and copy “jaxws-rt.jar” to Tomcat library folder “{$TOMCAT}/lib“.
Restart Tomcat.

Typically when you see this message, it is benign.
If it says
INFO: validateJarFile(/<webapp>/WEB-INF/lib/servlet-api-2.5.jar) - jar not loaded.
See Servlet Spec 2.3, section 9.7.2. Offending class: javax/servlet/Servlet.class
It means it is ignoring your servlet-api-2.5.jar because tomcat already has a built-in version of that jar, so it isn't going to be using yours. Typically this doesn't cause an issue.
If however it says WEB-INF/lib/my_jar.jar - jar not loaded...Offending class: javax/servlet/Servlet.class
then what you can do (in my instance, it's a shaded jar) is run
$ mvn dependency:tree
and discover that you have a transitive dependency on "something" that depends on a jar that is either servlet-api or something like it (ex: tomcat-servlet-api-9.0.0). So add an exclusion to that to your pom, ex: (in my case, tomcat, in your case, probably the ones mentioned in the other answers):
<dependency>
...
<exclusions>
<exclusion>
<groupId>org.apache.tomcat</groupId>
<artifactId>tomcat-servlet</artifactId>
</exclusion>
</exclusions>
</dependency>

from https://stackoverflow.com/a/9941668/778517
I did mvn dependency:tree and result was
(...)
[INFO] +- org.zkoss.zk:zkspring-core:jar:3.2.0:compile
[INFO] | +- org.springframework:spring-beans:jar:3.0.7.RELEASE:compile
[INFO] | +- org.springframework:spring-context:jar:3.0.7.RELEASE:compile
[INFO] | | \- org.springframework:spring-asm:jar:3.0.7.RELEASE:compile
[INFO] | +- org.springframework:spring-web:jar:3.0.7.RELEASE:compile
[INFO] | \- org.reflections:reflections:jar:0.9.5-RC2:compile
[INFO] | +- com.google.collections:google-collections:jar:1.0:compile
[INFO] | +- ch.qos.logback:logback-classic:jar:0.9.9:runtime
[INFO] | | \- ch.qos.logback:logback-core:jar:0.9.9:runtime
[INFO] | +- com.google.code.gson:gson:jar:1.4:compile
[INFO] | \- javax.servlet:servlet-api:jar:2.5:compile
(...)
so in pom.xml, zkspring-core I added the exclusions tag
(...)
<groupId>org.zkoss.zk</groupId>
<artifactId>zkspring-core</artifactId>
<version>3.2.0</version>
+ <exclusions>
+ <exclusion>
+ <groupId>javax.servlet</groupId>
+ <artifactId>servlet-api</artifactId>
+ </exclusion>
+ </exclusions>
</dependency>
(...)
after I ran mvn dependency:tree and javax.servlet:servlet-api:jar:2.5:compile is clean
(...)
[INFO] +- org.zkoss.zk:zkspring-core:jar:3.2.0:compile
[INFO] | +- org.springframework:spring-beans:jar:3.0.7.RELEASE:compile
[INFO] | +- org.springframework:spring-context:jar:3.0.7.RELEASE:compile
[INFO] | | \- org.springframework:spring-asm:jar:3.0.7.RELEASE:compile
[INFO] | +- org.springframework:spring-web:jar:3.0.7.RELEASE:compile
[INFO] | \- org.reflections:reflections:jar:0.9.5-RC2:compile
[INFO] | +- com.google.collections:google-collections:jar:1.0:compile
[INFO] | +- ch.qos.logback:logback-classic:jar:0.9.9:runtime
[INFO] | | \- ch.qos.logback:logback-core:jar:0.9.9:runtime
[INFO] | \- com.google.code.gson:gson:jar:1.4:compile
(...)

Remove servlet.jar from source web-inf/lib folder as it is available in tomcat lib folder then it works fine

Maven JdbcTemplate exclusion

I would like to use JdbcTemplate to query some very simple values:
String sql = "SELECT NAME FROM CUSTOMER WHERE CUST_ID = ?";
String name = (String)getJdbcTemplate().queryForObject(
sql, new Object[] { custId }, String.class);
So I added the flowing entry to my pom:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-jdbc</artifactId>
<version>4.3.7.RELEASE</version>
</dependency>
I see other Jars added
spring-tx-4.3.7.RELEASE.jar
spring-beans-4.3.7.RELEASE.jar
spring-core-4.3.7.RELEASE.jar
I would like to minimize the jar clash with the host application, and reduce my code footprint,
Out of this list what can I exclude and still letting JdbcTemplate work?

I won't disappoint you but ... none of them is excludable. All of the mentioned jars are needed.
You can check that out by visiting the dependency respository site itself. There you can find all of them (and even more) in the "Compile Dependencies" list.
Or execute mvn dependency:tree -Dverbose -Dincludes=org.springframework:spring-core,org.springframework:spring-tx,org.springframework:spring-beans inside the root of your project to verify it on your own.
The command should give you something like:
[INFO] \- org.springframework:spring-jdbc:jar:4.3.7.RELEASE:compile
[INFO] +- org.springframework:spring-beans:jar:4.3.6.RELEASE:compile (version managed from 4.3.7.RELEASE)
[INFO] | \- (org.springframework:spring-core:jar:4.3.6.RELEASE:compile - version managed from 4.3.7.RELEASE; omitted for duplicate)
[INFO] +- org.springframework:spring-core:jar:4.3.6.RELEASE:compile
[INFO] \- org.springframework:spring-tx:jar:4.3.6.RELEASE:compile (version managed from 4.3.7.RELEASE)
[INFO] +- (org.springframework:spring-beans:jar:4.3.6.RELEASE:compile - version managed from 4.3.7.RELEASE; omitted for duplicate)
[INFO] \- (org.springframework:spring-core:jar:4.3.6.RELEASE:compile - version managed from 4.3.7.RELEASE; omitted for duplicate)

Resolve duplicate versions of dependency

This has been very annoying. I have 2 projects, project A and B, B with dependency on A as a JAR file. So a 3rd library X in A has a dependency on another 3rd party library Y, the problem is maven resolves Y in project A to a version, but in project B to another version, like the following:
commons-beanutils:jar:1.9.2 vs. commons-beanutils:jar:1.8.0
And the version below is specified in project A:
net.sf.json-lib:json-lib:jar:jdk15:2.4
In the POM.xml of project B, there isn't really any explicitly specified version of dependencies.
In project A:
[INFO] +- net.sf.json-lib:json-lib:jar:jdk15:2.4:compile
[INFO] | +- commons-beanutils:commons-beanutils:jar:1.9.2:compile
[INFO] | +- commons-collections:commons-collections:jar:3.2.1:compile
[INFO] | \- net.sf.ezmorph:ezmorph:jar:1.0.6:compile
In project B that only introduces the dependency on Y because of A:
[INFO] +- A.jar
[INFO] | +- net.sf.json-lib:json-lib:jar:jdk15:2.4:compile
[INFO] | | +- commons-beanutils:commons-beanutils:jar:1.8.0:compile
[INFO] | | +- commons-collections:commons-collections:jar:3.2.1:compile
[INFO] | | \- net.sf.ezmorph:ezmorph:jar:1.0.6:compile
The ideal solution is to only make changes in pom.xml in project B to solve the duplicate versions dependency hell. Any idea? Thanks!
Is it possible to make project B inherit dependencies from A.jar instead of introducing those of its own.
EDIT
In the end I found something that worked, so I'd just put it here in case someone may be facing the same problem later.
The key is to put the dependencies come with project A into exclusions, so maven won't just use the versions of libraries defined in project A, but work out a version based on the current context. Below is the example:
<dependency>
<groupId>com.wonderland</groupId>
<artifactId>project-a</artifactId>
<version>1.0</version>
<exclusions>
<exclusion>
<groupId>commons-beanutils</groupId>
<artifactId>commons-beanutils</artifactId>
</exclusion>
<!-- ... everything else to be excluded -->
<exclusions>
</dependency>

Let me put the main points into an answer.
B is a war and depends on the jar A. So it inherits all the transitive dependencies of A.
net.sf.json-lib:json-lib:jar:jdk15:2.4:compile has actually a dependency on commons-beanutils:commons-beanutils:jar:1.8.0:compile (I looked that up). So your project B correctly resolves this dependency (and puts it into the war).
The tree of project A shows a dependency of commons-beanutils on version 1.9.2. This version number must have come from some other place inside project A. It may be a dependencyManagement, it may be some other dependency. Track down where the version 1.9.2 comes from and you know more.
In any case, the war will only contain the version 1.8.0 and not 1.9.2 as you can never have two artifacts with same groupId/artifactId in one war.

JPA Inheritance entitymanager.find produces ClassCastException

I have a class hierarchy like this:
#Entity
#Table (name="call_distribution_policies")
#Inheritance (strategy=InheritanceType.JOINED)
public class CallDistributionPolicy implements Serializable, Cloneable{
----------------
}
#Entity
#Table(name="skill_based_call_distribution_policies")
public class SkillBasedCallDistributionPolicy extends CallDistributionPolicy {
--------------
}
public class CallDistributionPolicyDAOJPAImpl extends
AbstractJPADAOImpl<CallDistributionPolicy> implements
CallDistributionPolicyDAO {
}
public CallDistributionPolicy get(long id) {
try {
Query query = entityManager
.createQuery("from CallDistributionPolicy where id = :id");
query.setParameter("id", id);
List<CallDistributionPolicy> resultList = query.getResultList();
if (!CollectionUtils.isEmpty(resultList)) {
return resultList.get(0);
}
return null;
} catch (EntityNotFoundException e) {
return null;
}
}
}
When I do this:
log.debug(" loaded: " + callDistributionPolicyDao.get(10).toString())
It prints the toString() of the SkillsBasedCallDistributionPolicy
But when I try to cast it like this:
SkillsBasedCallDistributionPolicy scdp = (SkillsBasedCallDistributionPolicy) callDistributionPolicyDao.get(10)
I get class cast exception.
com.vantage.callcenter.core.entity.acd.CallDistributionPolicy$$EnhancerByCGLIB$$334f3d1b cannot be cast to com.vantage.callcenter.core.entity.acd.SkillBasedCallDistributionPolicy
The instanceof check fails too!
When I inspect the object in eclipse, I see the CGLIB Proxy, but as far as I understand, the CGLIB proxy should extend the SkillsBasedCallDistributionPolicy class? In the CGLIB$CALLBACK_0 property, I can see the entity class is "CallDistributionPolicy" but the target is "SkillsBasedCallDistributionPolicy".
What should be the proper process of loading the Subclass? I can see hibernate is generating all the right SQL and loading the proper subclass, but how can I check the instanceof and cast it into a subclass?
I am using hibernate 3.2.1 , Spring 2.5.5 , cglib2.1_3. Any suggestions?

I know that this has been a problem in Hibernate during a long time, see for example:
ClassCastException cglib lazy loading
JPA: instanceof vs. hibernate proxy: when is it safe?
How to Avoid ClassCastExceptions when using Hibernate Proxied Objects)
And by problem, I mean bug, instanceof and casting should just work.
But I couldn't reproduce your issue with Hibernate 3.3.0.SP1. Both instanceof and casting to subclasses of a hierarchy using a joined strategy just worked. Tested with:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-cglib-repack</artifactId>
<version>2.1_3</version>
</dependency>
and
<dependency>
<groupId>javassist</groupId>
<artifactId>javassist</artifactId>
<version>3.8.0.GA</version>
</dependency>
I'm pretty sure there was a Jira issue for this, but couldn't find it.
The problem(bug) is consistent across my application. Can you post your working pom.xml here so I can see exactly what hibernate dependencies are you using?
Below the dependencies I used:
<project>
...
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.5.10</version>
</dependency>
</dependencies>
</dependencyManagement>
...
<dependencies>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
<version>3.4.0.GA</version>
<exclusions>
<exclusion>
<groupId>javassist</groupId>
<artifactId>javassist</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-cglib-repack</artifactId>
<version>2.1_3</version>
</dependency>
...
</dependencies>
</project>
Here is the dependency tree:
[INFO] +- org.hibernate:hibernate-entitymanager:jar:3.4.0.GA:compile
[INFO] | +- org.hibernate:ejb3-persistence:jar:1.0.2.GA:compile
[INFO] | +- org.hibernate:hibernate-commons-annotations:jar:3.1.0.GA:compile
[INFO] | +- org.hibernate:hibernate-annotations:jar:3.4.0.GA:compile
[INFO] | +- org.hibernate:hibernate-core:jar:3.3.0.SP1:compile
[INFO] | | +- antlr:antlr:jar:2.7.6:compile
[INFO] | | \- commons-collections:commons-collections:jar:3.1:compile
[INFO] | +- org.slf4j:slf4j-api:jar:1.5.10:compile
[INFO] | +- dom4j:dom4j:jar:1.6.1:compile
[INFO] | | \- xml-apis:xml-apis:jar:1.0.b2:compile
[INFO] | \- javax.transaction:jta:jar:1.1:compile
...
[INFO] \- org.hibernate:hibernate-cglib-repack:jar:2.1_3:compile