Scope conflicts until batch job finished?

Question

Tech stack:

JBeret (core, se) 1.3.0.Final
Hibernate Search (orm, jsr352-core, jsr352-jberet) 5.10.4.Final
Weld (servlet-core, se-core) 3.0.5.Final

If I trigger

BatchRuntime.getJobOperator().start( MassIndexingJob.NAME, MassIndexingJob.parameters().forEntity(getDomainObjectClass()).build() );

then I had the situation that a can't access any CDI component outside of the batch job that are RequestScoped or SessionScoped, until the batch job is finished.

How I can fix this problem?

Part of the stacktrace

 Caused by: org.jboss.weld.contexts.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
    at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:647) ~[weld-core-impl-3.0.5.Final.jar:3.0.5.Final]
    at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89) ~[weld-core-impl-3.0.5.Final.jar:3.0.5.Final]
    at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:164) ~[weld-core-impl-3.0.5.Final.jar:3.0.5.Final]
    at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63) ~[weld-core-impl-3.0.5.Final.jar:3.0.5.Final]
    at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:87) ~[weld-core-impl-3.0.5.Final.jar:3.0.5.Final]
    at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:131) ~[weld-core-impl-3.0.5.Final.jar:3.0.5.Final]
    at foo.bar.Baz$Proxy$_$$_WeldClientProxy.getFoo(Unknown Source) ~[classes/:na]

Annotated @ActivateRequestContext produce this stacktrace on startup/deployment

 Caused by: org.jboss.weld.exceptions.WeldException: WELD-001524: Unable to load proxy class for bean Managed Bean [class foo.bar.Bean] with qualifiers [@Any @Default] with class class foo.bar.Bean using classloader ParallelWebappClassLoader
  context: foobar
  delegate: false
----------> Parent Classloader:
java.net.URLClassLoader@58a9760d

    at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:370)
    at org.jboss.weld.injection.producer.SubclassedComponentInstantiator.createEnhancedSubclass(SubclassedComponentInstantiator.java:113)
    at org.jboss.weld.injection.producer.SubclassedComponentInstantiator.initEnhancedSubclass(SubclassedComponentInstantiator.java:86)
    at org.jboss.weld.injection.producer.SubclassedComponentInstantiator.<init>(SubclassedComponentInstantiator.java:79)
    at org.jboss.weld.injection.producer.SubclassedComponentInstantiator.forInterceptedDecoratedBean(SubclassedComponentInstantiator.java:63)
    at org.jboss.weld.injection.producer.BeanInjectionTarget.initializeAfterBeanDiscovery(BeanInjectionTarget.java:121)
    at org.jboss.weld.injection.producer.InjectionTargetInitializationContext.initialize(InjectionTargetInitializationContext.java:42)
    at org.jboss.weld.injection.producer.InjectionTargetService.initialize(InjectionTargetService.java:63)
    at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:475)
    at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:86)
    at org.jboss.weld.environment.servlet.WeldServletLifecycle.initialize(WeldServletLifecycle.java:236)
    at org.jboss.weld.environment.servlet.EnhancedListener.onStartup(EnhancedListener.java:62)
    at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5245)
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
    ... 42 more
Caused by: org.jboss.weld.exceptions.WeldException: Cannot load variable at 0. Local Variables: Local Variables: []
    at org.jboss.weld.bean.proxy.InterceptedSubclassFactory.addMethodsFromClass(InterceptedSubclassFactory.java:262)
    at org.jboss.weld.bean.proxy.InterceptedSubclassFactory.addMethods(InterceptedSubclassFactory.java:136)
    at org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:449)
    at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:362)
    ... 55 more
Caused by: org.jboss.classfilewriter.InvalidBytecodeException: Cannot load variable at 0. Local Variables: Local Variables: []
    at org.jboss.classfilewriter.code.CodeAttribute.aload(CodeAttribute.java:196)
    at org.jboss.weld.bean.proxy.RunWithinInterceptionDecorationContextGenerator.startIfNotOnTop(RunWithinInterceptionDecorationContextGenerator.java:71)
    at org.jboss.weld.bean.proxy.RunWithinInterceptionDecorationContextGenerator.runStartIfNotOnTop(RunWithinInterceptionDecorationContextGenerator.java:148)
    at org.jboss.weld.bean.proxy.InterceptedSubclassFactory.addMethodsFromClass(InterceptedSubclassFactory.java:200)
    ... 58 more

Do you mean the batch job works fine, but your main application hangs while the batch job is executing? Or is there a specific error? Please share the stacktrace/logs; it's a bit hard to understand what's going on without that. — yrodiere, Sep 26 '18 at 14:27
JBeret SE uses the Weld SE static singleton instance weld container for managing CDI components (see [SEArtifactFactory](https://github.com/jberet/jsr352/blob/master/jberet-se/src/main/java/org/jberet/se/SEArtifactFactory.java#L27)). Are these problematic CDI components in your app managed by the same weld container insance? Or are there multiple weld container instances? — cheng, Sep 26 '18 at 15:14
Thanks for hint, yes servlet container and jberet use the same CDI beanmanager instance — zeitiger, Sep 27 '18 at 11:52
I created an issue [JBERET-454](https://issues.jboss.org/browse/JBERET-454) to record and track it on JBeret side. If you still have problem with JBeret or anything can be improved, feel free to follow up there. — cheng, Oct 01 '18 at 17:59
I fixed the problem now with replacing all contextId references within my servlet container to a custom value — zeitiger, Oct 23 '18 at 13:39

score 0 · Answer 1 · answered Sep 27 '18 at 08:02

I do not know what exactly JBeret does, but Weld SE out of the box does not activate request context (or session context) which in turn leads to the exception you are seeing. The reason is that in SE there are no HTTP requests (or sessions) hence Weld simply does not know when to activate it.

Although "request" can be interpreted differently and can be valuable addition even in SE - that's why there are supported ways to activate request context, for instance via interceptor. I suppose this is something JBeret does for you and that's why the beans "work" there.

Therefore in order to be able to use your request scoped beans in SE application, you will need to take extra steps. Note however that the context can be different from that of JBeret batch job (you won't see the same beans with the exact same state) as I expect JBeret to offload the work to another thread.

Sadly that doesn't help, if I try to annotated `@ActivateRequestContext` then my WAR file doesn't start anymore — zeitiger, Oct 04 '18 at 07:26

Scope conflicts until batch job finished?

1 Answers1