You can always use patching tool’s auto-discovery option to generate a profile. In case you are not able to use that following are the sample settings for JBoss. Just create default.properties under patching-tool directory
This post is not necessarily about any specific technology. Just wanted to tell you about one possible reason for this commonly faced problem. I was working on a Spring MVC application lately and I got the following error
SEVERE [localhost-startStop-4] org.apache.catalina.core.ContainerBase.addChildInternal ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/springcaptcha]]
Caused by: org.apache.catalina.LifecycleException: Failed to start component [org.apache.catalina.webresources.StandardRoot@70d8c322]
… 10 more
Caused by: org.apache.catalina.LifecycleException: Failed to initialize component [org.apache.catalina.webresources.JarResourceSet@2e94c523]
… 13 more
Caused by: java.lang.IllegalArgumentException: java.util.zip.ZipException: error in opening zip file
… 16 more
Caused by: java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
… 17 more
Now, there could be various reasons why this could be happening. I am just going to tell how I resolved it.
I was using Maven for my builds and it happened that some of the dependency jars downloaded by Maven are not valid. They were Zero Byte, 1Byte jars. Obviously, Tomcat was trying to load those jars and was not able to do so. I resolved this error by manually copying jars from Maven Repos and changing some of the dependencies. In your case check if you can do the same.
Other Possible Reasons:
Check if your jar has proper permissions for the system user which is running Tomcat
Try to open the file in Zipeg , Winrar, Winzip or any equivalent unzipping system and verify if any of the jar in the classpath is not corrupt. Look for suspiciously smaller sized files
In Liferay development, it’s very useful to have Source Code available to you for the purpose of troubleshooting and debugging. This is especially useful when you get an error in the log on the server with a stack trace and a line number. With the source code, you can always look at the code and investigate in detail the root cause of the error. You can always download the Source Code of your portal from liferay.com and setup with your IDE(this is useful for local debugging with breakpoints)
However, this becomes challenging when you have Liferay EE subscription and you have applied patches to your portal. It is possible that your source code is out-of-date/out-of-sync with your deployed portal code. Luckily, Liferay patching tool provides you a way to patch your source code.
To begin, go to your patching-tool directory
Create a new profile to be used for patching the source code. To achieve this create patch-source.properties under patching-tool directory
Recently we had a requirement where we want all our new articles to go live next day, up for review in 6 months and automatically expire in 1 year. Of course, all this can be overriden by content authors at the time of content creation. But these are the defaults we wanted. To achieve this you have to override JournalArticle model hint as defined in portal-model-hints.xml. Here are the defaults in Liferay
To override this you will have to create an ext(unfortunately that’s the only way to go). In your ext’s ext-impl/src/META-INF folder create ext-model-hints.xml. Copy the <model name=”com.liferay.portlet.journal.model.JournalArticle”> section from portal-model-hints.xml and change the relevant settings. here are the changes we made to meet our needs
Disclaimer – Following is not the best or optimal solution. If you have better suggestion please write in comments
JournalVmUtil was present upto Liferay 5.2 and then deprecated in Liferay 6.0 and then completed removed in Liferay 6.1. If you are upgrading to 6.1 and make extensive use of JournalVmUtil you can do the following.
Extend VelocityTemplateParser.java. Following code example is just a sample. Feel free to add any pre-processing or post-processing as required
As far as my experience is concerned, this error means that your database is referring to theme which is not present. To make sure run the following commands
Now go to liferay’s Control Panel -> Plugin Configuration -> Theme Plugins tab and click on the theme in question. See the
Plugin ID of the theme. It should match what is there in layout and layoutset tables. If it doesn’t then you have to either change themeid or update database tables. If you happen to update DB don’t forget to restart or clear DB cache.
Note : Use caution while trying this for the production installation. For production, it’s better to use technics like “Forgot Password”
If you forget password for your local admin account in Liferay, then stop the server and run the following command
Where mynewpassword is your new password. Now restart the server. This time you should be able to login with your new password. As soon as you login, Liferay should prompt you for password change. Change your password and try to remember it this time 😉