I'm going to try to help answer these questions in piecemeal as I have time. Hopefully others will also chime in.



Liferay's persistence layer is built to leverage Hibernate. Hiberate is not a database. In fact, one of the primary benefits (amongst others) of Hibernate is that an application can be database agnostic. You do not want to use Hypersonic unless you're planning on just using it for demo purposes. As such, Liferay supports the same databases that Hibernate supports. See here for the full list.

Hi Ken,

At the risk of sounding "salesy", you may want to consider attending one of our developer courses. They'll walk you through how Service Builder works, but more importantly, teach you how to do things the right way when developing in Liferay. And yes, you can definitely do things the wrong way and make your life harder down the road.

http://www.liferay.com/services/training

Talking about music is like dancing about architecture.

That said, my library of books on Liferay is now getting extensive and I really like Liferay in Action. The forums (wikis/blogs) here are also very useful (an understatement).

In the grander scheme of things, service builder is such a time saver. To get to know it, it is worth reading a bit (books/online), staring at the DTD, using the Liferay IDE/Studio to speed dev up ; and learning to add methods to the service-builder generated *model.impl source and also to your service-builder generated *service.impl source.

Many thanks to everyone for the answers here, which clarify a lot of things. A couple of small responses to clarify my original questions:

(1) Actually, I've been developing complex software systems for a long time. Among the many languages and packages I've used I just hadn't come across Hibernate, and when I asked a colleague about it I got the wrong answer.

(3) A common pattern for many applications is open, process, close. It is therefore usual to have to initialise something (say, open a database connection), use it (say, issue SQL queries), and finalise it (say, close a database connection). I couldn't tell whether the Service Builder approach required this, e.g. whether there was some "init" method to be called or implemented.

I should now be able to make progress on this. Thanks

Very informative thread. Thanks to everyone contributed.

Yes, I would like to know how the transaction in general is carried out. I know the persistence classes will take care of that using Hibernate, but not a hibernate pro. I would like to understand (a quick brief) how it is making connection to database in an agnostic way.

And in particular worst case), say your database is down, how we can track that project a message to customer about that.

Thanks
Smile

Obviously new to development, too, if you don't know Hibernate. Hibernate is an object relational mapping tool which you use so you don't have to do all of the JDBC result set processing on your own.

Hibernate is (for the most part) database agnostic and layers on top of both Hypersonic and Mysql.



Yes. For local, you'd use the XxxLocalServiceUtil class to access your service builder entities and methods.



Not sure what you're asking for here.



The DTD is the best documentation for the various XML entities. If you use the Liferay IDE, it has a nice visual editor which can make creating service.xml files a little less verbose.

An entity represents a row of a table. Namespace is used when creating new tables to prefix the table name in the entity object (so you can use a prefix of "MYCOMP" and then use "USER_" as a table name knowing that you will not face collisions with Liferay's "USER_" table.

Finders are a convenience to hide the details of the actual finder implementation rather than having to hand-code all of the various sorts of finders you need.

Company id and group id are used when you need to support Liferay's multi-hosting/multi-group capabilities. For example, if a logical record may have different values for different hosts, the company id will make it a unique row. Same sort of concept with the group; if a record should have one value for group A but a different value for group B, the groupId element will give you a unique row. These have nothing to do with 'non-instanceable applications'.



The concept that you're not getting is that the generated code is meant to handle crossing the class loader boundary that exists between deployed applications in an application container. Normally an instance of a class cannot be passed to another web application in the same container; class loader issues prevent that. The bulk of the code generated by Service Builder gets around all of these issues so you can effectively share entities across the class loader boundaries.

As far as which classes you should use, it is all down to the XxxLocalServiceUtil classes. Only use that class and the interfaces that it exposes.

When developing your own code, refer to the generated comments in the code that tell you where your changes should be made.



This is the service jar for the service you created. It contains the XxxLocalServiceUtil classes and relevant interfaces that other plugins need to access your service. It can only be ignored by plugins that have no need of your service. If your plugin needs the service, it needs the service jar.



Extension is usually used when you need to change functionality in the existing Liferay service builder entities. By extending their classes you can override their methods with your own. In addition, you end up w/ a change to Liferay's spring configuration to use your extended instance rather than your own.

When you are dealing with your own service entities, extension is not needed and should not be used.