Details

    • Steps to Reproduce:
      Hide

      This should apply to any application that matches the key points listed in the description:

      1.  EAR deployment
      2. sub deployment which uses a CXF annotation class
      3. org.apache.cxf dependency only declared at EAR level with export=true

      However, there is also a test app attached to the support case.

      Show
      This should apply to any application that matches the key points listed in the description:  EAR deployment sub deployment which uses a CXF annotation class org.apache.cxf dependency only declared at EAR level with export=true However, there is also a test app attached to the support case.

      Description

      When deploying an EAR file which has a sub deployment that uses CXF annotation classes a warning is logged that looks like this:

      WFLYWS0065: Annotation '@org.apache.cxf.interceptor.OutInterceptors' found on class 'de.comdirect.application.mt.wsexample.server.SimpleWsServiceWS'. Perhaps you forgot to add a 'org.apache.cxf' module dependency to your deployment?

      If you declare a dependency on org.apache.cxf in the sub-deployment, the warning is not logged.  However, if you declare the org.apache.cxf dependency at the EAR level with export=true you still get the message even though the CXF module should be visible.

      I tracked down the class org.jboss.as.webservices.deployers.WSClassVerificationProcessor located in the org/jboss/as/webservices/main/wildfly-webservices-server-integration-7.3.0.GA-redhat-00004.jar

      In this class there is a method which logs this message, plus an additional related method:

      private void verifyApacheCXFModuleDependencyRequirement(DeploymentUnit unit) {
      if (!hasCxfModuleDependency(unit))

      { CompositeIndex index = (CompositeIndex)unit.getAttachment(Attachments.COMPOSITE_ANNOTATION_INDEX); DotName[] dotNames = \{ DotNames.WEB_SERVICE_ANNOTATION, DotNames.WEB_SERVICE_PROVIDER_ANNOTATION }

      ;
      for (DotName dotName : dotNames) {
      for (AnnotationInstance ai : index.getAnnotations(dotName)) {
      AnnotationTarget at = ai.target();
      if (at instanceof ClassInfo) {
      ClassInfo clazz = (ClassInfo)ai.target();
      for (DotName dn : clazz.annotations().keySet()) {
      if (dn.toString().startsWith("org.apache.cxf"))

      { WSLogger.ROOT_LOGGER.missingModuleDependency(dn.toString(), clazz.name().toString(), "org.apache.cxf"); }

      }
      }
      }
      }
      }
      }

      private static boolean hasCxfModuleDependency(DeploymentUnit unit) {
      ModuleSpecification moduleSpec = (ModuleSpecification)unit.getAttachment(Attachments.MODULE_SPECIFICATION);
      for (ModuleDependency dep : moduleSpec.getUserDependencies()) {
      String id = dep.getIdentifier().getName();
      if (cxfExportingModules.contains(id))

      { return true; }

      }
      return false;
      }

      The hasCxfModuleDependency() method checks a list of dependencies called userDependencies looking to see if there is an "org.apache.cxf" entry in the list.

      However, there is more than one list of module dependencies which are part of moduleSpec.

      private final List<ModuleDependency> systemDependencies = new ArrayList();
      private final List<ModuleDependency> localDependencies = new ArrayList();
      private final List<ModuleDependency> userDependencies = new ArrayList();

      I think when you have an exported dependency from the EAR level it may be part of one of the other dependency lists rather than in userDependencies, so what we have is well-meaning code that tries to check and make sure you have the right dependency to support your annotation (because normally missing annotation classes just fail silently so a check is useful to have), but I think it doesn't check everywhere that it should.

      Since the EAP 7.3.1 patch just came out, I installed that and repeated the test but there was no difference.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  thofman Tomas Hofman
                  Reporter:
                  thofman Tomas Hofman
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  2 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: