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"?
Related
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
I am currently working on liferay upgradation from 6.0 to 6.2.2 GA3. I tried upgrading the services portlet. The services portlet of 6.0 version is built using mvn services-portlet-archetype whereas for 6.2 version the archetype is liferay-servicebuilder-archetype. The difference is that in 6.2 liferay-servicebuilder-archetype there are two modules:
Module 1: is a portlet which has our code logic
Module 2: is the services-portlet which has the class files generated during liferay:build-service. These files are archived into jar file which is later used inside the portlet(Module 1) module for the creation of the WAR file.
Whereas in 6.0, there is no concept of modules. The services class files generated during liferay:build-service are generated inside services folder under src/.
This liferay-servicebuilder-archetype is available only from Liferay 6.1+ versions as seen in mvnrepository. My guesses for the need of this new archetype from 6.1 version are:
1. To avoid committing the auto generated services files by mistake to our version control repo.
2. To be more modular.
But with this new archetype I found out that the build process consumes lot of permgen space and heap space(I have to double the heap and permgen space everytime I run the mvn clean package liferay:build-service as observed through jvisualvm). I was able to create the same portlet with services-portlet-archetype successfully deployed and working in 6.2 GA3 server(without extra permgen space and heapspace). But did not find any memory issues during its build.
My questions are:
1. Which of these two archetypes(liferay-servicebuilder-archetype or services-portlet-archetype) is a good practice for liferay 6.2 GA3.
2. Going forward if I need to upgrade all the 20+ portlets which I am using in my project should I need to create from archetype? (Takes lot of time and effort).
3. How to fix this issue of extra memory consumption if using liferay-servicebuilder-archetype is the best practice. The target folder seems to produce more class files than in services-portlet-archetype target folder.
4. The need for this new archetype is for the two benefits mentioned above(which I guessed) or is there anything else?
After waiting for 2+ weeks for an answer to this question, I am assuming that my following guesses are the correct answer to this question.
The need for this new archetype from 6.1 version is:
1. To avoid committing the auto generated services files by mistake to our version control repo.
2. To be more modular.
If there is a more convincing answer, I will choose that to be the best answer.
EDIT::::
Found this link useful
https://www.liferay.com/community/forums/-/message_boards/message/51303796
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.
I have an app that uses apache-commons-collections v3.2.1. When I deploy the war file using the WAS 6.1 Integrated Solutions Console I get errors because the commons-collections.jar file in isclite.ear gets loaded before the one that I bundle with my .war file. The problem is that my application requires v3.0.0+ of commons collections. The one in isclite.ear is version 2.1.
So, can I deploy into WAS 6.1 without involving isclite? Can I just drop a war file into a directory somewhere? Is there an option I can select in the process of deploying through the admin interface to skip or remove the isclite.ear dependency?
Thanks.
I had a very similar problem with ColdFusion where a jar in the server was a different version than the one that was needed by my application. I had to call a non-delegating loader (one that doesn't ask the parent to first load the class before loading the requested jar). The loader I used is open source. You can find out about it at
http://groups.google.com/group/javaloader-dev
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.