Forums

Home » Liferay Portal » English » 3. Development

Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
venka reddy
Build number exception
August 10, 2013 1:31 PM
Answer

venka reddy

Rank: Regular Member

Posts: 231

Join Date: March 23, 2011

Recent Posts

I am developing the custom plugin portlet

Unexceptionally i got this error
Build namespace Test has build number X which is newer than Y.



I gone through the forums post it says , remove the our table row in service component table and drop your table in DB. I don't want to remove table .Is any preferred solution this?
David H Nebinger
RE: Build number exception
August 10, 2013 2:01 PM
Answer

David H Nebinger

Community Moderator

Rank: Liferay Legend

Posts: 11770

Join Date: September 1, 2006

Recent Posts

That's not what it means at all.

When you build services, there's an associated build number that goes along with it. The service jar will verify that it is the same or newer than the deployed instance.

This whole process is meant to ensure that you don't get a portlet that has a newer service jar (and therefore newer methods, entities, whatever) than what is deployed.

Deploy your updated plugin that has the latest service layer, then deploy your portlet again and you'll be fine.

Those other suggestions you read about were hacks that don't really fix the problem just get you around the problem. Underneath, you still have a service jar with a different version than the deployed service plugin, so there is always a potential of some deeper exception by not keeping in sync (i.e. missing methods, different method signatures, class not founds, etc.).
subhash lamba
RE: Build number exception
August 10, 2013 9:07 PM
Answer

subhash lamba

Rank: Regular Member

Posts: 136

Join Date: July 7, 2013

Recent Posts

I also have a same problem. i think that accure because of who portlet have same namespace.
To solve this problem change in service.property file or manualy change in servicecomponent table in database.
in service property

build.namespace=toocool_payment
build.number=232
build.date=1376104775323
build.auto.upgrade=true

there is build.number you need to change into it.
also remove if same namespace in two diffrent portlet.
I hop this will help you
Anil KC
RE: Build number exception
August 12, 2013 8:57 AM
Answer

Anil KC

Rank: Junior Member

Posts: 35

Join Date: December 20, 2012

Recent Posts

venka reddy:
I am developing the custom plugin portlet

Unexceptionally i got this error
Build namespace Test has build number X which is newer than Y.



I gone through the forums post it says , remove the our table row in service component table and drop your table in DB. I don't want to remove table .Is any preferred solution this?


Create a file called service-ext.properties and specify the new build number there. The build number from now onwards will remain constant as specified in the service-ext.properties. The ext build number should be greater than service.properties build number. Also, add build.auto.upgrade=false in newly created file.
David H Nebinger
RE: Build number exception
August 12, 2013 11:29 AM
Answer

David H Nebinger

Community Moderator

Rank: Liferay Legend

Posts: 11770

Join Date: September 1, 2006

Recent Posts

Anil KC:
Create a file called service-ext.properties and specify the new build number there. The build number from now onwards will remain constant as specified in the service-ext.properties. The ext build number should be greater than service.properties build number. Also, add build.auto.upgrade=false in newly created file.


Note: This will solve the exception, but does not address the underlying issue...

It's all about how to identify changes in the service tier.

If you create a new method in XxxLocalServiceImpl, say "findByXxx(final String xxx)" and build services, that method is going to be in XxxLocalServiceUtil. And you're free to write code that happily calls XxxLocalServiceUtil.findByXxx("my xxx") all day and get expected results.

Now let's say requirements change, and findByXxx(String xxx) no longer makes any business sense - say it now has to be findByXxx(final String xxx, final int xxxType) and no reasonable default can be assumed.

Now you make the change, build services and deploy, but you don't deploy any of the other plugins that have the service jar.

This is the source of the issue; plugins still want to use findByXxx(String), but that method no longer exists.

The build version number is supposed to identify those situations rather than leave you w/ unknown exceptions (ClassNotFound, NoSuchMethod, etc.).