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
Related
In SAP Cloud SDK FAQ page, there is a QA about I'm Observing a DefaultHttpClientFactory not a subtype Exception, now I encountered a similar error Provider com.sap.cloud.sdk.cloudplatform.connectivity.CertificateBasedHttpClientFactory not a subtype, however I could not exclude connectivity-scp-cf since this is mandatory?
Any hints how to solve this error?
Caused by: com.sap.core.connectivity.jco.cf.auth.TokenFactory$GetTokenException: Could not get ClientCredentialsGrantAccessToken
at com.sap.core.connectivity.jco.cf.auth.TokenFactory.getClientCredentialsGrantAccessToken(TokenFactory.java:61)
at com.sap.core.connectivity.jco.cf.destination.ConnectivityConfigurationCF.getConfiguration(ConnectivityConfigurationCF.java:72)
... 92 more
Caused by: java.lang.NoClassDefFoundError: com/sap/cloud/security/client/HttpClientFactory : cannot initialize class because prior initialization attempt failed
at com.sap.core.connectivity.jco.cf.auth.TokenFactory.executeTokenExchange(TokenFactory.java:94)
at com.sap.core.connectivity.jco.cf.auth.TokenFactory.getClientCredentialsGrantAccessToken(TokenFactory.java:57)
... 93 more
Caused by: java.lang.ExceptionInInitializerError: java.util.ServiceConfigurationError: com.sap.cloud.security.client.HttpClientFactory: Provider com.sap.cloud.sdk.cloudplatform.connectivity.CertificateBasedHttpClientFactory not a subtype
Interface type com.sap.cloud.security.client.HttpClientFactory is part of dependency com.sap.cloud.security.xsuaa:token-client.
When using SAP Java Buildpack (e.g. for JCo), please make sure to give this dependency a provided scope. Otherwise you'll be experiencing class loading issues like in your current case. For further errors, please attach your mvn dependency:tree.
I'm using Primefaces 6.1 running on a clustered WebLogic Server (Mojarra 2.2.8) Version: 12.2.1.3.0 and during the session replication i'm getting the following exception:
<Jan 30, 2018 4:08:08,727 PM CET> <Error> <Cluster> <BEA-003144> <All session objects should be serializable to replicate. Check the objects in the session. Failed to replicate a non-serializable object in context /app.
java.rmi.MarshalException: failed to marshal create(Lweblogic.rmi.spi.HostID;ILweblogic.cluster.replication.ROID;Ljava.io.Serializable;); nested exception is:
java.io.NotSerializableException: org.primefaces.model.SortMeta
at weblogic.rjvm.BasicOutboundRequest.marshalArgs(BasicOutboundRequest.java:100)
at weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:297)
at weblogic.cluster.replication.RemoteReplicationServicesInternalImpl_12213_WLStub.create(Unknown Source)
at sun.reflect.GeneratedMethodAccessor1191.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Truncated. see log file for complete stacktrace
Caused By: java.io.NotSerializableException: org.primefaces.model.SortMeta
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
at java.util.ArrayList.writeObject(ArrayList.java:766)
at sun.reflect.GeneratedMethodAccessor31.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Truncated. see log file for complete stacktrace
JSF component binding is never used in the application. Looking at the Primefaces source I can see that the model SortMeta (does not implements Serializable) is only used in the DataTable component.
The view state saving method has to be server side.
How to solve or avoid this exception?
EDIT:
Problem was caused by the "new" datatable attribute multiViewState.
https://forum.primefaces.org/viewtopic.php?f=3&t=54138&p=164132
Class SortMeta is now Serializable:
https://github.com/primefaces/primefaces/issues/3272
can any body tell me the actual reason causing the below error:
oracle.jbo.JboException: JBO-29000: Unexpected exception caught: java.lang.NullPointerException, msg=null
at oracle.jbo.server.ViewObjectImpl.executeQueryForCollection(ViewObjectImpl.java:7349)
at oracle.jbo.server.ViewRowSetImpl.execute(ViewRowSetImpl.java:1257)
at oracle.jbo.server.ViewRowSetImpl.executeQueryForMasters(ViewRowSetImpl.java:1449)
at oracle.jbo.server.ViewRowSetImpl.executeQueryForMode(ViewRowSetImpl.java:1355)
at oracle.jbo.server.ViewRowSetImpl.executeQuery(ViewRowSetImpl.java:1340)
at oracle.jbo.server.ViewObjectImpl.executeQuery(ViewObjectImpl.java:7236)
at oracle.adf.model.bc4j.DCJboDataControl.executeIteratorBindingWithParams(DCJboDataControl.java:2987)
at oracle.jbo.uicli.binding.JUCtrlActionBinding.doIt(JUCtrlActionBinding.java:1541)
at oracle.adf.model.binding.DCDataControl.invokeOperation(DCDataControl.java:2150)
at oracle.jbo.uicli.binding.JUCtrlActionBinding.invoke(JUCtrlActionBinding.java:740)
...
...
..
.
Caused by: java.lang.NullPointerException
at oracle.jdbc.driver.OraclePreparedStatement.setObjectAtName(OraclePreparedStatement.java:15884)
at oracle.jdbc.driver.OraclePreparedStatementWrapper.setObjectAtName(OraclePreparedStatementWrapper.java:911)
at weblogic.jdbc.wrapper.PreparedStatement_oracle_jdbc_driver_OraclePreparedStatementWrapper.setObjectAtName(Unknown Source)
at oracle.jbo.server.OracleSQLBuilderImpl.bindParamValue(OracleSQLBuilderImpl.java:4669)
at oracle.jbo.server.BaseSQLBuilderImpl.bindParametersForStmt(BaseSQLBuilderImpl.java:3687)
at oracle.jbo.server.ViewObjectImpl.bindParametersForCollection(ViewObjectImpl.java:22684)
From the stacktrace, it seems some bind variable that is required by your view object query is not being set correctly.
If it works intermittently, it could be that the bind variable is lost at some point. To debug/test, try it with a hard-coded value for your bind variable and see if that works first (if you have a ViewCriteria, try removing that first) - then run the task flow and see if it works consistently.
I would suggest running the application in JDeveloper with -Djbo.debugoutput=console argument. It gives you a lot if information of what your business components are doing and you could catch the error cause in console logs.
I am new to Liferay. I am working on a task, in that I need to convert the list content in XML to liferay article. In short, I am converting huge list of content into Liferay article.
I have developed a portal, through that I am importing a content into liferay. During importing time,few minutes successfully import the content into liferay. After few minutes, I got below exception. I have tried many times to import, But I failed to import complete content into liferay.
importing:java.lang.ArrayIndexOutOfBoundsException
Aug 27, 2015 9:38:16 AM org.apache.catalina.core.ApplicationDispatcher invoke
SEVERE: Servlet.service() for servlet jsp threw exception
java.lang.NullPointerException
atcom.liferay.portal.service.permission.PortletPermissionImpl.contains(PortletPermissionImpl.java:305)
atcom.liferay.portal.service.permission.PortletPermissionImpl.contains(PortletPermissionImpl.java:226)
atcom.liferay.portal.service.permission.PortletPermissionImpl.contains(PortletPermissionImpl.java:211)
atcom.liferay.portal.service.permission.PortletPermissionImpl.hasAccessPermission(PortletPermissionImpl.java:436)
atcom.liferay.portal.service.permission.PortletPermissionUtil.hasAccessPermission(PortletPermissionUtil.java:278)
atcom.liferay.portlet.SecurityPortletContainerWrapper.hasAccessPermission(SecurityPortletContainerWrapper.java:344)
atcom.liferay.portlet.SecurityPortletContainerWrapper.check(SecurityPortletContainerWrapper.java:209)
atcom.liferay.portlet.SecurityPortletContainerWrapper.checkRender(SecurityPortletContainerWrapper.java:243)
atcom.liferay.portlet.SecurityPortletContainerWrapper.render(SecurityPortletContainerWrapper.java:139)
atcom.liferay.portlet.RestrictPortletContainerWrapper.render(RestrictPortletContainerWrapper.java:126)
atcom.liferay.portal.kernel.portlet.PortletContainerUtil.render(PortletContainerUtil.java:156)
atcom.liferay.portal.layoutconfiguration.util.PortletRenderer._render(PortletRenderer.java:125)
atcom.liferay.portal.layoutconfiguration.util.PortletRenderer.access$4(PortletRenderer.java:107)
atcom.liferay.portal.layoutconfiguration.util.PortletRenderer$PortletRendererCallable.doCall(PortletRenderer.java:180)
atcom.liferay.portal.layoutconfiguration.util.PortletRenderer$PortletRendererCallable.doCall(PortletRenderer.java:1)
atcom.liferay.portal.kernel.executor.CopyThreadLocalCallable.call(CopyThreadLocalCallable.java:69)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
atcom.liferay.portal.kernel.concurrent.ThreadPoolExecutor$WorkerTask._runTask(ThreadPoolExecutor.java:682)
atcom.liferay.portal.kernel.concurrent.ThreadPoolExecutor$WorkerTask.run(ThreadPoolExecutor.java:593)
at java.lang.Thread.run(Thread.java:745)
09:38:16,735 ERROR [http-bio-9001-exec-134][status_jsp:753] javax.servlet.ServletException: java.util.concurrent.ExecutionException: com.liferay.portal.kernel.portlet.PortletContainerException: com.liferay.portal.kernel.portlet.PortletContainerException: java.lang.NullPointerException
As a workaround of this, you can consider increasing the max queue size:
index.search.writer.max.queue.size=9999999
Also, you can add the following which makes disk writes less often:
lucene.commit.batch.size=10000
lucene.commit.time.interval=300000
You can consider referring this defect notes for more information.
Cheers!
AJ
P.S. This is just a possible workaround or tuning thing, but I think there would be a better solution somewhere in case the above is not.
I want to execute instance of supertype AbstractEntryProcessor (lets say SomeEntryProcessor) with IMap.executeOnKey method.
Server side ClassLoader doesn't have this class (SomeEntryProcessor).
So it expectedly fails with:
java.lang.ClassNotFoundException: com.package.SomeEntryProcessor
com.hazelcast.nio.serialization.HazelcastSerializationException: java.lang.ClassNotFoundException: com.package.SomeEntryProcessor
at com.hazelcast.nio.serialization.DefaultSerializers$ObjectSerializer.read(DefaultSerializers.java:190) ~[hazelcast-3.2.3.jar:3.2.3]
at com.hazelcast.nio.serialization.StreamSerializerAdapter.read(StreamSerializerAdapter.java:40) ~[hazelcast-3.2.3.jar:3.2.3]
at com.hazelcast.nio.serialization.SerializationServiceImpl.readObject(SerializationServiceImpl.java:279) ~[hazelcast-3.2.3.jar:3.2.3]
at com.hazelcast.nio.serialization.ByteArrayObjectDataInput.readObject(ByteArrayObjectDataInput.java:433) ~[hazelcast-3.2.3.jar:3.2.3]
at com.hazelcast.map.client.MapExecuteOnKeyRequest.read(MapExecuteOnKeyRequest.java:88) ~[hazelcast-3.2.3.jar:3.2.3]
But after this executeOnKey hangs forever.
I believe this happens due to infinite wait in method
ClientCallFuture.get(long timeout, TimeUnit unit) {
...
this.wait(waitMillis); // line 103 in hazelcast 3.2.3
}
Has anyone seen the same?
Created an issue https://github.com/hazelcast/hazelcast/issues/3842, but no response received
Sorry somehow missed the issue. Can you try a 3.3.x release? I guess the issue is fixed on those versions.