Forums

Home » Liferay Portal » English » 3. Development

Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
natesh kurup
Service Builder does not create the entity relationships
July 26, 2010 2:32 AM
Answer

natesh kurup

Rank: New Member

Posts: 5

Join Date: July 14, 2010

Recent Posts

Hi,

Iam using Liferay 6.0.3. I have the following entries in my service.xml
 1
 2<entity name="Contingent" local-service="true" remote-service="false">
 3
 4        <!-- Primary key column -->
 5        <column name="contingentId" type="long" primary="true" id-type="increment" />
 6
 7        <!-- Other columns -->
 8        <column name="theme" type="String" />
 9        <column name="title" type="String" />
10
11        <column name="eventId" type="long" />
12
13
14        <!-- Sort order -->
15        <order by="asc">
16            <order-column name="contingentId" />
17        </order>   
18    </entity>
19
20    <entity name="Event" local-service="true" remote-service="false">
21        <!-- Primary key column -->
22        <column name="eventId" type="long" primary="true" id-type="increment" />
23
24        <!-- Other columns -->
25        <column name="name" type="String" />
26
27        <column name="contingentList" type="Collection" entity="Contingent"
28            mapping-key="eventId"/>
29       
30    </entity>


When i run the build-service task, i expected the EventModel class to have a collection of Contingent, but the entities that are generated have no relationship, neither is the relationship found in the generated portlet.hbm.xml.

Can anybody assist?

Regards

Natesh Kurup
Jaafar Altaie
RE: Service Builder does not create the entity relationships
June 30, 2012 1:11 PM
Answer

Jaafar Altaie

Rank: Junior Member

Posts: 69

Join Date: April 26, 2012

Recent Posts

Nitesh,

I'm also noticing that Service Builder isn't creating all of the required packages in my application. I'm thinking this could be to do with a problem with Liferay IDE, but I"m going to try using plain old ANT build to see if all the required packages are created. Meanwhile, would like to know if you found a solution. Thanks!
Juan Gonzalez
RE: Service Builder does not create the entity relationships
July 1, 2012 1:50 AM
Answer

Juan Gonzalez

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1872

Join Date: October 28, 2008

Recent Posts

Liferay doesn't create relationships that way. Whenever you add a FK, Liferay adds a getXXXX(Long idFK) method in XXXLocalServiceUtil, so search there for your method.
Juan Gonzalez
RE: Service Builder does not create the entity relationships
July 1, 2012 1:51 AM
Answer

Juan Gonzalez

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1872

Join Date: October 28, 2008

Recent Posts

Jaafar Altaie:
Nitesh,

I'm also noticing that Service Builder isn't creating all of the required packages in my application. I'm thinking this could be to do with a problem with Liferay IDE, but I"m going to try using plain old ANT build to see if all the required packages are created. Meanwhile, would like to know if you found a solution. Thanks!



What packages doesn't Service Builder create?
Nishikant sapkal
RE: Service Builder does not create the entity relationships
July 2, 2012 9:56 AM
Answer

Nishikant sapkal

Rank: Junior Member

Posts: 71

Join Date: February 15, 2010

Recent Posts

Please see here -

http://www.liferay.com/community/forums/-/message_boards/message/14639227
Jack Bakker
RE: Service Builder does not create the entity relationships
July 2, 2012 5:13 PM
Answer

Jack Bakker

Rank: Liferay Master

Posts: 559

Join Date: January 3, 2010

Recent Posts

first I would upgrade to v6.0.6 for various reasons, perhaps unrelated

then, after running service builder, u likely will find your persistence classes getting generated nicely where you might need to add methods to your *entity*Impl and to your *entity*LocalServiceUtil to add calls to methods in *entity*Persistence (or in the case of *entity*Impl to *entity*LocalServiceUtil methods)

easy enough, for example in your ContingentLocalServiceUtil, type contingentPersistence. and see the methods you've got, add the ones you need ; then rerun service builder

as perhaps an aside:

for installs where multiple portlets need to access common services, I've adopted a pattern to put all my services (read service.xml) in one portlet called *clientName*-service-portlet and then deploy it and then MOVE the tomcat*/webapps/*client*-services-portlet/WEB-INF/lib/*-service.jar to global classpath tomcat*/lib/ext ; but this requires a tomcat restart to pick up the new global .jar
David H Nebinger
RE: Service Builder does not create the entity relationships
July 2, 2012 5:17 PM
Answer

David H Nebinger

Rank: Liferay Legend

Posts: 6704

Join Date: September 1, 2006

Recent Posts

Jack Bakker:
for installs where multiple portlets need to access common services, I've adopted a pattern to put all my services (read service.xml) in one portlet called *clientName*-service-portlet and then deploy it and then MOVE the tomcat*/webapps/*client*-services-portlet/WEB-INF/lib/*-service.jar to global classpath tomcat*/lib/ext ; but this requires a tomcat restart to pick up the new global .jar


We use the same *clientName*-service-portlet pattern, except rather than moving the service jar to lib/ext and restarting tomcat, we use the liferay-plugin-package.properties file and the required deployment context of each consumer plugin to access the services. Saves the whole application container restart nonsense...
Jack Bakker
RE: Service Builder does not create the entity relationships
July 2, 2012 5:26 PM
Answer

Jack Bakker

Rank: Liferay Master

Posts: 559

Join Date: January 3, 2010

Recent Posts

liferay-plugin-package.properties approach does a copy of the jar that is referenced ?

I haven't fully evaluated performance to compare 1) move service jar to global or 2) do the liferay-plugin-package.properties approach

overhead of updates to each liferay-plugin-package.properties is tiny obligation though what can be said for having to redeploy each portlet every time there is a service change ?

I think we have discussed this before... sometime, in a place not that far away...
Hitoshi Ozawa
RE: Service Builder does not create the entity relationships
July 3, 2012 5:32 AM
Answer

Hitoshi Ozawa

Rank: Liferay Legend

Posts: 7990

Join Date: March 23, 2010

Recent Posts

I'm using the lib/ext because undeploying and deploying new portlet requires some time and portlet may error out if one portlet is updated and another is still not updated.
Thus, to have a stable system, it's still needed to stop the server.

If my liferay is in a cluster, I can take one server down and do an update without loosing integrity of the system.
David H Nebinger
RE: Service Builder does not create the entity relationships
July 3, 2012 8:31 AM
Answer

David H Nebinger

Rank: Liferay Legend

Posts: 6704

Join Date: September 1, 2006

Recent Posts

Jack Bakker:
liferay-plugin-package.properties approach does a copy of the jar that is referenced ?


Well, I think it's actually the IDE that does the copying, but yes the service jar ends up in the service consumer portlet's WEB-INF/lib directory. It's a nice feature of the build process (IMHO), but I do wish they would integrate the same thing into the ant build and/or hot deploy.

I haven't fully evaluated performance to compare 1) move service jar to global or 2) do the liferay-plugin-package.properties approach


Well, to put to global you must shut down the server. In fact, every update deployed requires a shutdown cuz you then have to manually move the service jar update to the global directory. Quite a pain in the butt to have to do this manual stuff, even if you're in a cluster.

The liferay-plugin-package.properties file approach does not require the restart, but it does have other peculiarities:

  • The IDE will copy the updated service jar to all open projects in the IDE when the service.xml is built. I normally use the IDE's "Build Service" button on the gui service.xml editor, and I think it is either that gui editor or the Liferay IDE's handling of the liferay-plugin-package.properties file that does the copying, and not the ant scripts, bug Greg would probably be the one to ask. Since this is not a deployment action, it's restricted to other plugin projects in the IDE, and you have to have the service providing plugin project open (even if you're not the primary developer on that project).
  • You must re-deploy the plugins that are consumers when a service jar update occurs in some cases. I say in some cases, because it primarily depends upon whether the signatures for the methods/entities the consumer uses change. If I have a plugin that uses an Employee entity and methods from the service jar, and I deploy this guy, but then I add a Manager entity and methods to the service jar but do not change anything w/ Employee, the plugin does not have to be redeployed (it will look up and use the Employee stuff from the older version of the service jar even though a newer implementation may have been deployed).
  • You can end up w/ multiple versions of the service jar floating around. This can happen as a result of the bullet above, in fact I've got a bunch of different versions floating around on the deployed system. So far I haven't seen any issues from this, but it is something that should be noted. It's easy to clean up, though, by refreshing/redeploying the dependent portlets after the service portlet was updated and deployed, but that's a lot of extra deployments that may not be necessary.
  • On the upside, Liferay will suspend the startup of a plugin that has a listed required deployment context on another plugin until that plugin is successfully loaded. Can save on some of the "BeanLocator is null" errors, but also means if the service provider fails to start up, all of the dependent plugins will not load (I guess this is a good thing, why have a portlet available that cannot use the service portlet it is dependent upon?).


So on one hand it solves the issues surrounding the global lib (shutting down the server, trying to access the XxxLocalServiceUtil objects before the service providing portlet has loaded), but it does come with some baggage of it's own.

For our part we've been using this method for months now without any issues. Personally I would prefer the copying of the service jar to occur as a hot deployment task, just as the other jars are copied in that are listed in liferay-plugin-package.properties, but I'd hate to have them hold GA2 for this emoticon
sheela mk
RE: Service Builder does not create the entity relationships
July 3, 2012 11:43 PM
Answer

sheela mk

Rank: Regular Member

Posts: 112

Join Date: February 16, 2012

Recent Posts

Hai...Natesh..As per your requirement ,,You can check..DTD of service.xml file..There you 'l get one to many and many to many relationship..as you want to build relationship between two tables...Like...

let me know..if you want any example coding..You can also refer to Liferay in action examples....there you will get one to many relationship..between two entity..

<column name="contingentList" type="Collection" entity="Contingent"
mapping-key="eventId"/>

This column..'ll create as method in your eventPersitence..You should pull out that method..to XLocalserviceImpl..
Jack Bakker
RE: Service Builder does not create the entity relationships
July 4, 2012 7:22 AM
Answer

Jack Bakker

Rank: Liferay Master

Posts: 559

Join Date: January 3, 2010

Recent Posts

classloading rules
David H Nebinger
RE: Service Builder does not create the entity relationships
July 4, 2012 12:40 PM
Answer

David H Nebinger

Rank: Liferay Legend

Posts: 6704

Join Date: September 1, 2006

Recent Posts

Jack Bakker:
classloading rules


Is that a question, or more of a statement: Classloading Rules!
Jack Bakker
RE: Service Builder does not create the entity relationships
July 5, 2012 6:16 AM
Answer

Jack Bakker

Rank: Liferay Master

Posts: 559

Join Date: January 3, 2010

Recent Posts

good idea, why didn't I think of it : "Classloading RULES!!!" on a T-Shirt to be worn at Liferay Symposium 2012 Oct 8-9 in San Francisco while sitting in the front row like a geek-keener listening in awe to Ray Auge talking (hopefully) about OSGi (holding up a lighter like at a RUSH concert ; and waiting for 'picks' to be thrown into the audience ; the real relation, the underlying dream...)

--

but I digress: back to topic:

for one client I have 20 or so portlets, some Vaadin, some MVCPortlet, one MVCPortlet project that has all the services for the client ; thinking of going to two but the concept of a 'build' morphs

in linux I have a bash alias where command mvserv*clientname* moves the service jar to the global class path

so for dev workflow related to change in services, I deploy the *clientname*-service-portlet, run mvserv*clientname* command, then restart tomcat ; not so bad all considered especially with SSD drives and a well tuned dev setenv.sh ; for to staging or production

does Liferay core distribute the services into various portlets ?

while thinking of dll heaven does one lives in dll hell ? no. we entertain different approaches ; I am thankful to have options while I zigzag towards the Grand Design.

Rock On Garth
(a few Canadian references above, enjoy)
David H Nebinger
RE: Service Builder does not create the entity relationships
July 5, 2012 8:22 AM
Answer

David H Nebinger

Rank: Liferay Legend

Posts: 6704

Join Date: September 1, 2006

Recent Posts

Jack Bakker:
does Liferay core distribute the services into various portlets ?


No, but then Liferay services are, of course, a horse of a different color. These services are intended to be used by all portlets, so putting the service jar in the global class path makes sense for them. They're also static in the sense that we, as Liferay users, do not actively develop them, they only (possibly) change from release to release.

We have a similar setup locally, many portlets (using different frameworks, but mostly Vaadin) using the required deployment context method I mentioned earlier. Deployments are a snap because the service providing portlet doesn't need it's service jar moved and service consuming portlets have the service jar already.

while thinking of dll heaven does one lives in dll hell ?


That's really the issue that I'm probably most concerned about with the path we're on. As I said, the service consumers (so far) do not have to be redeployed when the service provider's method signatures they use don't change. I think this is due to the magic of the CLP layer between the service jar and the actual implementation.

It's not so much like "DLL Hell" as each portlet has the service jar it was coded to work against and there aren't issues w/ the different versions and the web app class loader, but it is a little worrysome...