RE: Custom portlet is not shown in 7.1.2 GA3 if @Reference is used

Jan Tošovský, modified 6 Years ago. Liferay Master Posts: 576 Join Date: 7/22/10 Recent Posts
Dear All,

I've created a simple Service Builder portlet which works as expected unless I add @Reference annotation to inject my service.

When this portlet is deployed, all dependencies are resolved, there are no error messages in the log, the module status is Active, but it isn't shown in the widget menu.

When the @Reference annotation is removed and portlet rebuilt/redeployed, the portlet is shown properly.

I've restarted the server, but still no luck.

I can't see even Blade's Service Builder Basic portlet.

Weren't there any breaking changes?

It worked in 7.1.1 GA1 (JDK 8 + tomcat 9)

Jan
Jan Tošovský, modified 6 Years ago. Liferay Master Posts: 576 Join Date: 7/22/10 Recent Posts
Wow, I finally fixed this.

TLDR: There were some server startup issues, but related to another portlet. Once I resolved them, all my portlets are shown again properly.

Broader context

I am migrating to 7.1 from 6.2 and converting old-style MVC portlets to module ones. If these are service builder based, the buid number counter starts from scratch. If the build number doesn't match the one stored in database when portlet is deployed, the upgrading process is started. In LR 7.x tables are not upgraded by default, it is expected a dedicated upgrading procedure is provided by the portlet itself. When it is missing, your migrating process most likely fails with the error 'The table my_table already exists'. You can ignore this by modifying SQL commands in tables.sql file ('create table if not exists' instead of 'create table'), but as your build number is lower, it fails anyway:
Unable to initialize service component
com.liferay.portal.kernel.exception.OldServiceComponentException: Build namespace MyNS has build number XX which is newer than YY
In my case I deleted my namespace from servicecomponent table directly so my build number is initial and no upgrating process is invoked:
delete from servicecomponent where buildnamespace='MyNS';
I could also increase the build number manually so both versions match.

When the server was restarted, all services were initialized properly so these service dependent portlets could be resolved properly.

The strange thing is why all modules even services were active in GoGo shell and no errors were signaled.