Parameters of type ObjectId with null value are changed to non-null upon invocation

[tiddman]

I have a method with this signature:

void fetchSince(FeedMeta feedMeta, ObjectId since, Promise<List<Position>> promise);

and am invoking it like this:

fetchSince(feedMeta, null, promise);

When invoked, the 2nd parameter is not null, it's an ObjectId such as "57728ed86cf58c9c45dfca95". The stack is below.

I suspect that in the Qbit method invocation internals, the null parameter is getting swizzled to the result of "new ObjectId()" which is a non-null value. A workaround is to pass the value by string.

at com.revelfire.poc.service.FetchServiceImpl.fetchSince(FetchServiceImpl.java:123)
at io.advantageous.boon.core.reflection.impl.MethodAccessImpl.invoke(MethodAccessImpl.java:329)
at io.advantageous.boon.core.reflection.impl.MethodAccessImpl.invokeDynamic(MethodAccessImpl.java:316)
at io.advantageous.qbit.boon.service.impl.MapAndInvokeDynamic.mapArgsAsyncHandlersAndInvoke(MapAndInvokeDynamic.java:52)
at io.advantageous.qbit.boon.service.impl.BoonServiceMethodCallHandler.mapArgsAsyncHandlersAndInvoke(BoonServiceMethodCallHandler.java:101)
at io.advantageous.qbit.boon.service.impl.BoonServiceMethodCallHandler.invokeByName(BoonServiceMethodCallHandler.java:335)
at io.advantageous.qbit.boon.service.impl.BoonServiceMethodCallHandler.receiveMethodCall(BoonServiceMethodCallHandler.java:88)
at io.advantageous.qbit.service.impl.BaseServiceQueueImpl.doHandleMethodCall(BaseServiceQueueImpl.java:232)
at io.advantageous.qbit.service.impl.BaseServiceQueueImpl.access$000(BaseServiceQueueImpl.java:85)
at io.advantageous.qbit.service.impl.BaseServiceQueueImpl$3.receive(BaseServiceQueueImpl.java:447)
at io.advantageous.qbit.service.impl.BaseServiceQueueImpl$3.receive(BaseServiceQueueImpl.java:434)
at io.advantageous.qbit.queue.impl.BasicReceiveQueueManager.manageQueue(BasicReceiveQueueManager.java:94)
at io.advantageous.qbit.queue.impl.BasicReceiveQueueManager$$Lambda$16/361571968.run(Unknown Source)
at io.advantageous.qbit.concurrent.ScheduledThreadContext.lambda$start$30(ScheduledThreadContext.java:89)
at io.advantageous.qbit.concurrent.ScheduledThreadContext$$Lambda$11/257608164.run(Unknown Source)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

[RichardHightower]

I think you are right. I could track this down and pass the null. Generally, the service layers does not like nulls.

[revelfire]

Can we use Void like Vertx does?

[revelfire]

Actually no I guess not it's about value not type sorry stupid comment.

[RichardHightower]

How are you invoking it? WebSocket? ServiceQueue? or ServiceBundle? Can you create a small test case that reproduces this?