Fóruns

Início » Liferay Portal » English » 6. Portal Framework

Visualização combinada Visão plana Exibição em árvore
Tópicos [ Anterior | Próximo ]
toggle
Trevor Ackerman
Service Builder without Persistence (How to use ClassLoaderProxy?)
3 de Dezembro de 2012 14:28
Resposta

Trevor Ackerman

Ranking: New Member

Mensagens: 9

Data de entrada: 17 de Novembro de 2011

Mensagens recentes

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
David H Nebinger
RE: Service Builder without Persistence (How to use ClassLoaderProxy?)
4 de Dezembro de 2012 05:35
Resposta

David H Nebinger

Ranking: Liferay Legend

Mensagens: 7238

Data de entrada: 1 de Setembro de 2006

Mensagens recentes

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.