21

I'm trying to setup some code that will behave one way if spring's request scope is available, and another way if said scope is not available.

The application in question is a web app, but there are some JMX triggers and scheduled tasks (i.e. Quartz) that also trigger invocations.

E.g.

/**
 * This class is a spring-managed singleton
 */
@Named
class MySingletonBean{

    /**
     * This bean is always request scoped
     */
    @Inject
    private MyRequestScopedBean myRequestScopedBean; 

    /* can be invoked either as part of request handling
       or as part of a JMX trigger or scheduled task */
    public void someMethod(){
        if(/* check to see if request scope is available */){
            myRequestScopedBean.invoke();
        }else{
            //do something else
        }
    }
}

Assuming myRequestScopedBean is request scoped.

I know this can be done with a try-catch around the invocation of myRequestScopedBean, e.g.:

/**
 * This class is a spring-managed singleton
 */
@Named
class MySingletonBean{

    /**
     * This bean is always request scoped
     */
    @Inject
    private MyRequestScopedBean myRequestScopedBean; 

    /* can be invoked either as part of request handling
       or as part of a JMX trigger or scheduled task */
    public void someMethod(){
        try{
            myRequestScopedBean.invoke();
        }catch(Exception e){
            //do something else
        }
    }
}

but that seems really clunky, so I'm wondering if anyone knows of an elegant Spring way to interrogate something to see if request-scoped beans are available.

Many thanks!

Taylor
  • 3,942
  • 2
  • 20
  • 33
  • Why do you need to check if the bean is request scoped? That seems very backwards. – Sotirios Delimanolis Apr 01 '15 at 00:33
  • Sorry, perhaps this was unclear. The bean is always request scoped, but the invocation of `someMethod` may not be as part of a request handling – Taylor Apr 01 '15 at 00:34
  • I'm still confused. `MyRequestScopedBean` is request-scoped. `MySingletonBean` is singleton-scoped. What do you need to check and why? – Sotirios Delimanolis Apr 01 '15 at 00:36
  • I've tried clarifying the question a bit. What I'm after is if request-scoped beans are available, to use them, and otherwise, fallback to something else. I realize the question is a bit vague but I can't be more specific for employer ip reasons. – Taylor Apr 01 '15 at 00:42
  • If the bean isn't available, context initialization will fail when trying to inject it into the singleton. If the request-scope isn't available (it's typically provided in `WebApplicationContext`s), then initialization will again fail when trying to initialize that bean. – Sotirios Delimanolis Apr 01 '15 at 00:43
  • 1
    I'm not sure that's accurate. Spring appears to inject a singleton proxy and then on invocation of the request-scoped bean will attempt to retrieve it out of some internal storage (I believe thread local). If the thread that enters into `MySingletonBean` is a request handling thread, then everything will work fine, but if the thread is triggered as part of a JMX trigger, then you'll get some exception from the internals of spring. – Taylor Apr 01 '15 at 00:46
  • Ah, you're right about that. So that's the behavior you want to catch, that an exception is thrown because there is no request scope or because there is no thread-bound request. – Sotirios Delimanolis Apr 01 '15 at 00:58
  • Yes, exactly. It's easy to do with a try-catch but I'm hoping there's something more elegant. – Taylor Apr 01 '15 at 03:14

2 Answers2

26

You can use the if check described here

SPRING - Get current scope

if (RequestContextHolder.getRequestAttributes() != null) 
    // request thread

instead of catching exceptions. Sometimes that looks like the simplest solution.

Community
  • 1
  • 1
Sergey Shcherbakov
  • 4,534
  • 4
  • 40
  • 65
2

You can inject a Provider<MyRequestScopedBean> and catch the exception when calling the get method but you should rethink your design. If you feel strongly about it you should probably have two beans with different qualifier

Edit

On second thought, if you are using java configuration, @Scope("prototype") your @Bean method and make your decision there, you can get a handle on request context via RequestContextHolder if available. But I strongly recommend you rethink your design

Lev Kuznetsov
  • 3,520
  • 5
  • 20
  • 33
  • 1
    Thanks for the answer. If I understood correctly, you're suggesting to wrap the try-catch in a Provider? I'm trying to figure out if there's some way to query whether this will work, rather than trying and failing. Appreciate the answer though. – Taylor Apr 01 '15 at 00:43