Spring Framework
  1. Spring Framework
  2. SPR-3721

ApplicationContext should delegate to a ResourceLoader the same way it does to other services

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.1 M3
    • Fix Version/s: None
    • Component/s: Core
    • Labels:
      None
    • Last commented by a User:
      false

      Description

      ApplicationContext should delegate to a ResourceLoader the same way it does to other services. It is easy to override the MessageSource or ApplicationEventMulticaster by adding a bean to the context. ResourceLoader is not afforded the same treatment so the only solution is subclassing and class hierarchy hell.

        Activity

        Hide
        Juergen Hoeller added a comment -

        The problem here is that the ResourceLoader is needed for loading bean definition files. So overriding it in a bean definition file is a chicken-and-egg problem...

        Note that a GenericApplicationContext (which I would recommend for any standard purposes these days, in combination with one of the BeanDefinitionReaders) allows for configuring the ResourceLoader through the "setResourceLoader" method. This should avoid class hierarchy well which usually comes in when baking specific bean definition formats into the ApplicationContext implementation class... (as shown in FileSystemXmlApplicationContext, for example, which is sort of deprecated in favor of a GenericApplicationContext + FileSystemResourceLoader + XmlBeanDefinitionReader).

        Juergen

        Show
        Juergen Hoeller added a comment - The problem here is that the ResourceLoader is needed for loading bean definition files. So overriding it in a bean definition file is a chicken-and-egg problem... Note that a GenericApplicationContext (which I would recommend for any standard purposes these days, in combination with one of the BeanDefinitionReaders) allows for configuring the ResourceLoader through the "setResourceLoader" method. This should avoid class hierarchy well which usually comes in when baking specific bean definition formats into the ApplicationContext implementation class... (as shown in FileSystemXmlApplicationContext, for example, which is sort of deprecated in favor of a GenericApplicationContext + FileSystemResourceLoader + XmlBeanDefinitionReader). Juergen
        Hide
        Dave Syer added a comment -

        That makes sense. Actually SPR-3726 if it was re-opened might also provide the feature I needed in a more focused way (per bean definition instead of per application context).

        Is there going to be any better support for creating GenericApplicationContext in XML (for a SingletonBeanFactoryLocator). A part of context: namespace? A FactoryBean? It's quite hard to do except in Java right now.

        Show
        Dave Syer added a comment - That makes sense. Actually SPR-3726 if it was re-opened might also provide the feature I needed in a more focused way (per bean definition instead of per application context). Is there going to be any better support for creating GenericApplicationContext in XML (for a SingletonBeanFactoryLocator). A part of context: namespace? A FactoryBean? It's quite hard to do except in Java right now.
        Hide
        Juergen Hoeller added a comment -

        Fair enough, GenericApplicationContext is not quite designed for use with SingletonBeanFactoryLocator. Not sure what to do about that... A FactoryBean might work, but on the other hand, ApplicationContext bootstrap is really meant to be programmatic. SingletonBeanFactoryLocator is a sort-of workaround facility that I would only really consider for use in an EJB environment. So for any special purposes, I would recommend to simply bootstrap the required ApplicationContext(s) manually and keep references to them wherever it is natural for the system.

        Juergen

        Show
        Juergen Hoeller added a comment - Fair enough, GenericApplicationContext is not quite designed for use with SingletonBeanFactoryLocator. Not sure what to do about that... A FactoryBean might work, but on the other hand, ApplicationContext bootstrap is really meant to be programmatic. SingletonBeanFactoryLocator is a sort-of workaround facility that I would only really consider for use in an EJB environment. So for any special purposes, I would recommend to simply bootstrap the required ApplicationContext(s) manually and keep references to them wherever it is natural for the system. Juergen
        Hide
        Dave Syer added a comment -

        I see what you mean, but I still wish Spring provided some more help here. "Wherever is natural for the system" is always going to be something like the SingletonBeanFactoryLocator - people all too often either struggle with or forget that they are only supposed to create one ApplicationContext per application. There is a lot of potentially good stuff in there, so it's a shame that you only think of it as a hack. Couldn't we promote it to something more useful?

        Show
        Dave Syer added a comment - I see what you mean, but I still wish Spring provided some more help here. "Wherever is natural for the system" is always going to be something like the SingletonBeanFactoryLocator - people all too often either struggle with or forget that they are only supposed to create one ApplicationContext per application. There is a lot of potentially good stuff in there, so it's a shame that you only think of it as a hack. Couldn't we promote it to something more useful?
        Hide
        Rossen Stoyanchev added a comment -

        This issue has been resolved through a selective bulk update, as part of a larger effort to better manage unresolved issues. To qualify for the update, the issue was either created before Spring 3.0 or affects a version older than Spring 3.0 and is not a bug.

        There is a good chance the request was made obsolete, or at least partly outdated, by changes in later versions of Spring including deprecations. It is also possible it didn't get enough traction or we didn't have enough time to address it. One way or another, we didn't get to it.

        If you believe the issue, or some aspects of it, are still relevant and worth pursuing at present you may re-open this issue or create a new one with a more up-to-date description.

        We thank you for your contributions and encourage you to become familiar with the current process of managing Spring Framework JIRA issues that has been in use for over a year.

        Show
        Rossen Stoyanchev added a comment - This issue has been resolved through a selective bulk update, as part of a larger effort to better manage unresolved issues. To qualify for the update, the issue was either created before Spring 3.0 or affects a version older than Spring 3.0 and is not a bug. There is a good chance the request was made obsolete, or at least partly outdated, by changes in later versions of Spring including deprecations. It is also possible it didn't get enough traction or we didn't have enough time to address it. One way or another, we didn't get to it. If you believe the issue, or some aspects of it, are still relevant and worth pursuing at present you may re-open this issue or create a new one with a more up-to-date description. We thank you for your contributions and encourage you to become familiar with the current process of managing Spring Framework JIRA issues that has been in use for over a year.

          People

          • Assignee:
            Juergen Hoeller
            Reporter:
            Dave Syer
            Last updater:
            Trevor Marshall
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Days since last comment:
              1 year, 43 weeks, 2 days ago