Vista combinada Visión Plana Vista de árbol
Discusiones [ Anterior | Siguiente ]
Trevor Ackerman
Service Builder without Persistence (How to use ClassLoaderProxy?)
3 de diciembre de 2012 14:28

Trevor Ackerman

Ranking: New Member

Mensajes: 9

Fecha de incorporación: 17 de noviembre de 2011

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?

David H Nebinger
RE: Service Builder without Persistence (How to use ClassLoaderProxy?)
4 de diciembre de 2012 5:35

David H Nebinger

Community Moderator

Ranking: Liferay Legend

Mensajes: 12082

Fecha de incorporación: 1 de septiembre de 2006

Mensajes recientes

There's a suggestion here that outlines what you could do:

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.