What are the consequences to develop portlet without service builder ?

[chris chris chris, modificado hace 16 años.]

Hi all,


I wonder, what are the consequences if I develop portlet without using service builder and service.xml ?

Because I think service.xml is lack of documentation and functionality, so it took 80% of my time just to finish 20% of the work.
I think it's better to create my own hibernate mapping, persistence and service layer than have to browse
all the forum and wiki regarding how to use service.xml. Right now I don't use any web service, so I don't need
code generation for web service classes from service builder.

Thanks in advance

[Artur Linhart, modificado hace 16 años.]

Hello,

I took place on some trainings for it abd from my point of view, there are some advantages for it - especially if You want to use the portal as the framework for the development of Your own application and You want to make it platform-independent, then the EXT-Environment with the service building does a good job, I guess. It is also good in the other cases You want to modify the functionality of the portal itself.

But - from my point of view - I do not think, this would be really helpfull. I prefer to develop just portlets independent on liferay EXT environment, because I can deploy them on multiple liferay instances for more customers also in the case I cannot make the modifications of the portal itself. From my point of view this is the obvious situation. And if You cannot modify the portal itself, You cannot use this style of development.

I am also afraid about the future upgrades of the portal, modified by implementing such service-developed portlets - if You have independent portlets, You can be pretty sure there will be no big problems (and effort) to migrate to the next version of portal.

But if You want to develop with the help of the EXT environment, then it is good to do it in the way like liferay proposed, because You still are modifying the portal or its external parts.

I think, the documentation can be found somwhere - orientate Yourself to the keyword "EXT Environment" - for example on this page http://wiki.liferay.com/index.php/Development_in_the_ext_environment and its linked documents You can find the main starting information... Or You can take place in the training - the development in EXT environment is (or at least in my case was) the core of the official liferay training (even if it was mentioned only as one topic from more, it took 60% of the training time).

with regards, Archie

[Ed Shin, modificado hace 16 años.]

Artur provides some great points, but I wanted to note that Service Builder works in the plugins environment, and you don't have to worry about it not working after upgrading because the generated code is localized to the portlet.

ServiceBuilder generates all the hibernate and spring code so you get transaction management for free. Once you learn how to use it, you'll see that it makes development a lot faster. For the times where you need to create a custom query, you can override the default PersistenceImpl class and implement your own database call. There's a lot of other useful features like automatically generated ajax json calls for methods in the *ServiceImpl.

Of course, there is something appealing about having full control over everything that's going on in your portlet, so that's not a bad idea too.

For a practical example of how to use Service Builder in a plugins environment, go here:
http://www.liferay.com/web/eshin/1

[Artur Linhart, modificado hace 16 años.]

Hi, Ed,

You make me hoping again... :-) In the trainings to the development in the EXT environment we got the answer it would be a very heavy task to extract just the generated portlet code with all the necessary libraries etc and to put it in a separate war-file - at least it was the state in the version 4.2.x

So You say it is possible to develop such a portlets and make them independent from the current lifeay version? The ext-environmend always made the modifications (extensions) of the portlets included directly in the portal itself, with no specific portlet war file creation. So there exists now such a possibility? Or do I understand You wrong?

with regards, Archie

[Ed Shin, modificado hace 16 años.]

Hi Artur,

Yes, Service Builder has now been extracted from the EXT environment. It did take a lot of work to make it work for plugins, and I think this was completed some time in 4.3.x. I've tested Service Builder in 4.4.0 and 4.4.1, and it definitely works with plugins (portlet .war files).

If you follow the example in my tutorial, you'll have a pretty good idea of how it works. The only caveat is that you shouldn't use "References". So instead of counterLocalService.* use CounterLocalServiceUtil.*, etc. Using counterLocalService.* works fine when you use the PortalClassLoader, but does not work when you don't use it.

I didn't see any dependencies that would make it difficult to upgrade if you use Service Builder in your plugins. I encourage you to take a look though, and I think you'll see that everything is fairly well isolated from the portal.

Another cool thing that is that the table gets automatically added to your database when you deploy your portlet. I didn't think something like this was possible, but it's definitely a very nice feature. I've tested on MySQL, and I'm pretty sure it works with all databases. (Note: If you specify a custom table name, then you'll need to add the table manually. Most people don't usually specify a custom table name, so you probably won't need to worry about this.)

Ed-

[Artur Linhart, modificado hace 16 años.]

This sounds very good ;-)

I have to find some time to get again into it.

According to the automatic creation of the tables - is there somehow assured that if I name the entities with the same name in more independent portlets, they will be then not is some conflict?

Is there possible to point the portlet to be stored in the different database - so some individual hibernate configuration for such a plugin portlet?

with regards, Archie

[Ed Shin, modificado hace 16 años.]

If you had the same exact name for a table, then the portal would throw an exception and not import the table. Adding columns would also not get auto-imported.

Yes, it's possible to use another database by overriding data-source.xml. You can check out wiki.liferay.com to see how to do it in the EXT environment, but the same should work in the plugin environment as well.

[Ratnadeep Rakshit, modificado hace 16 años.]

Hello Ed,

I have a special situation where I need to modify some of the existing portlet in the liferay core and also develop many new potlets. As I have been reading, the ways of doing it would be building the changes in the EXT environment and use the Plugin SDK for developing the new portlets. But, is it not possible that I can override the classes or jsp's from outside the EXT environment? Also, is there a better way of building portlets without using the standard SDK because as per our company standards, every code that we write must be under a the following directory structure -

project-dir > portlet > src > package name > code

But as per the instructions of the SDK, we need to build our code inside the portlet directory if we need to manage the complete lifecycle of the portlet (from creation to deployment). Did anyone try using or modifying the build.xml so that we can use our directory structure and still make use the SDK infrastructure???

And help would be appreciated.

Regards

Rakshit

[Ed Shin, modificado hace 16 años.]

Hi Ratnadeep,

I think this is not so related to the original thread. Can you post your question in a new thread?

Using the EXT environment to change core portlets and the Plugins SDK for new portlets is a good strategy.

You have 2 possible options with the directory structure. Create a customized build script that deploys your changes directly to the server or you can deploy your changes to the EXT environment and then call Liferay's build scripts to deploy it to the server.

Having a pre-defined structure will hinder your progress. Ideally, you would just use the EXT environment. If you have to follow that specific directory structure, then I guess you have no choice. But I think the decision maker is probably not aware of the cost in terms of development time and effort that this might take.

If all you need to do is modify JSPs and you want to keep the directory structure that you mentioned, I'd just create a build script that overwrites the JSPs in the server.

[Anantya Wibowo, modificado hace 11 años.]

hi all...

i've managed developing portlet using spring3-hibernate3-maven. there are no consequences. i can call liferay's local service impl if want to integrate with adding user, adding document/image gallery.

[David H Nebinger, modificado hace 11 años.]

Well this is a really old thread, but I have to disagree w/ the assessment of 'no consequences'...

Service builder's greatest strength is the ability to handle crossing the web app classpath boundary for all data access.

Skipping SB is fine if all of your data access is limited to just the portlet that uses the native hibernate layer.

Say, for example, you are working w/ a table of COURSES that has another table of STUDENTS and a third table of TEACHERS. A course will have one teacher but multiple students.

So you create a portlet to show the student list for a selected course and you manually generate the hibernate stuff for the entities. You can build it, test it, deploy it, and it all works just great.

Now someone wants a list of courses and the teachers that teach them. Now you're stuck. You can either:

• Create the new portlet in the same war file as the student list portlet (so you don't have to copy all of the hibernate/spring stuff to another portlet).
• Create a new portlet for the course list and manually copy over all of the hibernate/spring stuff from the student list portlet.

Either case you're in a bad situation.

In the first case you might think "Sure, 2nd portlet, no problem" but as your whole student/teacher/course registration system grows (you add a BOOKS table so you can track what books are used in the course, a GRADES table to capture student grades in the course, etc.) all of a sudden you're looking at a single portlet project hosting many individual portlets, all because you don't want to replicate the hibernate stuff around.

In the second case you're in maintenence hell. As the new tables are added you have to go back to all of the portlets where you've replicated this stuff around. Hopefully you won't miss one of them, hopefully you get all of your fixes replicated correctly, ...

Now let's say you've used Service Builder from the start. The student list portlet has the service.xml file w/ all of the entities defined. You can build it, test it, deploy it, and it all works just great.

Now when the course/teacher list thing comes up, you can create a separate project that uses the service jar from the student list portlet. It has full access to the service as if it were in the student list portlet, but it's a separate deployable artifact that doesn't have to worry about the web app classloader boundary and doesn't have copies of the code floating around.

As your system gets extended with the new BOOKS and GRADES tables and entities, your one service.xml gets updated, your one student list portlet gets updated, and you can happily build separate yet connected portlets that can leverage those new entities.

Liferay's system of using Service Builder for all data access just works. It allows you to access the user service, the document and image gallery, etc. If they had done straight spring/hibernate implementations for their data access needs, you wouldn't be able to have separate deployable portlet projects, everything would have to be directly connected to the core Liferay system and it would just be a mess.

So given that Liferay's system just works but the path you're on has obvious problems, how can you say there are no consequences?

[Hitoshi Ozawa, modificado hace 11 años.]

David, I think the original poster is talking about using his own entity framework for ALL of his projects. I think there's nothing wrong with that. I'm not using Liferay's UI framework on all of my projects. I'm just using functionalities that would lessen my work. If it's going to take me more work to use Liferay (because of lack of documentation or quality), it's better to just use your own.

[David H Nebinger, modificado hace 11 años.]

I'm not saying it's not possible, but it is a definite design decision that deserves a full response other than "I've done it and there are no consequences". Especially since there are consequences. If you are aware of the consequences, you can make the educated decision whether to leverage Service Builder or not.

Anyone new to Liferay and searching for whether to use Service Builder or not could stumble onto this thread and believe they can just roll their own service layer (using whatever framework they want) and there will be no consequences.

I was highlighting the consequences you'll face by choosing to use your own service layer.

I never said it wasn't possible, I was just highlighting the problems you're going to have if you choose to do so.

[Hitoshi Ozawa, modificado hace 11 años.]

I understand. I just wanted to point out the community is now reaching a point where it doesn't have to rely 100% on liferay.com to do something. If there's a problem in feature, quality, release schedule, etc., it's no longer necessary to just sit sucking one's thumb waiting for liferay.com to do something. As was stated, there isn't too much documentation on using service builder and there are some basic features lacking from it. I'm beginning to feel it would be better to have a community led project to make liferay platform better.

I've looked at aperte and I think they're have much better reporting plugin than what liferay.com has and is offering. I don't think there's nothing wrong with using non-liferay.com's parts. Just my 2 cents worth of opinion. :-)