Foros de discusión

Service Builder without Persistence (How to use ClassLoaderProxy?)

thumbnail
Trevor Ackerman, modificado hace 11 años.

Service Builder without Persistence (How to use ClassLoaderProxy?)

New Member Mensajes: 9 Fecha de incorporación: 17/11/11 Mensajes recientes
ServiceBuilder uses that ClassLoaderProxy to make the implementation layer of any service you build available to any other portlet deployed within your running Liferay instance.

For lack of a better term, this reminds me of how in Unix you may build a shared library and deploy it to a server so that any applications that needs its implementation may just use them without having to link to the library during compile time.

Can someone tell me either or both of:

1. How can you use Service Builder to create a service and leave out all the persistence layer (I have no interest in storing any model objects to a database)

2. How can I create a library that has a jar for an interface and a separate jar/war for the implementation and be able to serve up the implementation via ClassLoaderProxy?

Cheers,
Trevor
thumbnail
David H Nebinger, modificado hace 11 años.

RE: Service Builder without Persistence (How to use ClassLoaderProxy?)

Liferay Legend Mensajes: 14916 Fecha de incorporación: 2/09/06 Mensajes recientes
There's a suggestion here that outlines what you could do: http://www.liferay.com/community/forums/-/message_boards/message/12095602

SB will generate the persistence layer for any entity in service.xml, and you must define an entity in order to get the shim layer.

If you define an external data source and use a memory-only database (i.e. hsql) and use that for your entities, you'll get a persistence layer generated by SB, but you can safely ignore it. Since it is memory-only, the 'table' for the entity won't get generated unless you hit the persistence layer from the service layer, but even if you do it won't hit your real database.

Using this methodology, you can get to the type of "service layer" that service builder should represent, rather than just a "database DAO service layer" that it currently is.