[
https://issues.apache.org/jira/browse/CXF-2663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12831049#action_12831049
]
Craig Tataryn commented on CXF-2663:
------------------------------------
Did more digging, the null class is being added to the Set here:
http://fisheye6.atlassian.com/browse/cxf/tags/cxf-2.2.6/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/support/JaxWsServiceFactoryBean.java?r=890613#l531
Essentially the last class listed in the XmlSeeAlso annotation at runtime is
null.
I found a workaround: in the WSDLJar project I'm purposely excluding the
classes from the org/ and generated/ packages which were generated by the
cxf-codegen-plugin module (WSDLJar module) because these classes are already
generated by cxf-common-xsd in the XSDJar.
I don't understand why cxf-codgegen-plugin generates this package named
"generated", all of the files under that package are already contained in the
org.hl7.v3 package. But, when the Service Interface is created it wants to
list that ObjectFactory from "generated" packagewithin the XmlSeeAlso
annotation. At runtime it can't find that ObjectFactory so it is replaced with
null, and hence the Set winds up with a null entry.
Anyone have any clue why that package named generated is created?
I've attached a new patch which logs a warning and doesn't add the null class
to the Set.
> JAXBUtils.scanPackages - iterator returns null class
> ----------------------------------------------------
>
> Key: CXF-2663
> URL: https://issues.apache.org/jira/browse/CXF-2663
> Project: CXF
> Issue Type: Bug
> Components: Tooling
> Affects Versions: 2.2.6
> 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"
> Reporter: Craig Tataryn
> Attachments: CXF Linked Hashset Problem Breakpoint Dump.txt, CXF
> LinkedHashset problem.png, CXFSchemaRefProblem.zip, JAXBUtils null check.patch
>
>
> 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:
> {code}
> 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)
> {code}
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
