I get the following error in my application:
2012-04-27 12:29:07,623 4540114 DEBUG [org.jboss.seam.jsf.SeamPhaseListener] (http-localhost%2F127.0.0.1-8080-3:) committing transaction after phase: INVOKE_APPLICATION 5
2012-04-27 12:29:07,623 4540114 DEBUG [org.jboss.seam.transaction.UTTransaction] (http-localhost%2F127.0.0.1-8080-3:) committing JTA transaction
2012-04-27 12:29:07,624 4540115 ERROR [org.jboss.aspects.tx.TxPolicy] (http-localhost%2F127.0.0.1-8080-3:) javax.ejb.NoSuchEJBException: Could not find stateful bean: a2d6v-rpg5ad-h1j0xu2n-1-h1j3g9no-cb
2012-04-27 12:29:07,624 4540115 WARN [org.jboss.seam.jsf.SeamPhaseListener] (http-localhost%2F127.0.0.1-8080-3:) uncaught exception, passing to exception handler
java.lang.IllegalStateException: Could not commit transaction
at org.jboss.seam.jsf.SeamPhaseListener.commitOrRollback(SeamPhaseListener.java:625)
While debugging I was successful in the application part and when it came to page redirect, this error occurs.
Can someone give me some pointers as to where it could be wrong?
I just had a similar problem, and it was all to do with the timeouts for the bean themselves.
You can either set timeouts on the stateful bean itself with the annotation
#CacheConfig (maxSize=100000, idleTimeoutSeconds=300, removalTimeoutSeconds=0)
Or by setting JBOSS_HOME\server\default\conf\standardjboss.xml to:
<container-configuration>
<container-name>Standard Stateful SessionBean</container-name>
...
<container-cache-conf>
...
<cache-policy-conf>
<remover-period>0</remover-period>
<max-bean-life>900</max-bean-life>
Where the parameters given are seconds.
I personally changed the standardjboss.xml to make it global. I made the remover-period 0 so that it's set to infinty. If it is less that the max bean life, then it's state will be removed you will get javax.ejb.NoSuchEJBException if the bean has not been touched.
Also worth checking you actually need a stateful bean hanging around.
https://community.jboss.org/wiki/howdothetimeoutsworkwithejb3statefulbeans
https://community.jboss.org/wiki/JbossTimeoutSettingForSeam
http://docs.jboss.org/seam/2.2.2.Final/reference/en-US/html_single/#d0e25223
Related
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
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.
We are getting following below error when we deploy any application in Liferay DXP 7.
When we clean the Liferay DXP and then redeploy the below issue gets fixed.
But the problem with this approach is that all the caches gets deleted after cleaning and when we redeploy and access the site , the caches gets recreated but it takes lot of time to access any page on the site.
[2018-05-17 10:58:33,113] [DEBUG] [10.111.2.74] [] [http-nio-5443-exec-8] [com.fsvps.clientPortal.service.common.ProgramFilterPopulator] - Retrieving logged in user
[2018-05-17 10:58:33,137] [DEBUG] [10.111.2.74] [] [http-nio-5443-exec-8] [com.fsvps.clientPortal.util.common.UserContextInitializationInterceptor] - Portlet mode view and debug mode = false
[2018-05-17 10:58:33,137] [DEBUG] [10.111.2.74] [] [http-nio-5443-exec-8] [com.fsvps.clientPortal.util.common.UserContextInitializationInterceptor] - Checking to see if invalid filter view should be shown
[2018-05-17 11:07:40,859] [DEBUG] [] [] [http-nio-5443-exec-2] [com.fsvps.clientPortal.util.common.UserContextInitializationInterceptor] - Entering
[2018-05-17 11:07:40,859] [WARN] [] [] [http-nio-5443-exec-2] [org.springframework.web.portlet.DispatcherPortlet] - Handler execution resulted in exception - forwarding to resolved error view
java.lang.ClassCastException: com.fsvps.clientPortal.domain.common.UserContext cannot be cast to com.fsvps.clientPortal.domain.common.UserContext
at com.fsvps.clientPortal.domain.common.UserContext$$FastClassBySpringCGLIB$$818d2483.invoke(<generated>)
at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:738)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:133)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:121)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:673)
at com.fsvps.clientPortal.domain.common.UserContext$$EnhancerBySpringCGLIB$$830ac420.setIpAddress(<generated>)
at com.fsvps.clientPortal.util.common.UserContextInitializationInterceptor.preHandle(UserContextInitializationInterceptor.java:93)
at org.springframework.web.portlet.handler.HandlerInterceptorAdapter.preHandleRender(HandlerInterceptorAdapter.java:72)
at org.springframework.web.portlet.DispatcherPortlet.doRenderService(DispatcherPortlet.java:739)
at org.springframework.web.portlet.FrameworkPortlet.processRequest(FrameworkPortlet.java:537)
The exact cause is impossible to pinpoint with the information you give. However, the class of problem is easy to identify:
java.lang.ClassCastException:
com.fsvps.clientPortal.domain.common.UserContext cannot be cast to
com.fsvps.clientPortal.domain.common.UserContext
(separated to lines to illustrate the identical class name)
Whenever a class can't be typecasted to itself or a legitimate superclass/interface, you're dealing with duplicate code: There are two versions of the class with the same name available to the classloader, and the system is choosing both.
As the error message just contains the name of the class, not its classloader, a first glance at the error message doesn't make sense. Knowing that a class is uniquely described by its package, name, and its classloader leads you to the root cause.
Identify your modules and make sure that there's only one option for com.fsvps.clientPortal.domain.common.UserContext available.
Edit: Answering to your comments - without knowing your deployment details, there's no way to help you other than wild guesses. Please add more information to your question if the next wild guess doesn't help:
The name of the class, UserContext, suggests that you might store it somewhere, e.g. in a session. Doing so will prevent the original class from unloading when you're undeploying your plugin. Note that there is a huge difference between undeploying code and garbage collecting objects: GC can only happen, when there is no more reference.
If you deploy an updated version of your plugin, the old and existing objects still are referencing the previously loaded UserContext class, while the new code is trying to assign it to a new UserContext reference. Even though, both might be identical in implementation, they are different classes that just share the name.
You can't keep long living references to code that might undeploy, and expect them to stay usable. A quick fix (if you're deploying OSGi modules) might be to extract stable and long-used classes into its own bundle that you won't redeploy. Or replace session stored objects (assuming that this is it) with Java runtime classes, e.g. Map of built-in types, and build a UserContext object from those types whenever you need it.
Environment : WAS 8.0.0.10
CDI : 1.0 (Implementation OpenWebBeans)
Use Case: Server is executing the Java class asynchronously via TimerManager. I am trying to inject the cdi bean with Request scope into the class but when any method is called on the injection, below is the stack trace i am getting. If i use the Applicationscope instead of RequestScope in the injection, Code works fine.
Upon investigating the issue, i found that Request and Session context will not be active for the threads initiallized asynchronously by the container. Is there some way i can initialize the request and session context?
Error :
javax.enterprise.context.ContextNotActiveException: WebBeans context with scope type annotation #RequestScoped does not exist within current thread**
at org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:358)
at org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:124)
at org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:95)
at com.ford.it.processcontrol.TestJob3_$$_javassist_22.executeJobCB(TestJob3_$$_javassist_22.java)
I'm assuming you already have this, or something alike somewhere:
CdiContainer cdiContainer = CdiContainerLoader.getCdiContainer();
cdiContainer.boot();
ContextControl contextControl = cdiContainer.getContextControl();
Then, somehow you have access to the ContextControl instance. Then you can start the context wherever you need it, just remember to stop it when it's no longer needed
try{
//start
contextControl.startContext(RequestScoped.class);
// do stuff
}catch(Exception e){}
finally{
//stop
contextControl.stopContext(RequestScoped.class);
}
This is working for me in some asynced classes.
Hope it helps.
regards!
I need the Spring Integration configuration to handle the case where there will be a variable number of queues which the application will receive messages on.
Have tried the following configuration:
<int-jms:message-driven-channel-adapter id="dsToT2"
destination-name="#{tConfigurer.getDsToTQueues().values().toArray().length>2?
dsConfigurer.getDsToTQueues().values().toArray()[2]:null}"
connection-factory="connectionFactory"
channel="ackToTChannel"/>
but, if the destination-name resolves to null, the following exception is thrown:
java.lang.IllegalArgumentException: 'destinationName' must not be null
What is the best way to handle this scenario?
Thanks
So, the problem is here that you get IllegalArgumentException on application startup.
If really don't know if your detination will be null or not, you shoudl do some Java code:
mark your <int-jms:message-driven-channel-adapter> with auto-startup="false"
Introduce separate bean for DefaultMessageListenerContainer with autoStartup=false too, and inject it to the <int-jms:message-driven-channel-adapter>
As far as destination-name is a property of that DefaultMessageListenerContainer you should right some code to resolve your destination on application startup and inject the value (if any) to the container bean.
And call start() of <int-jms:message-driven-channel-adapter>. It is a AbstractEndpoint bean with id dsToT2
Note, you can't provide null to the destination-name attribute. Your AC will fail on startup when it tries to populate bean properties. In this case will be called AbstractMessageListenerContainer#setDestinationName, which, in turn, does the check
Assert.notNull(destinationName, "'destinationName' must not be null");.
However, you can try to provide empty string '' instead of null and add similar SpEL condition for auto-startup attribute.
HTH
I want my session to timeout after a given interval of time. In web.xml I've been using code like:
<session-config>
<session-timeout>20</session-timeout>
</session-config>
where 20 is the timeout period in minutes, which works correctly.
What I would like to do is to do it programatically using code like this inside one of my beans as follow:
#ManagedBean(name="login")
#SessionScoped
public class MyLoginBean implements HttpSessionListener, Serializable {
// private variables etc.
HttpServletRequest request;
HttpSession session = request.getSession();
// Constructor
public MyLoginBean() {
session.setMaxInactiveInterval(1200);
}
// The rest of the code
}
where the timeout here is 1200 seconds, i.e. 20 minutes. Unfortunately, on opening up a browser to look at the application, it fails with the message:
com.sun.faces.mgbean.ManagedBeanCreationException: Cant instantiate class: com.csharp.MyLoginBean.
Followed by:
java.lang.NullPointerException
What am I doing wrong here? I know that setMaxInactiveInterval() refers to the particular session, which in this case is the login bean, rather than everything, which is what the code in web.xml file specifies. I have several beans, but timing out the login bean is the only one that matters.
I'm using JSF 2.0 with Glassfish 3.1.1 and Eclipse Indigo, so some advice would be very much appreciated.
The NullPointerException has an extremely simple cause. It's one of the most simplest exceptions. To learn about the cause of an arbitrary exception, just look in its javadoc. All Java exceptions have their causes explained in the javadoc. Here's an extract of the javadoc of NullPointerException:
Thrown when an application attempts to use null in a case where an object is required. These include:
Calling the instance method of a null object.
Accessing or modifying the field of a null object.
Taking the length of null as if it were an array.
Accessing or modifying the slots of null as if it were an array.
Throwing null as if it were a Throwable value.
Applications should throw instances of this class to indicate other illegal uses of the null object.
Your problem is caused by point 1. Here,
HttpServletRequest request;
HttpSession session = request.getSession();
you're trying to invoke getSession() method on null instead of a concrete HttpServletRequest instance. In fact, you should have obtained the HttpServletRequest via ExternalContext#getRequest() and assigned it to request.
However, you've bigger problems: you should absolutely not get hold of the current servlet request as a property of a session scoped bean (which lives longer than the HTTP request!). You should get it inside the thread local scope (i.e. wholly inside the constructor or the method block). You should also not let your JSF managed bean implement the HttpSessionListener. This makes no utter sense. You'd end up with 2 instances, one created as listener by the container and another one created as managed bean by JSF.
Just thus should do:
#ManagedBean(name="login")
#SessionScoped
public class MyLoginBean implements Serializable {
public MyLoginBean() {
HttpSession session = (HttpSession) FacesContext.getCurrentInstance().getExternalContext().getSession();
session.setMaxInactiveInterval(1200);
}
// ...
}
Or, if you're using JSF 2.1, use the one provided by ExternalContext:
FacesContext.getCurrentInstance().getExternalContext().setSessionMaxInactiveInterval(1200);