Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AbstractBasicReadWriteAdapter can't convert value of type Long to long #205

Closed
LowCostCustoms opened this issue Jan 27, 2022 · 1 comment
Assignees
Labels
Type: bug Something isn't working
Milestone

Comments

@LowCostCustoms
Copy link

Steps to reproduce

  • camunda-bpm-data version: 1.2.5
  • Camunda BPM version: 7.16.4
  • JDK version: openjdk 11.0.9.1
  • Operating system: macOS 10.15.7
  • Complete executable reproducer: (e.g. GitHub Repo)
  • Steps:
  1. Create a process definition with a single service task activity, which is backed by a Java Delegate;
  2. Add an input parameter mapping on Input/Output tab for an input variable, using ${0} as the Variable Assignment Value expression;
  3. In your code, create a variable factory for the variable defined on step 2 using CamundaBpmDataKotlin.longVariable method;
  4. In the delegate code, which is called by the task defined on step 1, create a piece of code, which reads the variable value using the factory defined on step 3;
  5. Deploy and run the process instance.

Expected behaviour

Value 0 is successfully assigned to the variable defined on step 2 and then successfully by the code defined on step 4.

Actual behaviour

An exception of type WrongVariableTypeException is thrown while trying to find the variable value from code, telling that it's impossible to convert value 0 to long.

Perhaps, the full stack trace is unnecessary, so I'll leave the head only:

io.holunda.camunda.bpm.data.adapter.WrongVariableTypeException: Error reading offset: Couldn't read value of long from 0
	at io.holunda.camunda.bpm.data.adapter.basic.AbstractBasicReadWriteAdapter.getOrNull(AbstractBasicReadWriteAdapter.java:51) ~[camunda-bpm-data-1.2.5.jar:na]
	at io.holunda.camunda.bpm.data.adapter.basic.ReadWriteAdapterVariableScope.getOptional(ReadWriteAdapterVariableScope.java:45) ~[camunda-bpm-data-1.2.5.jar:na]
	at io.holunda.camunda.bpm.data.reader.VariableScopeReader.getOptional(VariableScopeReader.java:29) ~[camunda-bpm-data-1.2.5.jar:na]
	at io.holunda.camunda.bpm.data.reader.VariableReader.getOrNull(VariableReader.java:61) ~[camunda-bpm-data-1.2.5.jar:na]
	at my.namespace.MyBean.myJavaDelegate$lambda-9(MyBean.kt:49) ~[main/:na]
	at org.camunda.bpm.engine.impl.bpmn.delegate.JavaDelegateInvocation.invoke(JavaDelegateInvocation.java:40) ~[camunda-engine-7.16.4-ee.jar:7.16.4-ee]
	at org.camunda.bpm.engine.impl.delegate.DelegateInvocation.proceed(DelegateInvocation.java:58) ~[camunda-engine-7.16.4-ee.jar:7.16.4-ee]

I assume the reason is that when a variable value is assigned by Camunda Engine, the type of its value is java.lang.Long. However Long type in kotlin is a totally different from Java's Long, and according to my observations, the corresponding Java class for it is java.base.long (at least when you retrieve it via Long::class.javaClass construct). The latter, in contrast to Java Long, is a primitive type. This causes conversion fail.

As a workaround for variables like this I had to use factories produced by CamundaBpmDataKotlin.customVariable<java.lang.Long>(...) method.

@janvonneree
Copy link
Collaborator

I could reproduce the issue.

In the AbstractBasicReadWriteAdapter the expected type is compared with the variable with isAssignableFrom(...) witch dose not match. The cast would succeed, but if got no pretty solution in mind so far.

@zambrovski zambrovski added the Type: bug Something isn't working label Feb 7, 2022
@janvonneree janvonneree self-assigned this Feb 7, 2022
@janvonneree janvonneree added the State: in progress Assignee is working on the issue. label Feb 7, 2022
jangalinski added a commit that referenced this issue Feb 24, 2022
…s_kotlin

feature: reading basic java variables as kotlin #205
@janvonneree janvonneree added this to the 1.2.6 milestone Feb 25, 2022
@janvonneree janvonneree removed the State: in progress Assignee is working on the issue. label Feb 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants