[
https://issues.jboss.org/browse/WFLY-1752?page=com.atlassian.jira.plugin....
]
Martin Kouba commented on WFLY-1752:
------------------------------------
First these are two completely different issues. And the stack trace is only related to
the second one (WebServiceResourceTest).
h3. ResourceDefinitionWithDifferentTypeTest
The CDI spec "3.7.1 Declaring a resource":
{quote}
If the matching object in the Java EE component environment is not of the same type as the
producer field declaration, the container automatically detects the problem and treats it
as a definition error.
{quote}
And currently a definition error is not thrown. I guess it's not possible to validate
the injection point correctly right now - see
{{org.jboss.as.weld.services.bootstrap.AbstractResourceInjectionServices.validateResourceInjectionPointType()}}.
Not sure if it's possible to fix it (but GF4 does it somehow ;-).
h3. WebServiceResourceTest
WildFly/CFX is really trying to invoke a no-args constructor the SheepWSEndPointService
doesn't declare. When looking at the JAX-WS spec (2.7 Service and Port) I think it
should (actually the number of required constructors differs in 2.0 and 2.2 versions). On
the other hand the JSR-109 (Web Services for Java EE, Version 1.4), section "4.2.2
javax.xml.ws.WebServiceRef annotation", states:
{quote}
For co-located clients (where the client and the server are in the same Java EE
application unit) with generated Service class, the location of the final WSDL document is
resolved by comparing the Service name on the @WebServiceClient annotation on the the
generated Service to the Service names of all the deployed port components in the Java EE
application unit...
{quote}
Also note that test passes on GF4 (as Jozef pointed out).
*The problem is we cannot provide a hard-coded WSDL location for our test.* I tried to fix
the SheepWSEndPointService to declare a public no-args constructor and supply some fake
WSDL location - does not work.
So we could either mark the assertion as non-testable and disable/delete the test or ask
some JAX-WS expert.
CDI TCK @WebServiceRef injection tests failing
----------------------------------------------
Key: WFLY-1752
URL:
https://issues.jboss.org/browse/WFLY-1752
Project: WildFly
Issue Type: Bug
Components: CDI / Weld, Web Services
Affects Versions: 8.0.0.Alpha3
Reporter: Jozef Hartinger
Assignee: Martin Kouba
Fix For: 8.0.0.Alpha4
{noformat}
org.jboss.arquillian.test.spi.ArquillianProxyException: org.jboss.wsf.spi.WSFException :
Cannot create service [Proxied because : Original exception not deserilizable,
ClassNotFoundException]
at org.jboss.wsf.spi.WSFException.rethrow(WSFException.java:55)
at
org.jboss.wsf.stack.cxf.client.serviceref.AbstractServiceObjectFactoryJAXWS.getObjectInstance(AbstractServiceObjectFactoryJAXWS.java:90)
at
org.jboss.wsf.stack.cxf.client.serviceref.CXFServiceRefFactoryImpl.newServiceRef(CXFServiceRefFactoryImpl.java:38)
at
org.jboss.as.webservices.webserviceref.WebServiceManagedReferenceFactory.getReference(WebServiceManagedReferenceFactory.java:37)
at
org.jboss.as.weld.services.bootstrap.ManagedReferenceFactoryToResourceReferenceFactoryAdapter.createResource(ManagedReferenceFactoryToResourceReferenceFactoryAdapter.java:41)
at
org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44)
at
org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53)
at org.jboss.weld.util.Beans.injectEEFields(Beans.java:348)
at
org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:59)
at
org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
at
org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
at
org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
at
org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:91)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:158)
at
org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:69)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:738)
at
org.jboss.weld.injection.producer.AbstractMemberProducer.getReceiver(AbstractMemberProducer.java:110)
at
org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:129)
at
org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:189)
at
org.jboss.weld.bean.builtin.ee.EEResourceProducerField.createUnderlying(EEResourceProducerField.java:149)
at
org.jboss.weld.bean.builtin.ee.EEResourceProducerField.access$000(EEResourceProducerField.java:53)
at
org.jboss.weld.bean.builtin.ee.EEResourceProducerField$EEResourceCallable.call(EEResourceProducerField.java:73)
at
org.jboss.weld.bean.builtin.CallableMethodHandler.invoke(CallableMethodHandler.java:45)
at
org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
at
org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:101)
at
org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.SheepWS$-1409013730$Proxy$_$$_Weld$Proxy$.isSheepInjected(Unknown
Source)
at
org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.WebServiceResourceTest.testResourceInvocation(WebServiceResourceTest.java:86)
Caused by: java.lang.InstantiationException:
org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.SheepWSEndPointService
at java.lang.Class.newInstance(Class.java:359)
at
org.jboss.wsf.stack.cxf.client.serviceref.AbstractServiceObjectFactoryJAXWS.instantiateService(AbstractServiceObjectFactoryJAXWS.java:241)
at
org.jboss.wsf.stack.cxf.client.serviceref.AbstractServiceObjectFactoryJAXWS.getObjectInstance(AbstractServiceObjectFactoryJAXWS.java:68)
... 128 more
{noformat}
The affected CDI TCK tests:
org.jboss.cdi.tck.tests.implementation.simple.resource.broken.type.ws.ResourceDefinitionWithDifferentTypeTest
org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.WebServiceResourceTest
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira