You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by "A. Rothman" <am...@amichais.net> on 2013/04/04 12:46:12 UTC
DOSGi - NullPointerException in Aegis when interface method declares
throws exception
Hi,
I'm getting an Aegis exception (stacktrace below) when trying to export
a service, using Oracle JDK 1.7.0_17, DOSGi 1.4.0, Karaf 2.3.1 (Aegis
Databinding 2.7.2). It looks similar to
https://issues.apache.org/jira/browse/CXF-3613, but that is closed as
fixed in 2.7.1. I also found mention of it in
http://mail-archives.apache.org/mod_mbox/cxf-dev/201301.mbox/%3C399BF167-4CDD-4E5C-B9CE-7DBDFC012074@apache.org%3E
from a few months ago but nothing further.
I tried debugging a bit, and it seems to fail when the service interface
has a method declaring a throws clause with an exception which is a
trivial Exception subclass (with no fields, just standard constructors).
Somewhere down the line of dependencies it reaches a java.lang.Class,
which has a field of type T[] named enumConstants, it tries to get the
base type for component type "T", which returns null, which causes the
exception.
So - is this the same issue? Should I open a new bug report for DOSGi or
CXF? Are there any updates on this? Workarounds? Anything I can do?
java.lang.NullPointerException
at java.lang.reflect.Array.newArray(Native Method)[:1.7.0_17]
at java.lang.reflect.Array.newInstance(Array.java:70)[:1.7.0_17]
at
org.apache.cxf.aegis.type.TypeUtil.getTypeRelatedClass(TypeUtil.java:261)[178:org.apache.cxf.cxf-rt-databinding-aegis:2.7.2]
at
org.apache.cxf.aegis.type.AbstractTypeCreator.createTypeForClass(AbstractTypeCreator.java:108)[178:org.apache.cxf.cxf-rt-databinding-aegis:2.7.2]
at
org.apache.cxf.aegis.type.AbstractTypeCreator.createType(AbstractTypeCreator.java:402)[178:org.apache.cxf.cxf-rt-databinding-aegis:2.7.2]
at
org.apache.cxf.aegis.type.basic.BeanTypeInfo.getType(BeanTypeInfo.java:192)[178:org.apache.cxf.cxf-rt-databinding-aegis:2.7.2]
at
org.apache.cxf.aegis.type.basic.BeanType.getDependencies(BeanType.java:534)[178:org.apache.cxf.cxf-rt-databinding-aegis:2.7.2]
at
org.apache.cxf.aegis.databinding.AegisDatabinding.addDependencies(AegisDatabinding.java:394)[178:org.apache.cxf.cxf-rt-databinding-aegis:2.7.2]
at
org.apache.cxf.aegis.databinding.AegisDatabinding.addDependencies(AegisDatabinding.java:399)[178:org.apache.cxf.cxf-rt-databinding-aegis:2.7.2]
at
org.apache.cxf.aegis.databinding.AegisDatabinding.addDependencies(AegisDatabinding.java:399)[178:org.apache.cxf.cxf-rt-databinding-aegis:2.7.2]
at
org.apache.cxf.aegis.databinding.AegisDatabinding.initializeMessage(AegisDatabinding.java:371)[178:org.apache.cxf.cxf-rt-databinding-aegis:2.7.2]
at
org.apache.cxf.aegis.databinding.AegisDatabinding.initializeOperation(AegisDatabinding.java:283)[178:org.apache.cxf.cxf-rt-databinding-aegis:2.7.2]
at
org.apache.cxf.aegis.databinding.AegisDatabinding.initialize(AegisDatabinding.java:242)[178:org.apache.cxf.cxf-rt-databinding-aegis:2.7.2]
at
org.apache.cxf.service.factory.AbstractServiceFactoryBean.initializeDataBindings(AbstractServiceFactoryBean.java:86)[165:org.apache.cxf.cxf-rt-core:2.7.2]
at
org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:475)[165:org.apache.cxf.cxf-rt-core:2.7.2]
at
org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:537)[165:org.apache.cxf.cxf-rt-core:2.7.2]
at
org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:249)[165:org.apache.cxf.cxf-rt-core:2.7.2]
at
org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:101)[172:org.apache.cxf.cxf-rt-frontend-simple:2.7.2]
at
org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:159)[172:org.apache.cxf.cxf-rt-frontend-simple:2.7.2]
at
org.apache.cxf.dosgi.dsw.handlers.AbstractPojoConfigurationTypeHandler.createServerFromFactory(AbstractPojoConfigurationTypeHandler.java:208)[56:cxf-dosgi-ri-dsw-cxf:1.5.0.SNAPSHOT]
at
org.apache.cxf.dosgi.dsw.handlers.PojoConfigurationTypeHandler.createServer(PojoConfigurationTypeHandler.java:118)[56:cxf-dosgi-ri-dsw-cxf:1.5.0.SNAPSHOT]
at
org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminCore.exportService(RemoteServiceAdminCore.java:119)[56:cxf-dosgi-ri-dsw-cxf:1.5.0.SNAPSHOT]
at
org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:64)[56:cxf-dosgi-ri-dsw-cxf:1.5.0.SNAPSHOT]
at
org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:58)[56:cxf-dosgi-ri-dsw-cxf:1.5.0.SNAPSHOT]
at java.security.AccessController.doPrivileged(Native
Method)[:1.7.0_17]
at
org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:58)[56:cxf-dosgi-ri-dsw-cxf:1.5.0.SNAPSHOT]
at
org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:37)[56:cxf-dosgi-ri-dsw-cxf:1.5.0.SNAPSHOT]
at
org.apache.cxf.dosgi.topologymanager.exporter.TopologyManagerExport.doExportService(TopologyManagerExport.java:249)[72:cxf-dosgi-ri-topology-manager:1.5.0.SNAPSHOT]
at
org.apache.cxf.dosgi.topologymanager.exporter.TopologyManagerExport.access$300(TopologyManagerExport.java:50)[72:cxf-dosgi-ri-topology-manager:1.5.0.SNAPSHOT]
at
org.apache.cxf.dosgi.topologymanager.exporter.TopologyManagerExport$3.run(TopologyManagerExport.java:214)[72:cxf-dosgi-ri-topology-manager:1.5.0.SNAPSHOT]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_17]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_17]
at java.lang.Thread.run(Thread.java:722)[:1.7.0_17]
Re: DOSGi - NullPointerException in Aegis when interface method declares
throws exception
Posted by "A. Rothman" <am...@amichais.net>.
Update: I think I found a temporary workaround: I changed the custom
exception to extend RuntimeException instead of Exception, and changed
the interface to declare throwing RuntimeException instead of the custom
exception, and now I no longer see this exception occurring. The reason
for using RuntimeException (rather than Exception) is so that the rest
of the code does not require any modification - only the exception class
and the interface are changed, and only those will need to be reverted
when a proper fix is released.
I hope this helps someone...