This class is as easy to subclass as AbstractRefreshableApplicationContext: All you need to implements is the {@link #loadBeanDefinitions} method;see the superclass javadoc for details. Note that implementations are supposed to load bean definitions from the files specified by the locations returned by the {@link #getConfigLocations} method.
Interprets resource paths as servlet context resources, i.e. as paths beneath the web application root. Absolute paths, e.g. for files outside the web app root, can be accessed via "file:" URLs, as implemented by {@link org.springframework.core.io.DefaultResourceLoader}.
This is the portlet context to be subclassed for a different bean definition format. Such a context implementation can be specified as "contextClass" init-param for FrameworkPortlet, replacing the default {@link XmlPortletApplicationContext}. It will then automatically receive the "contextConfigLocation" init-param.
Note that Portlet-based context implementations are generally supposed to configure themselves based on the configuration received through the {@link ConfigurablePortletApplicationContext} interface. In contrast, a standaloneapplication context might allow for configuration in custom startup code (for example, {@link org.springframework.context.support.GenericApplicationContext}). @author Juergen Hoeller @author John A. Lewis @since 2.0 @see #loadBeanDefinitions @see org.springframework.web.portlet.context.ConfigurablePortletApplicationContext#setConfigLocations @see XmlPortletApplicationContext
|
|