Help Desk Ticket Reference: https://access.redhat.com/issue-tracker/?module=issues&action=view&tid=1018343&gid=1354 project_key: SOA When a JAXB context is first initialised for the classes that will be marshalled to eliminate any reflection overhead strongly typed accessor classes are generated to access the fields of the classes and the classes are then defined using the current classloader. For SOA-P a lot of messages similar to the following are now reported: - 09:11:14,956 FINE [Injector] Unable to inject org/uddi/api_v3/GetAuthToken$JaxbAccessorF_cred java.lang.reflect.InvocationTargetException at sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.xml.bind.v2.runtime.reflect.opt.Injector.internalInject(Injector.java:180) at com.sun.xml.bind.v2.runtime.reflect.opt.Injector.inject(Injector.java:85) at com.sun.xml.bind.v2.runtime.reflect.opt.AccessorInjector.prepare(AccessorInjector.java:87) at com.sun.xml.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:165) at com.sun.xml.bind.v2.runtime.reflect.Accessor$FieldReflection.optimize(Accessor.java:253) at com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.<init>(TransducedAccessor.java:231) at com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor.get(TransducedAccessor.java:173) at com.sun.xml.bind.v2.runtime.property.AttributeProperty.<init>(AttributeProperty.java:87) at com.sun.xml.bind.v2.runtime.property.PropertyFactory.create(PropertyFactory.java:104) at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.<init>(ClassBeanInfoImpl.java:171) at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getOrCreate(JAXBContextImpl.java:491) at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:325) at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139) at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117) at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:188) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:130) at javax.xml.bind.ContextFinder.find(ContextFinder.java:289) at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:372) at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:337) at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:244) at org.apache.juddi.config.Install.buildInstallEntity(Install.java:568) at org.apache.juddi.config.Install.install(Install.java:93) at org.apache.juddi.config.AppConfig.getPersistentConfiguration(AppConfig.java:120) at org.apache.juddi.config.AppConfig.loadConfiguration(AppConfig.java:95) at org.apache.juddi.config.AppConfig.<init>(AppConfig.java:62) at org.apache.juddi.config.AppConfig.getInstance(AppConfig.java:183) at org.apache.juddi.config.AppConfig.getConfiguration(AppConfig.java:205) at org.apache.juddi.Registry.start(Registry.java:55) at org.jboss.internal.soa.esb.dependencies.JuddiRMIService.startService(JuddiRMIService.java:144) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:322) at sun.reflect.GeneratedMethodAccessor80.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:189) at $Proxy38.start(Unknown Source) at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42) at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37) at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:297) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553) at org.jboss.system.ServiceController.doChange(ServiceController.java:688) at org.jboss.system.ServiceController.start(ServiceController.java:460) at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163) at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99) at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46) at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50) at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171) at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179) at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553) at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782) at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702) at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117) at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70) at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53) at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:403) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540) at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:308) at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:256) at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461) at org.jboss.Main.boot(Main.java:221) at org.jboss.Main$1.run(Main.java:556) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.SecurityException: class "org.uddi.api_v3.GetAuthToken$JaxbAccessorF_cred"'s signer information does not match signer information of other classes in the same package at java.lang.ClassLoader.checkCerts(ClassLoader.java:807) at java.lang.ClassLoader.preDefineClass(ClassLoader.java:488) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:626) at java.lang.ClassLoader.defineClass(ClassLoader.java:616) at java.lang.ClassLoader.defineClass(ClassLoader.java:466) ... 99 more This is because the accessor being generated is being generated as an inner class of the class being marshalled, if this class is in a signed jar then the newly generated class is in the same package but unsigned so the SecurityException is thrown. JAXB will then fall back to using reflection so the optimisation is lost. Note - this only affects deployments where the marshalled classes are in signed jars, custom deployment of additional classes not signed will not be affected by this.
Is there a possibility of pregenerating these accessors in juddiv3 (Kurt Stam) as part of the SOA build? There is no solution to dynamic classes being generated under the same package as signed classes.
I don't believe JAXB does allow pre-generation of these accessors. Alternatively what issues would there be if the classes in the package 'org.uddi.api_v3' were in an unsigned jar? These classes are only used to be passed into the endpoint and not perform privileged actions so could they be left unsigned?
This will not be considered for soa-5.1.0
This issue was triaged for SOA 5.1, decision was to leave it in Future.
Link: Added: This issue depends JBWS-3267
RJW, reviewing old cases. Depends JBWS-3267, still valid.
Opened JBPAPP-8015 to bring this to EAP's attention.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: The JAXB Accessor Optimization disappears when using SOA-P supplied endpoints with signed jars. An exception is thrown and JAXB will fall back to using Reflection. As a result, optimization is lost.