[CXF-2663] JAXBUtils.scanPackages - iterator returns null class

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.2.6
• Fix Version/s: 2.2.7
• Component/s: Tooling

Environment

$ mvn --version
Apache Maven 2.2.1 (r801777; 2009-08-06 14:16:01-0500)
Java version: 1.6.0
Java home: D:\Program Files\IBM\RAD75\jdk\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows xp" version: "5.1 build 2600 service pack 3" arch: "x86" Family: "windows"

• Assignee: Daniel Kulp
• Reporter: Craig Tataryn
• Created: 05/Feb/10 21:30
• Updated: 23/Mar/10 02:59
• Resolved: 09/Feb/10 23:34

Description

When starting up my endpoint such that the JAXB classes referenced from the endpoints do not exist in the War project, but rather in a separate project on the classpath a strange issue occurs. Essentially the loop within JAXBUtils.scanPackages that loops over the "classes" Set will get a "null" Class from the set.

Attached is:
1) sample project
2) screen shot of the missing class element during a debug session
3) dump of a conditional breakpoint which logs the class name of the class within the loop until the class is null.
4) a possible patch to workaround the problem

To run the project and reproduce the problem:
1) unzip the attached project file
2) change directories to the Pom project, execute mvn clean install
3) change directories to the War project, execute mvn jetty:run
4) you should see a stacktrace similar to this:

2010-02-05 15:01:35.781::WARN:  Nested in org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'cspsEndpoint': Invocation of init method failed; nested exception is javax.xml.ws.WebServiceException: java.lang.NullPointerException:
java.lang.NullPointerException
        at org.apache.cxf.common.util.PackageUtils.getPackageName(PackageUtils.java:56)
        at org.apache.cxf.jaxb.JAXBUtils.scanPackages(JAXBUtils.java:742)
        at org.apache.cxf.jaxb.JAXBDataBinding.createJAXBContextAndSchemas(JAXBDataBinding.java:467)
        at org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:320)
        at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromWSDL(ReflectionServiceFactoryBean.java:432)
        at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:528)
        at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:278)
        at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:178)
        at org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:100)
        at org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:105)
        at org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:167)
        at org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:346)
        at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:259)
        at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:209)
        at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:404)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
        at java.lang.reflect.Method.invoke(Method.java:599)

The patch which is attached might just mask the real underlying problem. I'm not sure if the problem is because the Set is being modified as its being iterated over. I certainly couldn't find a place where that was happening, but who knows.