use of the namespace tag in servicebuilder in liferay 6.1

[Kiran Kumar Boyini, modifié il y a 11 années.]

Hi All,

In liferay service builder, we have <namespace> tag to generate the table in given namespace .But I have following doubts .

1) What happen If I have not used <namespace> tag in service builder and is this tag is mandatory for every service file.

2) can I able to use same name for two different service builders which are in different portlets.

please clarify my doubts.

Kiran.

[Rajeeva Lochana .B.R, modifié il y a 11 années.]

HI Kiran,


1) What happen If I have not used <namespace> tag in service builder and is this tag is mandatory for every service file.

To differentiate liferay core table and custom table we are using "namespace" in service.
For more information about this check the blow link.

http://www.liferay.com/community/forums/-/message_boards/view_message/5991570#_19_message_5991502


2) can I able to use same name for two different service builders which are in different portlets.

Yes, we can use same namespace for different service. On one condition:
Two service must have different entity/table name.

If we have same table name in both service, then it will break all the hibernate caching logic.

Thanks,
Rajeeva Lochana.B.R

[Kiran Kumar Boyini, modifié il y a 11 années.]

Hi Rajeeva Lochana,

As you explained second answer, I have given same name space for two different entities in two service builders.But I am getting the following
Exception .

com.liferay.portal.OldServiceComponentException: Build namespace vam has build number 2 which is newer than 1

I resolved the above problem by giving the different name space for two different entities in two service builders.

Regards,

kiran.

[MANOVINAYAK AYYAPPAN, modifié il y a 11 années.]

Hi Kiran,

The Build Number is tied to the buildNamespace.

So if you have the same namespace shared by two service builders then, you must maintain the same build numbers in both the service builders.

Check the following table in DB where the build numbers are maintained:
select * from servicecomponent;

To keep it short, update the service.properties of both service builder files (which are sharing the same namespace) with the most recent build number evry time before you build service.


I would not suggest such namespace sharing between service builders in different portlets. Every Portlet should have a unique namespace.
Sharing of services should be possible by placing the JAR files in the global classpath.

Regards,
Mano

[David H Nebinger, modifié il y a 11 années.]

Well, wrong wrong wrong...

Service builder will automatically update the service.properties and change the build number automatically. Suggesting that someone manually try to keep these in sync is just foolhardy.

Secondly, you should never suggest someone go to the tables directly. The tables belong to Liferay, they can change at any time, and they should just be ignored. I've been doing Liferay development for years, and never have I needed to go to the tables directly to find anything. If you can't do something in the existing Liferay API, you're doing something wrong.

And to repeat, no, you never update service.properties directly. This file is controlled and managed by service builder. If you need to do something, you do it in service-ext.properties.

The only right thing you've said is the use of different namespaces for different service.xml files. Namespaces are used by Liferay to ensure that there is no classpath collisions when a plugin is using services from two separate plugins. Each namespace must be unique or you'll end up w/ classpath issues and other failures.

[MANOVINAYAK AYYAPPAN, modifié il y a 11 années.]

My post was misunderstood.

ABOUT INCREMENTING BUILD NUMBER MANUALLY:
Updating service.properties with the buildnumber, I was suggesting a way to avoid the error (which is NOT a good practice, so that is reason I suggested not to share same namespace between service builders in two separate portlets)
com.liferay.portal.OldServiceComponentException: Build namespace has build number 2 which is newer than 1

Most of the time I get the build number exception as stated above (com.liferay.portal.OldServiceComponentException) when I deploy (when the service.properties file was not checked into SVN by my teammate) In such cases I have always manually incremented the Service builder's build number.

Say my teammate and I work on the same namespace: start off with same build number and my teammate builds service 20 times, while I build it 10 times.
My teammate deploys first to the Test Environment, then I deploy next, I will definitely get the error as stated above because my build number will be less than the one that was previously deployed.

I cannot run the service builder 11 more times to reach the build number that my teammate has, which is time consuming and foolish. So in this case I will increment the build number directly 20 and run the service builder once and then deploy

And thanks for sharing about service-ext.properties, which I di not know. I will use it henceforth.

ABOUT THE TABLE:
I suggested to query the table serviceComponent to understand as of how the service builder maintains the namespace and build number. There is no harm querying liferay's table and relating to how the Portal Works.

No offence meant here.

[David H Nebinger, modifié il y a 11 années.]

MANOVINAYAK AYYAPPAN:

I cannot run the service builder 11 more times to reach the build number that my teammate has, which is time consuming and foolish. So in this case I will increment the build number directly 20 and run the service builder once and then deploy

And thanks for sharing about service-ext.properties, which I di not know. I will use it henceforth.

Note that you can use service-ext.properties to define a value for the build number. This will override the value that SB increments each time, and will totally prevent the error from coming up.

That being said, you should only use this under the following situations:

1. You are not changing the class method signatures.
2. You are not adding new entities that you will later be dependent upon.

This is a really narrow use case, and it basically only applies if you do all of your SB design work up front, generate all of the entities, etc. but later on want to be able to change the Xxx(Local)ServiceImpl implementations (not a method signature change, just a method body change).

Basically the build number is used to ensure that the version of the service jar is compatible with the service implementation, but not necessarily the same. If all you are doing, from the first deployment, is perhaps adding new methods or modifying existing method bodies, your service jar may actually be compatible with the service implementation w/o requiring across the board deployment.

But even for this narrow use case, you cannot just throw it out there as something everyone should just do, because you must be absolutely clear about what the impact this makes on your service project currently and in the future.

[MANOVINAYAK AYYAPPAN, modifié il y a 11 années.]

Thanks a lot David !!!

I learnt something new (service-ext.properties) today!!!