Migrating from 7.6 to 7.7 - Embbeded RESP API

Hi.

I`m a rest interface user for a long time and now I have to embbed it, and I did. Currently I have a full working Spring Camunda Rest with basic authentication enabled. I use camunda 7.7 by the way.

Just for information, I did that, using the starter project at github, because I need more flexibility to create beans and new end-points.

So, I replaced the Old Rest interface and everithing was working good, except any database writing operation. When I try to write anything I get the following error:

 SEVERE [http-nio-8080-exec-69] org.camunda.commons.logging.BaseLogger.logError ENGINE-16004 Exception while closing command context: null
 java.lang.NullPointerException
	at org.camunda.bpm.engine.impl.cmd.GetNextIdBlockCmd.execute(GetNextIdBlockCmd.java:37)
	at org.camunda.bpm.engine.impl.cmd.GetNextIdBlockCmd.execute(GetNextIdBlockCmd.java:24)
	at org.camunda.bpm.engine.impl.interceptor.CommandExecutorImpl.execute(CommandExecutorImpl.java:24)
	at org.camunda.bpm.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:104)
	at org.camunda.bpm.engine.spring.SpringTransactionInterceptor$1.doInTransaction(SpringTransactionInterceptor.java:42)
	at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:130)
	at org.camunda.bpm.engine.spring.SpringTransactionInterceptor.execute(SpringTransactionInterceptor.java:40)
	at org.camunda.bpm.engine.impl.interceptor.ProcessApplicationContextInterceptor.execute(ProcessApplicationContextInterceptor.java:66)
	at org.camunda.bpm.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:30)
	at org.camunda.bpm.engine.impl.db.DbIdGenerator.getNewBlock(DbIdGenerator.java:46)
	at org.camunda.bpm.engine.impl.db.DbIdGenerator.getNextId(DbIdGenerator.java:38)
	at org.camunda.bpm.engine.impl.db.entitymanager.DbEntityManager.ensureHasId(DbEntityManager.java:479)
	at org.camunda.bpm.engine.impl.db.entitymanager.DbEntityManager.insert(DbEntityManager.java:404)
	at org.camunda.bpm.engine.impl.persistence.entity.AuthorizationManager.insert(AuthorizationManager.java:133)
	at org.camunda.bpm.engine.impl.persistence.AbstractManager$1.call(AbstractManager.java:295)
	at org.camunda.bpm.engine.impl.persistence.AbstractManager$1.call(AbstractManager.java:289)
	at org.camunda.bpm.engine.impl.interceptor.CommandContext.runWithoutAuthorization(CommandContext.java:471)
	at org.camunda.bpm.engine.impl.persistence.AbstractManager.saveDefaultAuthorizations(AbstractManager.java:289)
	at org.camunda.bpm.engine.impl.identity.db.DbIdentityServiceProvider.createDefaultAuthorizations(DbIdentityServiceProvider.java:255)
	at org.camunda.bpm.engine.impl.identity.db.DbIdentityServiceProvider.saveGroup(DbIdentityServiceProvider.java:91)
	at org.camunda.bpm.engine.impl.identity.db.DbIdentityServiceProvider.saveGroup(DbIdentityServiceProvider.java:40)
	at org.camunda.bpm.engine.impl.cmd.SaveGroupCmd.executeCmd(SaveGroupCmd.java:41)
	at org.camunda.bpm.engine.impl.cmd.SaveGroupCmd.executeCmd(SaveGroupCmd.java:27)
	at org.camunda.bpm.engine.impl.cmd.AbstractWritableIdentityServiceCmd.execute(AbstractWritableIdentityServiceCmd.java:36)
	at org.camunda.bpm.engine.impl.interceptor.CommandExecutorImpl.execute(CommandExecutorImpl.java:24)
	at org.camunda.bpm.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:104)
	at org.camunda.bpm.engine.spring.SpringTransactionInterceptor$1.doInTransaction(SpringTransactionInterceptor.java:42)
	at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:130)
	at org.camunda.bpm.engine.spring.SpringTransactionInterceptor.execute(SpringTransactionInterceptor.java:40)
	at org.camunda.bpm.engine.impl.interceptor.ProcessApplicationContextInterceptor.execute(ProcessApplicationContextInterceptor.java:66)
	at org.camunda.bpm.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:30)
	at org.camunda.bpm.engine.impl.IdentityServiceImpl.saveGroup(IdentityServiceImpl.java:86)
	at org.camunda.bpm.engine.rest.impl.GroupRestServiceImpl.createGroup(GroupRestServiceImpl.java:95)
	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.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137)
	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296)
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250)
	at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:140)
	at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:103)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
	at org.jboss.resteasy.core.SynchronousDispatcher.invokePropagateNotFound(SynchronousDispatcher.java:217)
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:224)
	at org.jboss.resteasy.plugins.server.servlet.FilterDispatcher.doFilter(FilterDispatcher.java:62)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.camunda.bpm.engine.rest.security.auth.ProcessEngineAuthenticationFilter.doFilter(ProcessEngineAuthenticationFilter.java:148)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.camunda.bpm.engine.rest.filter.CacheControlFilter.doFilter(CacheControlFilter.java:41)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
	at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:617)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:518)
	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1091)
	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:668)
	at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1527)
	at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1484)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
	at java.lang.Thread.run(Thread.java:745)

Hi again.

Before start this process we have the 7.6 engine in production, so I took the new 7.7 and apply the migration scripts. The rest of history is on my last post.

Ok, I decided to test with a new database and, for my surprise, it worked. I took a look and realized one thing: My deployment key is not that guid anymore, is an integer and I think that`s the reason of my problem.

So, did you guys changed the NextKey and KeyGeneration on 7.7? What can I do, I can`t just get rid of all data gerenated over this year.

1 Like

Could it be that you accidentally changed the configuration of your process engine? Make sure the idGenerator property of the engine is set to an instance of org.camunda.bpm.engine.impl.persistence.StrongUuidGenerator. The default is an instance of org.camunda.bpm.engine.impl.db.DbIdGenerator which uses database-backed sequence to generate IDs and is known to be unstable.

2 Likes

Thanks.

To be very honest I never change that.

I added the following line to my configuration

config.setIdGenerator(new StrongUuidGenerator());

I read this article and noticed that StrongUuidGenerator is default.

After adjust my config class and add java-uuid-generator maven dependency everything works fine.

I’m glad this solved your problem. The StrongUuidGenerator is default whenever you use a shared, container-managed Camunda engine. For embedded engines (i.e. where you manage the process engine configuration yourself), the DbIdGenerator is the default.

1 Like

Hey Edgar, I am using spring boot 2.4.4 in my project where can I add this configuration, that you are referring to? I don’t see anything related to IdGenerator. Please help

Hi @satyaram413,

In case you use Spring Boot Starter, configuration properties can be found here:
https://docs.camunda.org/manual/7.15/user-guide/spring-boot-integration/configuration/
search on the page for id-generator, actually the strong generator is already used as default.

Please notice that is a quite old topic, therefore I will close it, your question seems to be better suited in a new post.

Best regards,
Yana

1 Like