Fórum

Liferay’s public API

Balaji Chopparapu, modificado 12 Anos atrás.

Liferay’s public API

New Member Postagens: 22 Data de Entrada: 08/10/10 Postagens Recentes

Hi,

I am trying to write a portlet that consumes liferay “Message Services”. As per the book “Liferay in Action” the author suggested to consume “Liferay’s public API,” to do the task.

What is Liferay Public API? Is it the SOAP api exposed by the Liferay “http://localhost:8080/api/axis/Portlet_MB_MBMessageService?wsdl”? What are the disadvantages in consuming api directly from LocalServiceUtil (“MBMessageLocalServiceUtil”). Will the methods exposed here are subjected to change in future release?

Please suggest.
~Balaji
thumbnail
Richard Sezov, modificado 12 Anos atrás.

RE: Liferay’s public API

Regular Member Postagens: 220 Data de Entrada: 07/02/07 Postagens Recentes
Hi Balaji,

That phrase didn't sound familiar to me, so I just did a search of my book and it doesn't appear anywhere. Is it possible you're referencing another Liferay book?

Regardless, Liferay's public API is what's available to a Liferay plugin. When Liferay is installed, the portal-service.jar is placed on the server's global classpath, and contains Liferay's public API. You can find Javadoc for it here.

Hope this helps!

--Rich
Balaji Chopparapu, modificado 12 Anos atrás.

RE: Liferay’s public API

New Member Postagens: 22 Data de Entrada: 08/10/10 Postagens Recentes
Hi Rich,

I really appreciate for the wonderful book your wrote on Liferay. A good technology needs good documentation. It helps people to adapt the technology quickly. Your book “Liferay in Action” will help developers to adapt liferay.

In book you mentioned “public API” in Page 213,243 but there is no detail explanation about it.

As per the post the api exposed by “portal-service.jar” is public api but I am little bit concerned about the statement, because any public api needs to go through standard deprecation process but it is not true for the classes exposed by portal-service.

For example:

From liferay 5.2 to 6.1

Following classes are renamed and refactored:
MBMessageFlagLocalServiceUtil (5.2) -> MBThreadFlagLocalServiceUtil (6.1)
BBCodeUtil (5.2) ->BBCodeTranslatorUtil (6.1)

Following methods are removed:

public void setTagsEntries(String[] tagsEntries) in com.liferay.portal.service.ServiceContext
public static void reIndex(long messageId) throws com.liferay.portal.SystemException in com.liferay.portlet.messageboards.service.MBMessageLocalServiceUtil
public static com.liferay.portal.kernel.search.Hits search(long companyId, long groupId, long userId, long[] categoryIds, long threadId, java.lang.String keywords, int start, int end) throws com.liferay.portal.SystemException in com.liferay.portlet.messageboards.service.MBCategoryLocalServiceUtil

Currently I am assigned a task to migrate our application based on liferay from 5.2 to 6.x , but I observed this is a major task and when I compile our ext module it gives me 1300 compilation error that needs to be fixed.


I believe it is better for applications to consume liferay api that go through standard depreciation process.


My question is it safe to use liferay public api? Will they not be change in future release?

For example:
Can I use the methods in “MBMessageLocalServiceUtil” will they not be changed in future release?

Thanks in Advance.
~Balaji
thumbnail
Hitoshi Ozawa, modificado 12 Anos atrás.

RE: Liferay’s public API

Liferay Legend Postagens: 7942 Data de Entrada: 24/03/10 Postagens Recentes
I believe it is better for applications to consume liferay api that go through standard depreciation process.


Wholly agree with you. APIs have changed from 6.0.6 to 6.1.0GA in a similar non-depreciation process. It's really not the book's fault
but more of programming practices by Liferay.com's developers.
thumbnail
Jan Eerdekens, modificado 12 Anos atrás.

RE: Liferay’s public API

New Member Postagens: 15 Data de Entrada: 20/01/11 Postagens Recentes
This has been happening time and time again during the last few years I've worked with Liferay and it is really starting to get on my nerves. The APIs aren't that good to begin with, but when they keep changing like they do without a correct deprecation and documentation path it is just pure hell. Not to mention that it is really hard to explain to customers why a simple minor version upgrade causes such a lot of possible development work just to keep the existing code running.