views:

705

answers:

3

We have a number of web service client applications which interface between our main customer facing application and backend web services. These web service application generate their own JAXWS stub code to directly interface with the web services and implementation code to provide a clean interface between the JAXWS code and any application that wishes to use it. We've had some small problems with these over the last few weeks but most of them have been resolved.

When it was time to integrate these into the customer facing application we encountered numerous problems, mainly focused around JDK1.5 and 1.6 incompatibility. These have been resolved now, however we have hit another problem which we have no resolution for. The web service clients use AOP to set common things like header credentials, exception handling and throttling:

<aop:config>
    <aop:pointcut id="pointcut" expression="execution(* MyService.*(..))" />

    <aop:aspect id="throttling" ref="throttlingAdvisor">
        <aop:around pointcut-ref="pointcut" method="doThrottle" />
 </aop:aspect>
    <aop:aspect id="errorHandling" ref="errorHandlingAdvisor">
        <aop:around pointcut-ref="pointcut" method="handleExceptions" />

Each aspect refers to a POJO bean, these beans include the method stated in the configuration with the method parameter type of org.aspectj.lang.ProceedingJoinPoint, this is used to extract the arguments of the method I'm intercepting.

We have one of these for each of the web service clients (in an applicationContext-webservicename.xml). This xml file is included in the packaged JAR which is included in the customer facing application and imported into the main applicationContext.xml loaded by the web.xml of the customer facing application.

We have a number of unit tests for these web clients, they all pass proving there's nothing wrong with them individually. When all the services are included in the customer facing applications we get a java.lang.NoClassDefFoundError: ProceedingJoinPoint exception when it starts up (we're using tomcat 5.5 with JDK1.5.0_17).

I looked up the JavaDoc for java.lang.NoClassDefFoundError just in case it had a special meaning, looks like the JVM thinks the class does not exist. I then looked for the jar which contains the classes it's claiming it cannot find (aspectjrt-1.5.4.jar and aspectjweaver-1.5.4.jar), there is a duplication of these classes so I tried removing each jar in turn to see what would happen, exactly the same error.

Am I missing a required dependency? Is there a common cause to this problem (I've searched for this yesterday not finding much)? Any help would be most appreciated.

A: 

Could be a class loader issue. Where are the AspectJ JARs? If you have them in your WEB-INF/lib now, perhaps you could try copying them to the Tomcat common/lib and see if that helps.

It could be that the app server class loader needs them on startup, but the application class loader hasn't gotten them from WEB-INF because it's lower in the class loader hierarchy.

duffymo
Thanks for your quick reply, I tried moving them to common/lib it had no affect. I also tried moving them to server/lib which caused another problem java.lang.NoClassDefFoundError: org/aspectj/weaver/reflect/ReflectionWorld$ReflectionWorldException.
Jonnie
A: 

Only add aspectjrt.jar to the server/lib folder, NOT the aspectjweaver.jar. Duplicate classes can also lead to confusion. The runtime jar (the "rt" stands for runtime) is supposed for the runtime. The weaver jar is used for compile/weave time. Are you using LTW or CTW?

mhaller
I'm using LTW - there's no special weaving done when Maven builds the jars.
Jonnie
A: 

After all this time we managed to find the solution to this problem, we use Bamboo to build our projects when a SVN commit is detected. Although the bamboo environment was set up to match our development machines when it built a dependent project it produced this weird problem.

We're still not sure why it did this, however in the meantime we're manually building and deploying this particular project.

My advice to anyone experiencing a similar problem, just isolate yourself from internal maven repos and rebuild all your projects locally.

Thanks for everyone's help.

Jonnie