Custom Scope not visible to child context [SPR-7089]

[spring-projects-issues]

Jack Punt opened SPR-7089 and commented

A Custom Scope (FlexClientScope, in case cited) must be registered with the root applicationContext.

In order to add Beans (a @RemotingDestination) a sub-context is created
as the target for: setParent(rootAppCtx); register(clazz); refresh(); getBean(beanName);
In the case cited, an AnnotationConfigApplicationContext.

When refresh(), the clazz with @Service @RemotingDestination
@Scope(value="flexclient", proxyMode = ScopedProxyMode.TARGET_CLASS)
proceeds to AbstractBeanFactory.java line 320: which attempts to find the requested scope,
but looks only in the current/child ApplicationContext, failing to find the Scope in the parent.

The proposed fix is to add a method (near line 779, after getRegisteredScope()) something like:

protected Scope getScopeUseParent(String scopeName) {
    BeanFactory beanFactory = this;
    Scope scope = this.scopes.get(scopeName);
    while ((scope == null)
           && (beanFactory instanceof HierarchicalBeanFactory)
           && ((beanFactory = ((HierarchicalBeanFactory)beanFactory).getParentBeanFactory()) != null) 
           && (beanFactory instanceof AbstractBeanFactory)) {
        scope = ((AbstractBeanFactory)beanFactory).scopes.get(scopeName);
    }
    return scope;                   // which may be null...
}

And use Scope scope = getScopeUsingParents(scopeName);
instead of: Scope scope = this.scopes.get(scopeName);
In the appropriate places in AbstractBeanFactory.java

[Documentation may need to be upgraded to warn non-AbstractBeanFactory implementations
that they should also search the parents to find registered Scopes.]

Note: for my project this is a "Major" "Blocker" Priority
and requires a source-level patch and class replacement.
but having upgraded the AbstractBeanFactory.class, i'm back in business until next release.
I respect the fact that it is apparently not a common requirement,
(it has gone this long without complaint) but would appreciate a supported solution when possible.

Environmental Impact: The suggested fix is "benign" (has little effect on existing/working apps),
as all of them apparently register and access custom Scopes in the same appCtx.
That is: the new while loop only runs before or in place of existing code that throws an Exception.
So at worst: existing code that relied on not finding a Scope might fail to get an Exception.

---

Affects: 3.0.2

Reference URL: http://forum.springsource.org/showpost.php?p=294224&postcount=13

[spring-projects-issues]

Juergen Hoeller commented

I'm afraid this is as designed: Custom scopes are individually configurable for each ApplicationContext, just like BeanFactoryPostProcessors (e.g. PropertyPlaceholderConfigurers) and BeanPostProcessors (e.g. tx:annotation-driven) are. So for the time being, each such scope would have to be re-defined at each context level: typically through importing the same XML configuration fragment in each such context (e.g. in the root WebApplicationContext as well as in your DispatcherServlet config).

That said: I can see where inheriting scopes from a parent ApplicationContext would be really useful, in particular for a larger number of extended scopes. We'll reconsider the arrangement for Spring 3.1 where we'll be introducing several extended web scopes which are likely to be optional or at least configurable, hence suffering from the same re-definition problem in a context hierarchy.

Juergen

[spring-projects-issues]

Jack Punt commented

Juergen, thanks for the info; I suspected it was intentional.

You suggest creating a new instance of the Scope in the child context.
That should work, as each Scope instance will ultimately use the same "object registry".

In my case, the child context is created without reference to external files,
Can you supply a pointer for how to create/inject a custom Scope programmatically?

Hmm, can I just re-register the same Scope object into the child Context?
Something like:
{
childBF = childCtx.getBeanFactory(); rootBF=rootCtx.getBeanFactory();
childBF.registerScope(scopeName, rootBF.getRegisteredScope(scopeName));
}
That solves the problem nicely, do you see any downside?

[spring-projects-issues]

Juergen Hoeller commented

Indeed, reusing the Scope SPI objects should work fine. Even when declaratively configuring them through Spring's CustomScopeConfigurer, you could simply refer to Scope SPI beans from the parent context when populating the "scopes" property. Effectively, custom scopes just need to be activated for a specific scope name at each context level, even if they refer to the very same backend from all contexts.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Closing groups of outdated issues. Please reopen if still relevant.