1 2 Previous Next 26 Replies Latest reply on Jun 23, 2008 3:20 PM by asoldano

    JBMETA-44, ws annotation processing for references

    starksm64

      We seem to have gotten out of sync in terms of the reference metadata processing as tests that were passing previously now fail because the annotations are not being merged with jboss descriptor information. I assume this is because ws is now expecting that org.jboss.metadata.javaee.spec.ServiceReferenceMetaData coming in from the deployer layer has been build up from both annotations and descriptor information?

        • 1. Re: JBMETA-44, ws annotation processing for references
          thomas.diesler

          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

            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

              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&lt;/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

                yes, getAnnotatedElement() should be pointing to the client field

                • 5. Re: JBMETA-44, ws annotation processing for references
                  aloubyansky

                  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 is

                  if(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

                    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

                      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

                        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

                           

                          "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

                            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

                              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

                                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

                                   

                                  "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

                                     

                                    "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.

                                    Sure

                                    But 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.


                                    1 2 Previous Next