ActiveMQ
  1. ActiveMQ
  2. AMQ-2702

Localize Spring-related classes in a separate module

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 5.3.1
    • Fix Version/s: 5.9.0
    • Component/s: None
    • Labels:
      None

      Description

      We should try reducing Spring dependency on the broker core (and other modules) and move all Spring-related classes in a separate module.

      1. AMQ-2702.diff
        1 kB
        Gert Vanthienen

        Activity

        Hide
        Dejan Bosanac added a comment -

        rev 935952 introduced activemq-spring module and moved a few classes there. Incidentally activemq-pool module doesn't have spring dependency any more.

        The main question is what should we do with all tests in activemq-core (and other modules), that depends on Spring (and preventing us to do a better separation). IMHO we should move them either in this newly-created activemq-spring module or activemq-all module or even previously created sys test project. It will require some refactoring and probably make debugging a bit harder, but I think it's the move we have to make.

        Show
        Dejan Bosanac added a comment - rev 935952 introduced activemq-spring module and moved a few classes there. Incidentally activemq-pool module doesn't have spring dependency any more. The main question is what should we do with all tests in activemq-core (and other modules), that depends on Spring (and preventing us to do a better separation). IMHO we should move them either in this newly-created activemq-spring module or activemq-all module or even previously created sys test project. It will require some refactoring and probably make debugging a bit harder, but I think it's the move we have to make.
        Hide
        Gary Tully added a comment -

        For a start I guess the spring-module can have any of the FactoryBeans and we can revert core to use annotations where there are spring dependencies in the class hierarchy so that core can injection container agnostic.

        All of the spring config could move long term to system tests, it may be possible to do an alternative config mechanism and reuse the tests in some way.

        Show
        Gary Tully added a comment - For a start I guess the spring-module can have any of the FactoryBeans and we can revert core to use annotations where there are spring dependencies in the class hierarchy so that core can injection container agnostic. All of the spring config could move long term to system tests, it may be possible to do an alternative config mechanism and reuse the tests in some way.
        Hide
        Gert Vanthienen added a comment -

        Now that this class is in the separate activemq-spring module, would it be possible to reintroduce the InitializingBean and DisposableBean interfaces on the PooledConnectionFactoryBean (cfr. AMQ-2702.diff) so it can be used in a plain Spring context without requiring the use of <context:annotation-driven/> to init/destroy the bean?

        Show
        Gert Vanthienen added a comment - Now that this class is in the separate activemq-spring module, would it be possible to reintroduce the InitializingBean and DisposableBean interfaces on the PooledConnectionFactoryBean (cfr. AMQ-2702 .diff) so it can be used in a plain Spring context without requiring the use of <context:annotation-driven/> to init/destroy the bean?
        Hide
        Dejan Bosanac added a comment -

        With svn revision 965820, we don't have runtime dependency on Spring. XBeanBrokerService doesn't implement ApplicationContextAware and we introduced BrokerContext which should be used to make bean lookups container neutral. Currently there's only SpringBrokerContext implementation that uses ApplicationContext to lookup for the beans. Similar classes can be implemented for other environments, like Blueprint for example.

        To enable usage of broker context in Spring environment, you should use something like

        <bean id="springContext" class="org.apache.activemq.spring.SpringBrokerContext" />
        
        <broker brokerContext="#springContext">
        
          ... 
        
        </broker>
        
        
        Show
        Dejan Bosanac added a comment - With svn revision 965820, we don't have runtime dependency on Spring. XBeanBrokerService doesn't implement ApplicationContextAware and we introduced BrokerContext which should be used to make bean lookups container neutral. Currently there's only SpringBrokerContext implementation that uses ApplicationContext to lookup for the beans. Similar classes can be implemented for other environments, like Blueprint for example. To enable usage of broker context in Spring environment, you should use something like <bean id= "springContext" class= "org.apache.activemq.spring.SpringBrokerContext" /> <broker brokerContext= "#springContext" > ... </broker>
        Hide
        Timothy Bish added a comment -

        This one looks to now be complete for v5.8 ?

        Show
        Timothy Bish added a comment - This one looks to now be complete for v5.8 ?

          People

          • Assignee:
            Dejan Bosanac
            Reporter:
            Dejan Bosanac
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development