Forums

Home » Liferay Portal » English » 3. Development

Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
Omkar Khandare
I want one common service builder portlet for all other portlets.
February 20, 2013 4:22 AM
Answer

Omkar Khandare

Rank: Junior Member

Posts: 40

Join Date: March 6, 2012

Recent Posts

I want to create one common datamodel portlet with service.xml containing all entities
to be used by all other portlets.

even if they ahve any extra columns in their table for entity
then they can be able to add the service.xml with additional fields along with old fields in
parent entities mentioned in common datamodel portlet.

How this common data modelling can be achieved.
Plz Help.
David H Nebinger
RE: I want one common service builder portlet for all other portlets.
February 20, 2013 5:33 AM
Answer

David H Nebinger

Community Moderator

Rank: Liferay Legend

Posts: 9269

Join Date: September 1, 2006

Recent Posts

Don't understand the question here...

You are free to (and encouraged to) create a single portlet plugin that has your service.xml file that covers all of your entities. You then share the service jar with all other portlets, thus exposing your single service layer to all.
Omkar Khandare
RE: I want one common service builder portlet for all other portlets.
February 20, 2013 6:38 AM
Answer

Omkar Khandare

Rank: Junior Member

Posts: 40

Join Date: March 6, 2012

Recent Posts

means i have to include service jar file of my common portlet into other portlets lib folder..??

So then how i can be able use all services of create, update & delete for any entity..?

& can i be able reuse columns of any entity & add more if needed.?

can explain in detail.
as I am using service builder for my project first time,
I don't know how can do common data modelling & implement the same.

Thanks
David H Nebinger
RE: I want one common service builder portlet for all other portlets.
February 20, 2013 6:51 AM
Answer

David H Nebinger

Community Moderator

Rank: Liferay Legend

Posts: 9269

Join Date: September 1, 2006

Recent Posts

Omkar Khandare:
means i have to include service jar file of my common portlet into other portlets lib folder..??


If you use the IDE and use the required deployment context in the other plugins, the service jar will be copied automatically.

So then how i can be able use all services of create, update & delete for any entity..?


The service jar will create XxxLocalServiceUtil classes which expose methods you can use for CRUD operations.

& can i be able reuse columns of any entity & add more if needed.?


Yes, and it's much easier. Use the service.xml to add new columns, rebuild the services, and your updated entities with new columns are there.
Hitoshi Ozawa
RE: I want one common service builder portlet for all other portlets.
February 20, 2013 2:04 PM
Answer

Hitoshi Ozawa

Rank: Liferay Legend

Posts: 7949

Join Date: March 23, 2010

Recent Posts

means i have to include service jar file of my common portlet into other portlets lib folder..??


If you're going to have just one service jar file, do what liferay is doing and put the file in the application server's lib\ext directory.

Information on Service Builder is provlded in Liferay's online documentation:
http://www.liferay.com/documentation/liferay-portal/6.1/development/-/ai/service-build-5

BUT before doing that,

as I am using service builder for my project first time,
I don't know how can do common data modelling & implement the same.


Please also read the forum guidelines. Search and read before you post. There's plenty of information available.
http://www.liferay.com/community/forums/-/message_boards/message/572822
David H Nebinger
RE: I want one common service builder portlet for all other portlets.
February 20, 2013 3:31 PM
Answer

David H Nebinger

Community Moderator

Rank: Liferay Legend

Posts: 9269

Join Date: September 1, 2006

Recent Posts

Hitoshi Ozawa:
If you're going to have just one service jar file, do what liferay is doing and put the file in the application server's lib\ext directory.


I typically do not recommend this because of the restart requirement necessary for deploying updates. Liferay doesn't have this issue because it is handled by doing a full portal upgrade, but for a constantly changing service layer (adding new entities, methods, etc.) dealing w/ a server restart can be a pain.
Omkar Khandare
RE: I want one common service builder portlet for all other portlets.
February 20, 2013 7:58 PM
Answer

Omkar Khandare

Rank: Junior Member

Posts: 40

Join Date: March 6, 2012

Recent Posts

Thanks Hitoshi & David.

I started working with it.
I am going well,
Only thing is, now i manually copied that jar file of common service into other portlet lib folders.
So now i am able instantiate all methods of xxxLocalServiceUtil.java & xxx.java in my xxxPortletAction.java methods.

Records are getting saved & fetched as well.

For development i will use in my portlets lib folder & at time of deployment I'll put that jar into Tomcat lib folder.

Thanks again.
Carter Chen
RE: I want one common service builder portlet for all other portlets.
March 25, 2015 1:19 AM
Answer

Carter Chen

Rank: New Member

Posts: 1

Join Date: March 25, 2015

Recent Posts

Omkar Khandare:
means i have to include service jar file of my common portlet into other portlets lib folder..??


If you were using Maven to build your project, you can just add your shared Service as a dependency to other Porlets.
David H Nebinger
RE: I want one common service builder portlet for all other portlets.
March 25, 2015 6:00 AM
Answer

David H Nebinger

Community Moderator

Rank: Liferay Legend

Posts: 9269

Join Date: September 1, 2006

Recent Posts

Carter Chen:
If you were using Maven to build your project, you can just add your shared Service as a dependency to other Porlets.


It's not that simple.

On the service providing project you have to be religious about updating your pom's project version specification any time the services need to be rebuilt and you have to "mvn install" or "mvn deploy" (depending upon whether you have a local maven repo or not).

You still have the dependency issue in that all plugins that are dependent upon the service jar will need their poms updated with the new version and the plugins will need a (clean) rebuild and deploy. And you have to monitor the deployment to ensure that the old service jar really does get removed also.