3 Replies Latest reply on Nov 15, 2008 4:04 PM by Ales Justin

    jboss-scanning.xml

    Ales Justin Master

      Moving this
      - http://lists.jboss.org/pipermail/jboss-development/2008-November/012965.html
      discussion here.

      How would this file look like?
      e.g.

      <scanning>
       <include path="org/jboss/acme/ejbs" filter="ant:*.*Bean"/>
       <include path="org/jboss/domain/hibernate" filter="regexp:<some-reg-exp>"/>
       <exclude path="org/jboss/logic"/>
       <exclude module="rules-impl.jar" />
      </scanning>
      

      Or what info should we expect from ScanningMetaData?

      ejb-jar.xml and web.xml are mentioned in ml discussion.
      How would we transform them into ScanningMetaData?



        • 1. Re: jboss-scanning.xml
          Adrian Brock Master

           

          "alesj" wrote:
          Moving this
          - http://lists.jboss.org/pipermail/jboss-development/2008-November/012965.html
          discussion here.

          How would this file look like?
          e.g.
          <scanning>
           <include path="org/jboss/acme/ejbs" filter="ant:*.*Bean"/>
           <include path="org/jboss/domain/hibernate" filter="regexp:<some-reg-exp>"/>
           <exclude path="org/jboss/logic"/>
           <exclude module="rules-impl.jar" />
          </scanning>
          



          That's a horrible syntax. If you really need to go beyond file/ant globbing
          for a file filter couldn't you have a seperate attribute to specify a different
          fitlerType="regexp"?


          Or what info should we expect from ScanningMetaData?


          Classes - with a short syntax for ease of use in some cases,
          e.g. including specific paths
          <scanning xmlns="urn:jboss:scanning:1.0">
           <path name="myejbs.jar">
          <!-- long form -->
           <classes>
           <include name="com.acme.foo.**"/>
           <exclude name="com.acme.foo.bar.*"/>
           </classes>
           </path>
          <!-- short form -->
           <path name="my.war/WEB-INF/classes" include="com.acme.foo.**"/>
          </scanning>
          


          How much of this you actually implement in the first version is upto you.
          The minimum would be a list of explicit paths to include (exclusion being the default).

          Also, the paths need to be able to handle "external jars",
          e.g. those referenced from the manifest


          ejb-jar.xml and web.xml are mentioned in ml discussion.
          How would we transform them into ScanningMetaData?


          metadata-complete (or pre javaee5 dds) means nothing is scanned
          <scanning xmlns="urn:jboss:scanning:1.0"/> <!-- nothing -->
          


          otherwise all the jars and all the classes are scanned
          <scanning xmlns="urn:jboss:scanning:1.0">
           <include name="**"/>
          </scanning>
          



          • 2. Re: jboss-scanning.xml
            Adrian Brock Master

             

            "adrian@jboss.org" wrote:

            That's a horrible syntax. If you really need to go beyond file/ant globbing
            for a file filter couldn't you have a seperate attribute to specify a different
            fitlerType="regexp"?


            It's a horrible syntax, because can you imagine explaining to an admin
            using a GUI consol e what "ant:*.*" means?

            You'd need a whole seperate wizard just to guide them through constructing a filter
            using point and click. ;-)

            • 3. Re: jboss-scanning.xml
              Ales Justin Master

              I've committed simple
              - ScanningDeploymentUnitFilter
              - ScanningMetaDataRecurseFilter
              - ScanningMetaDataResourceFilter

              I also fixed a small glitch in my GenericAnnotationResourceVisitor,
              removing lookup for super and interfaces unless explicitly asked,
              otherwise this can go past scanning metadata filter.

              "adrian@jboss.org" wrote:

              Also, the paths need to be able to handle "external jars",
              e.g. those referenced from the manifest


              I have a simple test where jar's manifest references ear's/lib jars.
              But this ear/lib jars are then scanned as part of top deployment (remember our urls issue in AnnEnvDeployer?).

              Can you think of any other test case that would check your 'external jars'?