I am trying to get some of the demo's working, but have been having problems. I am using Tomcat 7 + MySql. When I try to the jsf2 portlet demo found at: http://repository.portletfaces.org/content/repositories/liferay-releases/com/liferay/faces/demos/jsf2-portlet/3.1.0-rc2/jsf2-portlet-3.1.0-rc2.war my logs (configured for log4j) show it gets registered but is immediately unregistered. I have no idea why and am not seeing any reason in the log. I would appreciate any help.
The log entry in question is: "04:17:55,430 INFO [PortletHotDeployListener:470] Unregistering portlets for jsf2-portlet".
Here are the ones leading to the one above.
04:17:53,693 DEBUG [BridgeConfigImpl:223] Processing faces-config: [/WEB-INF/faces-config.xml]
04:17:53,694 DEBUG [BridgeConfigImpl:296] Processing web-app: [/WEB-INF/web.xml]
04:17:53,695 DEBUG [BridgeConfigImpl:306] Processing web-app: [/WEB-INF/liferay-web.xml]
04:17:53,699 DEBUG [BridgeConfigImpl:341] Added implicit extension-mapped servlet-mapping for urlPattern=[*.xhtml]
04:17:53,699 DEBUG [BridgeConfigImpl:341] Added implicit extension-mapped servlet-mapping for urlPattern=[*.jsp]
04:17:53,713 INFO [PortletHotDeployListener:433] 1 portlet for jsf2-portlet is available for use
04:17:55,418 INFO [PluginPackageUtil:1099] Reading plugin package for jsf2-portlet
04:17:55,430 INFO [PortletHotDeployListener:470] Unregistering portlets for jsf2-portlet
**04:17:55,437 INFO [PortletHotDeployListener:503] 1 portlet for jsf2-portlet was unregistered**
The full log can be seen below.:
04:17:53,183 INFO [PluginPackageUtil:1099] Reading plugin package for jsf2-portlet
04:17:53,469 INFO [PortletHotDeployListener:614] Registering portlets for jsf2-portlet
04:17:53,511 INFO [BridgeImpl] Initializing Liferay Faces Bridge 3.1.0-rc2 (Galatia / Jul 14, 2012 AD)
04:17:53,592 DEBUG [BridgeConfigImpl:168] Pre-processing faces-config: [jar:file:/usr/local/LiferayTomcat/liferay-portal-6.1.0-ce-ga1/apache-tomcat-7.0.27/lib/weld-servlet.jar!/META-INF/faces-config.xml]
04:17:53,598 DEBUG [BridgeConfigImpl:168] Pre-processing faces-config: [jar:file:/usr/local/LiferayTomcat/liferay-portal-6.1.0-ce-ga1/apache-tomcat-7.0.27/lib/ext/resin.jar!/META-INF/faces-config.xml]
04:17:53,599 DEBUG [BridgeConfigImpl:168] Pre-processing faces-config: [jar:file:/usr/local/LiferayTomcat/liferay-portal-6.1.0-ce-ga1/apache-tomcat-7.0.27/webapps/jsf2-portlet/WEB-INF/lib/liferay-faces-alloy-3.1.0-rc2.jar!/META-INF/faces-config.xml]
04:17:53,600 DEBUG [BridgeConfigImpl:168] Pre-processing faces-config: [jar:file:/usr/local/LiferayTomcat/liferay-portal-6.1.0-ce-ga1/apache-tomcat-7.0.27/webapps/jsf2-portlet/WEB-INF/lib/liferay-faces-bridge-impl-3.1.0-rc2.jar!/META-INF/faces-config.xml]
04:17:53,601 DEBUG [BridgeConfigImpl:168] Pre-processing faces-config: [jar:file:/usr/local/LiferayTomcat/liferay-portal-6.1.0-ce-ga1/apache-tomcat-7.0.27/webapps/jsf2-portlet/WEB-INF/lib/util-taglib.jar!/META-INF/faces-config.xml]
04:17:53,602 DEBUG [BridgeConfigImpl:202] Post-processing faces-config: [jar:file:/usr/local/LiferayTomcat/liferay-portal-6.1.0-ce-ga1/apache-tomcat-7.0.27/webapps/jsf2-portlet/WEB-INF/lib/liferay-faces-bridge-impl-3.1.0-rc2.jar!/META-INF/faces-config.xml]
04:17:53,603 DEBUG [BridgeConfigImpl:802] render-response-wrapper-class=[com.liferay.faces.bridge.application.view.BridgeWriteBehindResponseRenderImpl]
04:17:53,604 DEBUG [BridgeConfigImpl:806] resource-response-wrapper-class=[com.liferay.faces.bridge.application.view.BridgeWriteBehindResponseResourceImpl]
04:17:53,609 DEBUG [BridgeConfigImpl:39] Creating instance with zero-arg constructor since wrapperConstructor=null
04:17:53,609 DEBUG [BridgeConfigImpl:592] Instantiated bridgeContextFactory=[com.liferay.faces.bridge.context.BridgeContextFactoryImpl] wrappedFactory=[null]
04:17:53,615 DEBUG [BridgeConfigImpl:39] Creating instance with zero-arg constructor since wrapperConstructor=null
04:17:53,622 DEBUG [BridgeConfigImpl:612] Instantiated bridgeFlashFactory=[com.liferay.faces.bridge.context.flash.BridgeFlashFactoryImpl] wrappedFactory=[null]
04:17:53,624 DEBUG [BridgeConfigImpl:39] Creating instance with zero-arg constructor since wrapperConstructor=null
04:17:53,624 DEBUG [BridgeConfigImpl:632] Instantiated bridgePhaseFactory=[com.liferay.faces.bridge.BridgePhaseFactoryImpl] wrappedFactory=[null]
04:17:53,626 DEBUG [BridgeConfigImpl:39] Creating instance with zero-arg constructor since wrapperConstructor=null
04:17:53,663 DEBUG [BridgeConfigImpl:652] Instantiated BridgeRequestScopeFactory=[com.liferay.faces.bridge.scope.BridgeRequestScopeFactoryImpl] wrappedFactory=[null]
04:17:53,665 DEBUG [BridgeConfigImpl:39] Creating instance with zero-arg constructor since wrapperConstructor=null
04:17:53,666 DEBUG [BridgeConfigImpl:673] Instantiated BridgeRequestScopeCacheFactory=[com.liferay.faces.bridge.scope.BridgeRequestScopeCacheFactoryImpl] wrappedFactory=[null]
04:17:53,668 DEBUG [BridgeConfigImpl:39] Creating instance with zero-arg constructor since wrapperConstructor=null
04:17:53,669 DEBUG [BridgeConfigImpl:695] Instantiated BridgeRequestScopeManagerFactory=[com.liferay.faces.bridge.scope.BridgeRequestScopeManagerFactoryImpl] wrappedFactory=[null]
04:17:53,671 DEBUG [BridgeConfigImpl:39] Creating instance with zero-arg constructor since wrapperConstructor=null
04:17:53,672 DEBUG [BridgeConfigImpl:717] Instantiated BridgeWriteBehindResponseFactory=[com.liferay.faces.bridge.application.view.BridgeWriteBehindResponseFactoryImpl] wrappedFactory=[null]
04:17:53,676 DEBUG [BridgeConfigImpl:39] Creating instance with zero-arg constructor since wrapperConstructor=null
04:17:53,677 DEBUG [BridgeConfigImpl:737] Instantiated BridgeURLFactory=[com.liferay.faces.bridge.context.url.BridgeURLFactoryImpl] wrappedFactory=[null]
04:17:53,683 DEBUG [BridgeConfigImpl:39] Creating instance with zero-arg constructor since wrapperConstructor=null
04:17:53,684 DEBUG [BridgeConfigImpl:789] Instantiated PortletContainerFactory=[com.liferay.faces.bridge.container.PortletContainerFactoryImpl] wrappedFactory=[null]
04:17:53,686 DEBUG [BridgeConfigImpl:39] Creating instance with zero-arg constructor since wrapperConstructor=null
04:17:53,687 DEBUG [BridgeConfigImpl:817] Instantiated UploadedFileFactory=[com.liferay.faces.bridge.model.UploadedFileFactoryImpl] wrappedFactory=[null]
04:17:53,688 DEBUG [BridgeConfigImpl:202] Post-processing faces-config: [jar:file:/usr/local/LiferayTomcat/liferay-portal-6.1.0-ce-ga1/apache-tomcat-7.0.27/lib/weld-servlet.jar!/META-INF/faces-config.xml]
04:17:53,690 DEBUG [BridgeConfigImpl:202] Post-processing faces-config: [jar:file:/usr/local/LiferayTomcat/liferay-portal-6.1.0-ce-ga1/apache-tomcat-7.0.27/lib/ext/resin.jar!/META-INF/faces-config.xml]
04:17:53,691 DEBUG [BridgeConfigImpl:202] Post-processing faces-config: [jar:file:/usr/local/LiferayTomcat/liferay-portal-6.1.0-ce-ga1/apache-tomcat-7.0.27/webapps/jsf2-portlet/WEB-INF/lib/liferay-faces-alloy-3.1.0-rc2.jar!/META-INF/faces-config.xml]
04:17:53,692 DEBUG [BridgeConfigImpl:202] Post-processing faces-config: [jar:file:/usr/local/LiferayTomcat/liferay-portal-6.1.0-ce-ga1/apache-tomcat-7.0.27/webapps/jsf2-portlet/WEB-INF/lib/util-taglib.jar!/META-INF/faces-config.xml]
04:17:53,693 DEBUG [BridgeConfigImpl:223] Processing faces-config: [/WEB-INF/faces-config.xml]
04:17:53,694 DEBUG [BridgeConfigImpl:296] Processing web-app: [/WEB-INF/web.xml]
04:17:53,695 DEBUG [BridgeConfigImpl:306] Processing web-app: [/WEB-INF/liferay-web.xml]
04:17:53,699 DEBUG [BridgeConfigImpl:341] Added implicit extension-mapped servlet-mapping for urlPattern=[*.xhtml]
04:17:53,699 DEBUG [BridgeConfigImpl:341] Added implicit extension-mapped servlet-mapping for urlPattern=[*.jsp]
04:17:53,713 INFO [PortletHotDeployListener:433] 1 portlet for jsf2-portlet is available for use
04:17:55,418 INFO [PluginPackageUtil:1099] Reading plugin package for jsf2-portlet
04:17:55,430 INFO [PortletHotDeployListener:470] Unregistering portlets for jsf2-portlet
**04:17:55,437 INFO [PortletHotDeployListener:503] 1 portlet for jsf2-portlet was unregistered**
The behavior you describe usually means that there's still an exception that occurs, it just isn't being logged correctly by Liferay. What works for me most of the times is to add a logging.properties file to the WEB-INF/classes directory of my portlet and give it the following content:
handlers = org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
org.apache.juli.FileHandler.level = FINE
org.apache.juli.FileHandler.directory = ${catalina.base}/logs
org.apache.juli.FileHandler.prefix = catalina.
java.util.logging.ConsoleHandler.level = FINE
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
After deploying this new WAR you should hopefully see additional logging that should help you find the cause of the failed deployment.
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.
I'm using CXF WSDL2Java (using JAXB to generate Java classes). I now have everything generating my classes fine, but I get INFO messages of the form;
Jun 15, 2016 4:39:16 PM org.apache.cxf.wsdl11.WSDLServiceBuilder checkForWrapped
INFO: Operation <--my operation--> cannot be unwrapped, its wsdl:part/#element reference must match xs:complexType/xs:sequence.
I understand why it can't be unwrapped and don't have the option to "fix" the WSDL, it's already in use as is.
I'd like to pass something in so that I don't see these INFO messages during my build, as it just creates noise for something that's really OK.
How can I run WSDL2Java to avoid this message?
I have created one portlet and i am trying to do deploy, but while doing deployment, I am getting the following error,
Note:I am using liferay-plugins-sdk-6.2-ce-ga6
Please help me out.
SEVERE: Exception sending context destroyed event to listener instance of class com.liferay.portal.kernel.servlet.PluginContextListener
java.lang.ExceptionInInitializerError
at com.liferay.portal.kernel.deploy.hot.HotDeployEvent.initDependentServletContextNames(HotDeployEvent.java:97)
at com.liferay.portal.kernel.deploy.hot.HotDeployEvent.<init>(HotDeployEvent.java:53)
at com.liferay.portal.kernel.servlet.PluginContextListener.fireUndeployEvent(PluginContextListener.java:170)
at com.liferay.portal.kernel.servlet.PluginContextListener.doPortalDestroy(PluginContextListener.java:132)
at com.liferay.portal.kernel.util.BasePortalLifecycle.portalDestroy(BasePortalLifecycle.java:31)
at com.liferay.portal.kernel.servlet.PluginContextListener.contextDestroyed(PluginContextListener.java:97)
at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:4980)
at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5626)
at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:1028)
at org.apache.catalina.startup.HostConfig.deleteRedeployResources(HostConfig.java:1299)
at org.apache.catalina.startup.HostConfig.checkResources(HostConfig.java:1229)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1439)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:315)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1374)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1530)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1519)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.lang.NullPointerException
at com.liferay.portal.kernel.util.PropsUtil.get(PropsUtil.java:32)
at com.liferay.portal.kernel.deploy.hot.DependencyManagementThreadLocal.<clinit>(DependencyManagementThreadLocal.java:40)
... 21 more
May 27, 2016 2:21:54 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/Sample-portlet] created a ThreadLocal with key of type [com.liferay.portal.kernel.util.CentralizedThreadLocal.ThreadLocalMapThreadLocal] (value [com.liferay.portal.kernel.util.CentralizedThreadLocal$ThreadLocalMapThreadLocal#32b11adf]) and a value of type [com.liferay.portal.kernel.util.CentralizedThreadLocal.ThreadLocalMap] (value [com.liferay.portal.kernel.util.CentralizedThreadLocal$ThreadLocalMap#95b4079]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
After googling a while I found that this type of error comes sometimes when you have duplicated the portal-service.jar so make sure this dendency in your pom is set to provided
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