We are upgrading from Liferay 4.2 to Liferay 5.2.2. We are using the EXT environment. Previously, in 4.2 there was a directory called /ext/portlets. According for 4.2 doc,
"Portlets placed in this directory will be automatically deployed to the application server when running the ant deploy target from the /ext directory"
Is there an equivalent for 5.2?
At first I though that /ext/modules would do the trick, but it looks like the build file inside of /modules just unwars my portlet war file. This is not sufficient to deploy the portlets, since Liferay needs to augment the web.xml in my portlets' WEB-INF to insert servlet mapping tags.
Just for comparison, 4.2's build file in /ext/portlets directory, would call com.liferay.portal.tools.PortletDeployer and pass my war file as an argument.
I looked around, the PortletDeployer still exists in the 5. 2 code base. It is now located in com.liferay.portal.tools.deploy, but it is not called anywhere from the build files. . I wonder if this means that there is no longer a way to predeploy portlets in 5.2 Liferay. Does Liferay have to be up and running to deploy in 5.2?
If your portlets are bundled as war, and are not required to run in the same webapp as Liferay, just put your wars in the liferay deploy dir. This directory is defined in your portal-ext.properties file, and overrides the bundled portal.properties file definition of
auto.deploy.deploy.dir=${liferay.home}/deploy
At startup, Liferay scans this directory and installs any found "plugin" (portlet, theme, layout, hook...).
You may be interested in the plugins SDK for the portlet and theme creation as it could help you separate portlet developpement and core portal extension.
You should also be careful regarding your theme, it may require migration to comply to the 4.3 onward themes.
Related
I'm looking for the jar for the com.liferay.blogs.service.permissions package. I've managed to track it down to an export of the system bundle, i.e. bundle 0. But I can't figure out where Liferay keeps this bundle.
My question, then, is as follows: where does Liferay DXP deployment?
Liferay keeps bundles for the OSGi framework at the osgi directory.
The blogs bundle is actually inside a wrapping file (Liferay package) inside the osgi/marketplace
ps: you can extract those packages by the way, similar to jars, on to this date at least, they are just compressed files.
I deployed a portlet in liferay 7 and it got deployed successfully and was available for use. I want to replace the jsp file, in earlier version I could see my application in tomcat/webapps folder and replace it quickly.
Now I am unable to locate the exploded war in liferay 7. I can only see the war in osgi/war folder.
Can someone help me with that.
Thanks in advance.
While I mostly agree with what Olaf wrote, I do understand the need to be able to make changes in JSP files and try them quickly during development. I'm afraid I don't have the solution for that yet.
However, let me answer the question you asked:
where is war exploded in Liferay 7 tomcat after getting copied in osgi folder
It is NOT (at least not the way it was done by application servers)! When you deploy a WAR file in Liferay 7, it will automatically (on the fly) convert it into OSGi bundle and install it in OSGi runtime. This way now Liferay is fully in charge of deploying plugins and does not need to rely on various application servers.
PLEASE NOTE: Every bundle has it's own state folder. In Liferay those are in <LIFERAY_HOME>/osgi/state. If you know the bundle ID you can easily find it. It may be (I haven't checked) that you'll find some JSP files there. The reason I'm writing this is to warn you (in case you figured it yourself) to NEVER modify bundle's state folder manually. Doing so may brake the whole environment. In worse case scenario you may have to redeploy everything in clean environment.
You should not rely on behavior like this. In previous versions it was the task of the application server to compile changed JSPs at runtime. However, this is bad practice in production systems and totally screws up your maintainability. If you need to update some UI code frequently, I'm suggesting you change your implementation to utilize ADT (Application Display Templates), e.g. through Freemarker or Velocity. Those are meant to be updated at runtime, where the JSP updates were a side effect of Tomcat's default (development friendly, production hostile) configuration
first intro: I try to get a hook running on a new Liferay 6.1.2 GA3. Previously I was using the portlet plugin mechanism only.
I try to get a simple calendar hook running and get compiler errors, such as "CalEvent cannot be resolved as a type".
My feeling is that I am missing the entire Liferay libraries in the hook, but the included libraries look complete to me (in order of build path priority):
- ear libraries
- Java JDK 6
- Liferay Hook Plugin API
- Liferay V6.1 CE (Tomcat 7)
- Web App Libraries
The libraries got automatically selected when creating the project as a hook. Any ideas?
com.liferay.portlet.calendar.model.CalEvent is in portal-service.jar. This should be on the classpath of your hook and Liferay IDE/DevStudio typically adds this library when you create a new hook. If it's not there, add it. You'll find it on the global classpath of your tomcat installation, e.g. ${liferay.home}/tomcat/lib/ext - assuming that you develop on tomcat.
If you need to add this file to the project, make sure it doesn't get packaged in the plugin's WEB-INF/lib folder - it needs to be picked up from the global classpath when deployed.
You do get the errors during development time (e.g. in IDE), not when you're deploying, right?
Or is it as simple as a forgotten "organize imports"?
A very strange issue happening.
I have developed an application under JSF and Primefaces on tomcat 6 on my local computer. Everything works perfect.
But when I deploy the application on remote tomcat 6 (Under enterprise RedHat Linux), the primefaces stops working. The funniest part:
the response takes a lot of time, and it returns the generated html (so it seems like it calls the lifecycle). But no components are rendered (there is plain lot of html intermixed with javascript functions) - p:tabView and other components` contents are rendered as simple lines of text.
But as for the Javascript, it states - ReferenceError: PrimeFaces is not defined.
Catalina log file states nothing.
I have no idea what it can be. Is there any idea?
1) Check what dependencies your project has in eclipse build path. Verify all of them are available in your remote server . All the dependencies in build path should be copied to the lib folder in war file you are generating(unless they are runtime like tomcat,jdk etc).
2) Verify your web.xml and faces-config.xml is same in your eclipse and war deployed in remote.
If it doesn't work then you can compare the temp folder in your eclipse to the war you are deploying contains everything that is in local.
You can find your local war by searching for your project file in eclipse under your workspace
The problem was security for Tomcat. It did not allow any redirections so the js-files were listed in the links but nothing was fetched. Problem was solved by reinstalling tomcat.
I'm developing a Liferay application, consisting on 2 different portlets, an both have to make certain operations in common, so I decided to put that operations in static methods in an external Utils class.
I have to externalize that class to avoid duplicating the same code in both portlets, and I want to have the portlets in different WAR files.
I know I can package the Utils class in a JAR file, but we are still developing and we don't want to regenerate the JAR and restart the Tomcat for every change.
Which is the best option and how can I perform it?
If you're using the Liferay SDK, you can use the clients (recently changed to shared) directory to put your common code.
A good example is how deploy-listener-shared is used in conjunction with deploy-listener-hook.
From what it looks like, all the configuration you need to do is to modify your build.xml files that will use the client\shared classes. If you look at build file of deploy-listener-hook you can see all you need to add is the.
For the new SDK:
<property name="import.shared" value="my-utils-shared" />
For the older SDK:
<property name="dependent.clients" value="my-utils-client" />
Hope this helps!
There is another method that involves building a JAR file but it doesn't require a server restart (on Tomcat at least).
Write a build script for your JAR file so it compiles, builds the JAR and finally copies it to the following location:
{tomcat}/webapps/ROOT/WEB-INF/lib
Then in your portlet open the "liferay-plugin-package.properties" (in Liferay Developer Studio / Liferay IDE this should open with a nice GUI).
Then add the name of your JAR to the "portal-dependency-jars" list in this file so in the source it would like (Or just hit the "Add" button in the GUI and select the JARs you want):
portal-dependency-jars=my-custom-lib.jar,my-other-custom-lib.jar
Save the file, and redeploy the portlet, and the JAR will be copied across when the portlet is deployed.
I've used this method for custom JARs, and 3rd party JARs that I've needed to use in my portlets.
For the development phase just package the jar file with both applications.
Unless one application depends on the other somehow it is completely ok.
Another solution is to use JRebel tool. It will allow you to redeploy jar in tomcat without restarting.
Also you may have several portlets in one .war. You may just define them both in portlet.xml.