Hello everyone,

Does anybody know how to generate an empty service by service builder which calls our custom xxFinders? Thanks in advance for your helps here!

Just create an entity without any columns.

I'm just wondering what would be the benefit of creating an empty service with service builder instead of just calling the service directly?

Because you expose a service to other portlets w/o having to copy code around?

Without any column definition, it seems there won't be any useful generated interfaces because there won't be any defined parameters to the interfaces.

sure, but you could get into the FooLocalServiceImpl file and add your own finder methods. As long as you're passing around serializables and interfaces, I would think you could leverage the basic SB framework to expose some shared methods for other portlets w/o having to contend w/ the webapp class loader boundaries...

Don't know, just brainstorming here. I too am curious what the OP had in mind.

creating an empty XXX service works fine ; and useful including when service calls custom-sql

but what about also generating empty XXXImpl for the entity ? where XXX interface can be referenced ?

in http://docs.liferay.com/portal/6.0/definitions/liferay-service-builder_6_0_0.dtd.org.html I see:



but In 6.1.1 I am generating with below and am getting no POJO ; can't have MOJO with no POJO

<entity name="myEntity" data-source="myDataSource" local-service="true" remote-service="true" session-factory="mySessionFactory" tx-manager="myTransactionManager">


</entity>

You won't get a pojo w/o columns, but adding columns means that you're then tying to a database entity...

There's an idea here http://www.liferay.com/community/forums/-/message_boards/message/12095602 which would give you a pojo to pass around and not necessarily bind it to a database as long as you are careful in how you use the XxxLocalServiceUtil methods...

good workaround as I chase the rabbit

instead of workaround reference no_data_source better this is a new service builder option to create multi-portlet service-available stuff not necessarily directly tied to any real backend persistence or for non-ORM custom-sql

Yeah, I wish there was a "non-db" attribute of some kind for the entities. That way SB could be an actual "service builder" rather than just a "data service builder".

Think along the lines of having a SB entity which is actually the result of some web service call or flat file read or something. When you have shared services of this nature, using a non-db entity would allow you to have a single implementation instance shared to all of your plugins.

The 'fake' DB method (either by using an in-memory database or lazy db pointer to the liferay data source) can at least let you build these kinds of things w/o actually having the entities created in the database, and you get all of the shared service stuff (including CLPs and XxxLocalServiceUtils)...

It's a SOA design principle. The owner of the entity is the one who governs the services. If a facade service can be build by somebody else and the entity definition is changed by the owner, the service may not work properly. A workable option is to support multiple version of the interface so the old version of the interface can still be used, but the current Service Builder doesn't support multiple interface versioning.

what I'm working on is a *.persistence.XXXFinderImpl which uses custom-sql to return a List<XXX>

XXX doesn't map to a database table ; why should it have to ?

useful for reporting and other use cases

I wonder on uses of this for backend LDAP, nosql, file ; and where the XXXLocalService might consume another remote service (SOAP or whatever) for say payment gateways, shipping and so on ; be useful for a shopping cart involving multiple portlets where IPC overhead can be reduced

in the past I've been using just a library deployed to global classpath ; but then there is the container restart overhead and also doesn't do much for remote services

I get the SOA design principles, and I'm not arguing about versioning or anything like that...

I'd like to be able to define entities that are not backed by a database table yet fit nicely into the SB pattern. I could put these entities into a service.xml file, build the services (local, remote, or both), and then consume the services/entities in other Liferay plugins the same way that DB entities are...

Right now you can define an empty entity, but methods that you add to the XxxLocalServiceImpl class are limited to returning primitives (or their Object counterparts), collections of primitives (or object counterparts), or a SB-defined entity (either from your service.xml file or one of the Liferay entities). You cannot define your own interface/implementation and pass that back because the CLP stuff generated by SB doesn't know anything about your own classes.

However, if you could define a non-DB entity, you could specify the entity in service.xml, add whatever methods you want in XxxLocalServiceImpl and build services to share this with other plugins because SB will generate the correct CLP stuff for you.

Using an in-memory or lazy database is a hack solution which allows you to do this, but certainly if SB supported it natively this hack wouldn't be necessary (although there would need to be a bunch of new templates/classes added at the SB foundations to support it).

SOA is definitely the way to go, but right now SB is limited to database services. What I'm talking about is opening SB up to non-database services too.

Exactly. I have faced similar things where I don't necessarily want to expose my table layouts to service users, I'd rather define a non-db entity in service.xml and let my methods, implemented in XxxLocalServiceImpl, take care of the construction and persistence of XXXs.

Same idea applies to all of the examples Jack has provided.

We want to have all of the functionality that SB gives us for DB entities (shared service jar, separate implementation code, CLP handling, spring wiring, required deployment context management, all of the code generation/synchronization stuff that SB does for us, etc.) but not actually have them based upon a DB table...

Right now the only way to do that is to fake an actual DB connection to define a DB entity that will never really exist...

note that for custom-sql using a XXXFinderImpl, you can just leave out the entity's 'table' attribute as below ; however the primary key column is required, which means the custom-sql has to return some number (for example in postgresql: "select row_number() over() as xxx_id, tableA.fld1, tableB.fld2 from tableA, tableB")

<entity name="XXX" data-source="myDataSource" local-service="true" remote-service="false" session-factory="mySessionFactory" tx-manager="myTransactionManager">
<column name="xxx_id" type="int" primary="true"/>
<column name="fld1" type="String" />
<column name="fld2" type="Date" />

</entity>