Forums

Home » Liferay Portal » English » 3. Development

Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
Balaji Chopparapu
Liferay’s public API
January 25, 2012 3:49 AM
Answer

Balaji Chopparapu

Rank: New Member

Posts: 22

Join Date: October 8, 2010

Recent Posts


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
Richard Sezov
RE: Liferay’s public API
January 25, 2012 8:06 AM
Answer

Richard Sezov

LIFERAY STAFF

Rank: Regular Member

Posts: 210

Join Date: February 7, 2007

Recent Posts

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
RE: Liferay’s public API
January 25, 2012 10:26 PM
Answer

Balaji Chopparapu

Rank: New Member

Posts: 22

Join Date: October 8, 2010

Recent Posts

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
Hitoshi Ozawa
RE: Liferay’s public API
January 26, 2012 4:37 AM
Answer

Hitoshi Ozawa

Rank: Liferay Legend

Posts: 7949

Join Date: March 23, 2010

Recent Posts

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.
Jan Eerdekens
RE: Liferay’s public API
March 1, 2012 7:27 AM
Answer

Jan Eerdekens

Rank: New Member

Posts: 15

Join Date: January 20, 2011

Recent Posts

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.