-
1. Re: JBMETA-44, ws annotation processing for references
thomas.diesler May 30, 2008 2:55 AM (in response to starksm64)The cause of this problem may be that serviceRef.getAnnotatedElement() returns null.
The related issue probably is
http://jira.jboss.org/jira/browse/JBWS-2171 -
2. Re: JBMETA-44, ws annotation processing for references
starksm64 May 30, 2008 11:22 AM (in response to starksm64)Ok, were not populating this field. We still need some minimal processing of the ws annotations to pass annotated element through.
-
3. Re: JBMETA-44, ws annotation processing for references
starksm64 May 30, 2008 11:37 AM (in response to starksm64)So Thomas, to be clear, this annotated client and jboss-client.xml override should be producing a metadata ServiceReferenceMetaData with an getAnnotatedElement() pointing to te client field?
public class WSAppclient extends VehicleClient { @WebServiceRef(name="service/wsjwsdefaultwebservice") static com.sun.ts.tests.jws.webservice.webservice1.client.DefaultWebServiceService service = null; [532][valkyrie: jar]$ cat META-INF/jboss-client.xml <?xml version="1.0" encoding="UTF-8"?> <jboss-client version="5.0"> <jndi-name>WSDefaultWebServiceApp_wsappclient_vehicle_client</jndi-name> <service-ref> <service-ref-name>service/wsjwsdefaultwebservice</service-ref-name> <wsdl-override>http://localhost:8080/WSDefaultWebServiceApp/jws/defaultWebService?WSDL</wsdl-override> </service-ref> </jboss-client>
I don't know where this would have been populated previously. Its only populated for @Resource so I'm not sure has change here either. -
4. Re: JBMETA-44, ws annotation processing for references
thomas.diesler Jun 2, 2008 11:36 AM (in response to starksm64)yes, getAnnotatedElement() should be pointing to the client field
-
5. Re: JBMETA-44, ws annotation processing for references
aloubyansky Jun 12, 2008 5:43 AM (in response to starksm64)Another question related to JBMETA-44 and JBCTS-797. It's not clear to me how the @WebServiceRef should be mapped to ServiceReferenceMetaData.
What (if anything) in @WebServiceRef should specify the service-interface?
The current processing of @WebServiceRef isif(annotation.type() != Object.class) ref.setServiceRefType(annotation.type().getName()); else ref.setServiceRefType(getType(element)); if(annotation.value() != Object.class) ref.setServiceInterface(annotation.value().getName());
Is this correct? The example Scott posted above is from JBCTS-797 which currently fails because "service-interface is null".
Thanks. -
6. Re: JBMETA-44, ws annotation processing for references
thomas.diesler Jun 12, 2008 6:09 AM (in response to starksm64)This implementation can be assumed to be correct because it was used in AS500Beta4 to pass the tck.
Generally, Beta4 was good enough to pass all WS related sections -
7. Re: JBMETA-44, ws annotation processing for references
aloubyansky Jun 12, 2008 6:20 AM (in response to starksm64)Should there be a default value for the service-interface then?
In XSD this element is required, so with the deployment descriptors it will always be a non-null value. But in case of annotations with the current impl it may not be present, like in this case. -
8. Re: JBMETA-44, ws annotation processing for references
asoldano Jun 13, 2008 10:00 AM (in response to starksm64)Hi,
I'm looking at the JBWS-2171 failure too (and the related issue).
Still have to figure out what changed from AS500Beta4 in the behavior we had about service-interface null or not null.
In the mean time, just two considerations regarding JBWS-2171:
- it seems to me the @WebServiceRef / @WebServiceRefs annotations on class (type target) are not processed since the WebServiceRef processor is called on field annotations only
- having the serviceRef.getAnnotatedElement() != null prevents the code throwing the "<service-interface> cannot be null" exception from being executed, since the check that lead to that exception is performed when looking for the type of service ref (JAXWS or JAXRPC) and of course having an annotated element implies JAXWS. This just to say that error might also be misleading. -
9. Re: JBMETA-44, ws annotation processing for references
asoldano Jun 13, 2008 11:16 AM (in response to starksm64)"alex.loubyansky@jboss.com" wrote:
Should there be a default value for the service-interface then?
IMHO no.
Btw, I've just re-deployed the JBWS-2171 appclient in debug mode on AS500Beta4 and as I expected the service-interface attribute is null.The bind process doesn't fail because the annotatedElement is set, since this is a jaxws service ref. -
10. Re: JBMETA-44, ws annotation processing for references
asoldano Jun 13, 2008 11:33 AM (in response to starksm64)This said, here is the current implementation for finding out the serviceImplClass and targetClassName used for the bind (from NativeServiceRefBinderJAXWS):
String serviceImplClass = null; // #1 Use the explicit @WebServiceRef.value if (wsref != null && wsref.value() != Object.class) serviceImplClass = wsref.value().getName(); // #2 Use the target ref type if (serviceImplClass == null && targetClass != null && Service.class.isAssignableFrom(targetClass)) serviceImplClass = targetClass.getName(); // #3 Use <service-interface> if (serviceImplClass == null && serviceRef.getServiceInterface() != null) serviceImplClass = serviceRef.getServiceInterface(); // #4 Use javax.xml.ws.Service if (serviceImplClass == null) serviceImplClass = Service.class.getName(); // #1 Use the explicit @WebServiceRef.type if (wsref != null && wsref.type() != Object.class) targetClassName = wsref.type().getName(); // #2 Use the target ref type if (targetClassName == null && targetClass != null && Service.class.isAssignableFrom(targetClass) == false) targetClassName = targetClass.getName();
We have (#4) setting javax.xml.ws.Service as serviceImplClass when #1, #2 and #3 give no result. This imho hides an error, ie. not failing when @WebServiceRef.type is not set and the annotation has type (class) target. As a matter of fact, the javaee 5 doc says (https://java.sun.com/javaee/5/docs/api/javax/xml/ws/WebServiceRef.html):
type
public abstract Class type
The Java type of the resource. For field annotations, the default is the type of the field. For method annotations, the default is the type of the JavaBeans property. For class annotations, there is no default and this must be specified.
Thomas, do you have an opinion about this? I think this implementation is simply a bit looser, nothing more. -
11. Re: JBMETA-44, ws annotation processing for references
emuckenhuber Jun 17, 2008 11:34 AM (in response to starksm64)Following up this topic about annotation processing for WebServiceRef.
This also requires the processing of @HandlerChain? e.g.:@WebServiceRef @HandlerChain(file = "handler-chains.xml")
Where the file contains the handler-chains like this file: https://svn.jboss.org/repos/jbossws/framework/trunk/testsuite/test/java/org/jboss/test/ws/jaxws/handlerscope/jaxws-client-handlers.xml
Which would be represented by ServiceReferenceHandlerChainsMetaData?
I also looked briefly at processing ServiceReferenceHandlerMetaData, but this does not seem to be possible with annotations - or am i missing something?
Thanks,
Emanuel -
12. Re: JBMETA-44, ws annotation processing for references
asoldano Jun 17, 2008 4:42 PM (in response to starksm64)Hi Emanuel,
"emuckenhuber" wrote:
This also requires the processing of @HandlerChain? e.g.:@WebServiceRef @HandlerChain(file = "handler-chains.xml")
Where the file contains the handler-chains like this file: https://svn.jboss.org/repos/jbossws/framework/trunk/testsuite/test/java/org/jboss/test/ws/jaxws/handlerscope/jaxws-client-handlers.xml
Which would be represented by ServiceReferenceHandlerChainsMetaData?
I also looked briefly at processing ServiceReferenceHandlerMetaData, but this does not seem to be possible with annotations - or am i missing something?
Generally speaking this use case (@HandlerChain on a service ref) should of course be supported.
As far as I can see we don't have a testcase for this yet, thus I think I'll start creating one.
I'll look at this more in deep tomorrow. Need to understand whether the processing you talk about is actually required or not, since the jbossws service ref binder seems to use the UnifiedServiceRefMetaData's String handlerChain attribute and read directly the @HandlerChain from the annotated element you provide us. -
13. Re: JBMETA-44, ws annotation processing for references
emuckenhuber Jun 18, 2008 6:25 AM (in response to starksm64)"alessio.soldano@jboss.com" wrote:
Generally speaking this use case (@HandlerChain on a service ref) should of course be supported.
As far as I can see we don't have a testcase for this yet, thus I think I'll start creating one.
Okay - i have a prototype working for this.. just need to check again - maybe you can validate it then to make sure that i did not miss anything.
But ServiceReferenceHandlerMetaData cannot be defined over annotations just via the xml descriptors - right?
Thanks -
14. Re: JBMETA-44, ws annotation processing for references
asoldano Jun 18, 2008 10:08 AM (in response to starksm64)"emuckenhuber" wrote:
Okay - i have a prototype working for this.. just need to check again - maybe you can validate it then to make sure that i did not miss anything.
SureBut ServiceReferenceHandlerMetaData cannot be defined over annotations just via the xml descriptors - right?
Yes, I can confirm this.
The ServiceReferenceHandlerMetaData (which is mapped to the JBossWS SPI UnifiedHandlerMetaData) is for JAX-RPC handlers declared in the standard J2EE1.4 descriptor.
The ServiceReferenceHandlerChainMetaData (which is mapped to the JBossWS SPI UnifiedHandlerChainMetaData) is for JAX-WS handlers declared in the standard JavaEE5 descriptor.
We then have the handlerChain attribute of the JBossWS SPI UnifiedServiceRefMetaData which is for the <handler-chain> element in the JBoss JavaEE5 descriptor or the file attribute of @HandlerChain annotation.