I have a portlet project that needs to do some Group querying. I've not created the project but it was made with the Eclipse Liferay SDK plugin.
I've added a DynamicQueryFactoryUtil.forClass(Group.class) but it fails in runtime. It complains about not finding GroupImpl.class, which is implementation for interface Group. My project dependencies doesn't include portlet-impl (it contains GroupImpl.class).
I'm not sure if I should:
include that jar into dependencies for compiling
include that jar into portlet jar
Or I'm doing something wrong and querying groups would be available right out of the box.
PS: I'm pretty newbie in Liferay things...
PS2: It's Liferay 6.1
To enable Liferay to retrieve the right class, you need to provide a correct classloader to the initialization of your DynamicQuery, in this case the portal's classloader because that one has access to the model implementations:
DynamicQueryFactoryUtil.forClass(Group.class, PortalClassLoaderUtil.getClassLoader())
Related
I'm using Liferay 7.1 GA1 Version. I have generated my service/api java classes with service-builder that Liferay IDE provides me.
How can I use these service classes in my other modules? I would like to use "MyServiceBuilder" generated classes in "MyPortlet" like you can see in the following picture.
Thanks.
Picture
Structure your project like this:
in the gradle file of the portlet add:
compileOnly project(":modules:test-service:test-service-api")
Right click and select Gradle > Refresh Gradle Project on the test-service folder.
Then use OSGi Declarative Services in your portlet:
#Reference
protected FooLocalService _fooLocalService;
Domino Designer is based on Eclipse so I can change most of project's properties, like the build path and so on.
The Java team gives us a JAR to implement in our XPages and our managed beans but it's a pain to not have the javadoc and sources associated to help us in our code.
I tried to associate Javadoc and sources in "Project properties > Java Build Path > Librairies" to the JAR but it's lost when I save and re-open (the JAR is store in Code/Jars).
Is there another way to use a JAR and those resources ?
Including the source code in the jars will work. That's what we do for OpenNTF Domino API.
Maybe by digging into the files in Package Explorer it would be possible to work out where it's set and automate setting it (possibly from xsp.properties or notes.ini or somewhere else) via a custom builder. Swiper on OpenNTF is an example of a DDE plugin that adds a custom builder.
I need to share multiple classes and properties file between portlets.
So I made a portlet Common-portlet, and in the rest of the portlets I made it as required development context in liferay-plugin-package.properties.
In eclipse, I also added the Common-portlet into the rest of the portlet's classpath.
After doing this eclipse shows no error.
But when I run the rest of the portlets it shows:
java.lang.NoClassDefFoundError: com/xxx/xxxxxxx/xxxxx/util/JSONUtil.
Is the approach above correct?
If yes then what I am lacking.
If no then what can be a better approach?
I would suggest create one separate java project and put all the common java file inside it and
extract the same as .jar file put it into tomcat-7.0.40\lib\ext and give a classpath refenerece from this directory or else in eclipse you can add this common project's reference all other portlet.
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"?
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.