Deploy of module service fails after upgrade to 7.1 ga2

RE: Deploy of module service fails after upgrade to 7.1 ga2

2018-11-25T21:06:12Z

Hi Erik,

I am glad to hear that :-)

Thank you for this valuable feedback.

Best regards.

RE: Deploy of module service fails after upgrade to 7.1 ga2

2018-11-23T19:52:43Z

Hi Alberto,

Thanks a lot, this was very helpful.

I added the activator class and then a record was inserted into Release_ table with schema-version 0.0.1 when I deployed the service module. However the service classes were not available.

I then added the upgrade class using DummyUpgradeStep for upgrade "0.0.1" to "1.0.0", and updated schema-version to 1.0.0 in bnd.bnd, but the record in Release_ was not updated to 1.0.0 when deployed, and still the service classes were unavailable. So I stopped the portal and deleted the record in the Release_ table manually, and started the portal again.

During startup it added a new record in Release_ table and this time with schema-version 1.0.0, and all service classes were available.

It all works well now, so thanks for your help, very appreciated.

Best regards,

Erik

RE: Deploy of module service fails after upgrade to 7.1 ga2

2018-11-23T08:40:19Z

Hi Erik,

If there is no record in the Release table you need to intialize so that the portal knows that you are upgrading your module and it's not an installation from the scratch it if you want to still uses your tables. For that you can follow these steps:

https://dev.liferay.com/develop/tutorials/-/knowledge_base/7-1/upgrade-processes-for-former-service-builder-plugins

Maybe you will also need to create an upgrade process from 0.0.1 to 1.0.0 (you can use DummyUpgradeStep.java) if there is no need to change data or set 0.0.1 in your bnd.bnd as required schema version.

I don't why the record was created in 7.1GA1 because the logic is the same than now. Maybe the tables for your module didn't exist or any other issue occured.

Let me know about the results.

Best regards.

RE: Deploy of module service fails after upgrade to 7.1 ga2

2018-11-22T18:54:24Z

Yes, that record it is missing in release_ table, it is an upgrade from LR 6.2.

I can see the record in the database I used in LR 7.1 GA1 for upgrade from 6.2, so that record is created automatically I guess.

In bnd.bnd it says :

Liferay-Require-SchemaVersion: 1.0.0

But how is the record inserted inserted in release_ the first time without dropping the tables before first deploy?

RE: Deploy of module service fails after upgrade to 7.1 ga2

2018-11-22T17:39:36Z

Hi Erik,

When Liferay tries to create the tables for a service builder module again is because there is no Release_ record for that module in the database so it believes that the module wasn't deployed in the past.. Can you check/attach that info before an after to upgrade?

Can you also check the require-schema-version defined in the bnd.bnd file? The portal uses that value to compare it with the Release_ record and to know tif it reached he latest schemaVersion (and required) to be able to allow to use a service module.

I hope it helps.

Deploy of module service fails after upgrade to 7.1 ga2

2018-11-22T15:35:52Z

Hi everyone,

I have a problem after upgrading to v7.1 GA2 CE with deploy of a service from ServiceBuilder. I did not experience this problem with 7.1 GA1 CE.

In gogo shell I see these errors:

g! lb mytest
START LEVEL 20
   ID|State      |Level|Name
  949|Active     |    1|mytest-api (1.0.0)|1.0.0
  950|Active     |    1|mytest-service (1.0.0)|1.0.0
g!
g!
g! dm na
[950] com.foo.mytest.service
 [89] com.liferay.portal.spring.extender.internal.configuration.ServiceConfigurationInitializer unregistered
    com.liferay.portal.kernel.model.Release (&(release.bundle.symbolic.name=com.foo.mytest.service)(&(release.schema.version>=1.0.0)(!(release.schema.version>=1.1.0)))(|(!(release.state=*))(release.state=0))) service required unavailable
 [90] com.liferay.portal.spring.extender.internal.context.ModuleApplicationContextRegistrator unregistered
    com.liferay.portal.kernel.model.Release (&(release.bundle.symbolic.name=com.foo.mytest.service)(&(release.schema.version>=1.0.0)(!(release.schema.version>=1.1.0)))(|(!(release.state=*))(release.state=0))) service required unavailable
    com.liferay.portal.kernel.configuration.Configuration (&(configuration.bundle.symbolic.name=com.foo.mytest.service)(name=service)) service required unavailable
g!

g! dm wtf
2 missing dependencies found.
-------------------------------------
The following service(s) are missing:
 * com.liferay.portal.kernel.configuration.Configuration (&(configuration.bundle.symbolic.name=com.foo.mytest.service)(name=service)) is not found in the service registry
 * com.liferay.portal.kernel.model.Release (&(release.bundle.symbolic.name=com.foo.mytest.service)(&(release.schema.version>=1.0.0)(!(release.schema.version>=1.1.0)))(|(!(release.state=*))(release.state=0))) is not found in the service registry
g!

And none of the services from the com.foo.mytest is listed from the command "inspect cap service 950".

The strange thing is that this problem does not happen always, when running against another database schema, which is just an exact copy of the other, with the same schema owner and table owners, and which is also the same user running the portal.

Sometimes if the table already exist it tries to create it again anyway and shows this error message in log:

2018-11-22 13:56:35.891 ERROR [pipe-start 948][com_liferay_portal_upgrade_impl:97] Invocation to listener threw exception
com.liferay.portal.kernel.upgrade.UpgradeException: Bundle com.foo.mytest.service_1.0.0 [948] has invalid content in tables.sql:_create table TS_TSFoo (_    uuid_ VARCHAR(75) null,_    fooId LONG not null primary key,_    groupId LONG,_    companyId LONG,_    userId LONG,userName VARCHAR(75) null,_    createDate DATE null,_    modifiedDate DATE null,_    field1 VARCHAR(75) null,_    field2 BOOLEAN,_    field3 INTEGER,_    field4 DATE null,_    field5 VARCHAR(75) null_); [Sanitized]
    at com.liferay.portal.spring.extender.internal.context.ParentModuleApplicationContextExtender$InitialUpgradeStep.upgrade(ParentModuleApplicationContextExtender.java:219)
    at com.liferay.portal.upgrade.internal.executor.UpgradeExecutor$UpgradeInfosRunnable.run(UpgradeExecutor.java:159)
    at com.liferay.portal.output.stream.container.internal.OutputStreamContainerFactoryTrackerImpl.runWithSwappedLog(OutputStreamContainerFactoryTrackerImpl.java:119)
    at com.liferay.portal.upgrade.internal.executor.UpgradeExecutor.executeUpgradeInfos(UpgradeExecutor.java:110)
    at com.liferay.portal.upgrade.internal.executor.UpgradeExecutor.execute(UpgradeExecutor.java:87)
    at com.liferay.portal.upgrade.internal.release.osgi.commands.ReleaseManagerOSGiCommands$UpgradeInfoServiceTrackerMapListener.keyEmitted(ReleaseManagerOSGiCommands.java:485)
    at com.liferay.portal.upgrade.internal.release.osgi.commands.ReleaseManagerOSGiCommands$UpgradeInfoServiceTrackerMapListener.keyEmitted(ReleaseManagerOSGiCommands.java:474)
    at com.liferay.osgi.service.tracker.collections.internal.map.ServiceTrackerMapImpl$DefaultEmitter.emit(ServiceTrackerMapImpl.java:222)
    at com.liferay.osgi.service.tracker.collections.map.PropertyServiceReferenceMapper.map(PropertyServiceReferenceMapper.java:43)
    at com.liferay.osgi.service.tracker.collections.internal.map.ServiceTrackerMapImpl$ServiceReferenceServiceTrackerCustomizer.addingService(ServiceTrackerMapImpl.java:260)
    at com.liferay.osgi.service.tracker.collections.internal.map.ServiceTrackerMapImpl$ServiceReferenceServiceTrackerCustomizer.addingService(ServiceTrackerMapImpl.java:248)
    at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:943)
    at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:1)
    at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
    at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
    at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:903)
    at org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:109)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:891)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:804)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:127)
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:228)
    at org.eclipse.osgi.internal.framework.BundleContextImpl.registerService(BundleContextImpl.java:469)
    at org.eclipse.osgi.internal.framework.BundleContextImpl.registerService(BundleContextImpl.java:487)
    at org.eclipse.osgi.internal.framework.BundleContextImpl.registerService(BundleContextImpl.java:1004)
    at com.liferay.portal.spring.extender.internal.context.ParentModuleApplicationContextExtender$ParentModuleApplicationContextExtension._processInitialUpgrade(ParentModuleApplicationContextExtender.java:612)
    at com.liferay.portal.spring.extender.internal.context.ParentModuleApplicationContextExtender$ParentModuleApplicationContextExtension.start(ParentModuleApplicationContextExtender.java:570)
    at org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:259)
    at org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:232)
    at org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:488)
    at org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:1)
    at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232)
    at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:450)
    at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:908)
    at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
    at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
    at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:230)
    at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:137)
    at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:129)
    at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:191)
    at org.eclipse.osgi.container.Module.publishEvent(Module.java:476)
    at org.eclipse.osgi.container.Module.start(Module.java:467)
    at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:428)
    at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:447)
    at org.eclipse.equinox.console.commands.EquinoxCommandProvider.start(EquinoxCommandProvider.java:243)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.java:139)
    at org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:91)
    at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:599)
    at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526)
    at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415)
    at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416)
    at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229)
    at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)
Caused by: org.postgresql.util.PSQLException: ERROR: relation "ts_tsfoo" already exists
    at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2412)
    at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2125)
    at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:297)
    at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:428)
    at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:354)
    at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:301)
    at org.postgresql.jdbc.PgStatement.executeCachedSql(PgStatement.java:287)
    at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:264)
    at org.postgresql.jdbc.PgStatement.executeUpdate(PgStatement.java:244)
    at com.zaxxer.hikari.pool.ProxyStatement.executeUpdate(ProxyStatement.java:117)
    at com.zaxxer.hikari.pool.HikariProxyStatement.executeUpdate(HikariProxyStatement.java)
    at com.liferay.portal.dao.db.BaseDB.runSQL(BaseDB.java:294)
    at com.liferay.portal.dao.db.BaseDB.runSQL(BaseDB.java:264)
    at com.liferay.portal.dao.db.BaseDB.runSQLTemplateString(BaseDB.java:452)
    at com.liferay.portal.dao.db.BaseDB.runSQLTemplateString(BaseDB.java:509)
    at com.liferay.portal.spring.extender.internal.context.ParentModuleApplicationContextExtender$InitialUpgradeStep.upgrade(ParentModuleApplicationContextExtender.java:215)
    ... 59 more

The module project was created with blade with no other changes than changing the build namespace to "TS" in the generated service.xml (foo table).

blade create -t service-builder -p com.foo.mytest mytest

This is the build.gradle for the mytest-service module, I modified some versions to adapt to GA2.

dependencies {
    compileOnly group: "biz.aQute.bnd", name: "biz.aQute.bndlib", version: "3.5.0"
    compileOnly group: "com.liferay", name: "com.liferay.portal.spring.extender.api", version: "3.0.0"
    compileOnly group: "com.liferay", name: "com.liferay.portal.spring.extender.impl", version: "1.0.14"
    compileOnly group: "com.liferay.portal", name: "com.liferay.portal.kernel", version: "3.39.2"
    compileOnly group: "com.liferay", name: "com.liferay.petra.string", version: "2.0.1"
    compileOnly project(":modules:mytest:mytest-api")
}

buildService {
    apiDir = "../mytest-api/src/main/java"
}

group = "com.foo.mytest"

I wonder what triggers it to insist on creating a new table even if one already exist, and other times the log just says that the table already exist and continues without throwing any error?

But it may also fail even if the table does not already exist, and then only the gogo shell shows the errors shown above .

I upgraded to latest Liferay-Workspace in settings.gradle with 1.10.9, and service-builder to 1.0.247.

Hope someone can help with this?

Thanks,

Erik