Hi,

Iam using Liferay 6.0.3. I have the following entries in my service.xml


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

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!

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.

What packages doesn't Service Builder create?

Please see here -

http://www.liferay.com/community/forums/-/message_boards/message/14639227

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

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...

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...

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.

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.



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

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..

classloading rules

Is that a question, or more of a statement: Classloading Rules!

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)

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.



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...