2 Replies Latest reply on Jul 12, 2013 9:03 AM by Tejas Mehta

    Speeding up Spring, coupled to JBoss

    Tejas Mehta Newbie

      Hello all,

       

      We, the Snowdrop Dev team, have been trying to speed up Spring's Component Scanning.

       

      Typically, Spring Applications make use of the context namespace to add beans to the Spring Container, example: <context:component-scan base-package="foo.bar"/>. In order to identify the beans it needs to initialize, Spring looks through the package and scans for @Component and its extensions. For packages with large number of Components, this process is fairly slow.

       

      The specific steps are as follows:

       

      After bootstrapping, the set of application components and service that need to be created are identified. AbstractbeanDefinitionReader will read resource definitions. DefaultListableBeanFactorywill be used as default bean factory based on bean definition objects.XmlBeanDefinitionReader.loadBeanDefinitions() load bean definitions from the specified XML file in which the BeanDefinitionParser will identify the context namespaces and parses the applicationContext xml. The resources are identified by the implementation of ResourcePatternResolver:, ie PathMatchingResourcePatternResolver in which the location patterns are found like an ant-style. Internally it uses ClassLoader.getResources(String name) method which returns an Enumeration containing URLs representing classpath resources. Then the ComponentScanBeanDefinitionParser will parse through the context definition nodes.

       

      It is this last step that we want to speed up and to do so we are attempting to leverage JBoss' Jandex module.

       

      At the start of deployment in JBoss, the Jandex module scans the classes and creates an Annotation Index. We would like to be able to utilize this Index to skip the scanning step and just initialize the pre-identified components.

       

      Potential Solution:

       

      Component-Scan within snowdrop's jboss namespace - https://github.com/snowdrop/snowdrop/tree/CustomBeanScanner:

      One option is to add our custom component scanner to snowdrop's namespace. So instead of <context:component-scan base-package="foo.bar"/>, the user would use: <jboss:component-scan base-package="foo.bar"/>.

       

      While this has the downside that the user has to change their application to make use of the feature, it forces the user to make a conscious decision.

       

      What do you think of this feature and of how it couples a Spring app with JBoss?  Is the intentional coupling worth the speed increase?

       

      Thanks in advance for the feedback,

       

      Tejas M. on behalf of the Snowdrop Team

        • 1. Re: Speeding up Spring, coupled to JBoss
          Ales Justin Master

          Don't we already have to setup some custom hook in web.xml, to handle our VFS?

          Or is that not needed anymore in AS7 / Wildfly.

           

          Is there a way to identify deployment with Spring in it -- w/o any custom JBoss files?

          (I used to do it via -spring.xml, afair :-))

           

          As I would rather have generic transparent usage for the users, then custom hook for every feature we need to plugin to.

          e.g. scanning is one thing, VFS is another, bytecode weaving, cross injection from MSC, ...

          1 of 1 people found this helpful
          • 2. Re: Speeding up Spring, coupled to JBoss
            Tejas Mehta Newbie

            As far as I know, there are almost no custom hooks required to handle our VFS with AS7/Wildfly, based on my experience with this example: https://github.com/jboss-jdf/jboss-as-quickstart/tree/master/kitchensink-spring/basic.

             

            So users are not required to use -spring.xml to deploy spring apps.

             

            Besides the custom hook, some of the options we looked into are AOP (too much configuration required on user's part) and javassist (not possible). We are now looking at Byteman, thanks to Vineet's suggestion. If we go this route then there would be no need for custom hooks, but would happen without users knowing, which may be a problem for some. What do you think?