Fórumok

Including Calendar Service in Custom Portlet

Manohar Reddy, módosítva 8 év-val korábban

Including Calendar Service in Custom Portlet

Junior Member Bejegyzések: 48 Csatlakozás dátuma: 2014.08.07. Legújabb bejegyzések
Hi,

I have a requirement like using calendar portlet service classes in other portlets . For this one I have two Options . They are
1. Using Web service call.
2. Moving the calendar portlet jar file into tomcat ext folder.
But Mostly I am written the java code in my requirement.
Please help me which approach is giving better performance.

Thanks.
Manohar
thumbnail
Olaf Kock, módosítva 8 év-val korábban

RE: Regarding performance .

Liferay Legend Bejegyzések: 6396 Csatlakozás dátuma: 2008.09.23. Legújabb bejegyzések
My vote:
3. edit your plugin's WEB-INF/liferay-plugin-package.properties to contain the line:

required-deployment-contexts=calendar-portlet


This will automatically copy calendar-portlet-service.jar into your dependent plugin.
thumbnail
David H Nebinger, módosítva 8 év-val korábban

RE: Regarding performance .

Liferay Legend Bejegyzések: 14914 Csatlakozás dátuma: 2006.09.02. Legújabb bejegyzések
Olaf Kock:
My vote:
3. edit your plugin's WEB-INF/liferay-plugin-package.properties to contain the line:

required-deployment-contexts=calendar-portlet


This will automatically copy calendar-portlet-service.jar into your dependent plugin.


Um, no it doesn't automatically copy.

The Liferay IDE will auto-copy service jars into WEB-INF/lib if the service-providing portlet project is also opened in the IDE. It's really a pretty limited use case.

The correct version of #3 is:

3. Have the calendar-portlet-service.jar in your WEB-INF/lib directory.

This can be accomplished sometimes by the IDE, sometimes by copying the jar manually (if using ant) or installing the jar in the local repo and declaring as a pom dependency so maven installs the jar.
thumbnail
Olaf Kock, módosítva 8 év-val korábban

RE: Regarding performance .

Liferay Legend Bejegyzések: 6396 Csatlakozás dátuma: 2008.09.23. Legújabb bejegyzések
David H Nebinger:
Olaf Kock:
My vote:
3. edit your plugin's WEB-INF/liferay-plugin-package.properties to contain the line:

required-deployment-contexts=calendar-portlet


This will automatically copy calendar-portlet-service.jar into your dependent plugin.


Um, no it doesn't automatically copy.

The Liferay IDE will auto-copy service jars into WEB-INF/lib if the service-providing portlet project is also opened in the IDE. It's really a pretty limited use case.



I'm afraid, this is wrong. The copying will happen when Liferay deploys a plugin from its own deploy folder to the application server. IDE in addition will make the dependency available, but not through a physical copy.

If you just run "ant war", you'll see that WEB-INF/lib is empty, there's no xxx-service.jar in there, but it will be there once the application is deployed. When you're editing the plugin that's dependent on another one in Liferay-IDE, IDE will know of this dependency, but not more.
thumbnail
David H Nebinger, módosítva 8 év-val korábban

RE: Including Calendar Service in Custom Portlet

Liferay Legend Bejegyzések: 14914 Csatlakozás dátuma: 2006.09.02. Legújabb bejegyzések
Sorry, Olaf, just did it.

Source project attached, does nothing but add calendar as a required deployment context (requires your maven profile is properly set but builds an empty war with no WEB-INF/lib dir).

When deployed, even though it has the required deployment context entry for calendar, you will not get the service jar injected. I'll even include the war for you to deploy locally and test.

Tried it in both the latest CE and EE, same thing, no injected service jar.
thumbnail
Olaf Kock, módosítva 8 év-val korábban

RE: Including Calendar Service in Custom Portlet

Liferay Legend Bejegyzések: 6396 Csatlakozás dátuma: 2008.09.23. Legújabb bejegyzések
David H Nebinger:
Sorry, Olaf, just did it.


In that case, I'd settle for both of us being right, just working in different environments: I've tried with Ant, while you worked with Maven. Sounds better than both of us being wrong emoticon
thumbnail
David H Nebinger, módosítva 8 év-val korábban

RE: Including Calendar Service in Custom Portlet

Liferay Legend Bejegyzések: 14914 Csatlakozás dátuma: 2006.09.02. Legújabb bejegyzések
Ant shouldn't make any difference - the tool will create a war w/ a liferay-plugin-package.properties file that declares the required deployment context only. I know Ant doesn't copy in the service jar either, but the IDE definitely will if the project that exposes the service is open in the IDE. That's the only time I've ever seen the service jar get injected into a project.

The issue is that a required deployment context just points at a target war file, but it does not and can not indicate what jar file within that war that you may actually be dependent upon.
thumbnail
Olaf Kock, módosítva 8 év-val korábban

RE: Including Calendar Service in Custom Portlet

Liferay Legend Bejegyzések: 6396 Csatlakozás dátuma: 2008.09.23. Legújabb bejegyzések
Well, then we can't agree to disagree. IMHO (and I'm going to double check it once I'm back on a decent computer) IDE makes the service-jar available to your dependent web application, but does not physically copy it to the project. It won't be copied to the deployed war. When you redeploy your service-containing plugin, the dependent plugin will be redeployed and get the updated service-jar injected. And this is what I'm going to check soon to settle this once and for all. I'll be lazy and use Ant.
thumbnail
David H Nebinger, módosítva 8 év-val korábban

RE: Including Calendar Service in Custom Portlet

Liferay Legend Bejegyzések: 14914 Csatlakozás dátuma: 2006.09.02. Legújabb bejegyzések
I've always encountered the opposite. If the plugin providing the service (and the service jar) is open in the Liferay IDE or Dev Studio, when you declare a required deployment context dependency in another project the IDE copies the service jar into the project right away.

In order to test out, be sure not to use the IDE at all as that's the variable in the mix...