Replies: 1 comment
-
Interesting idea... There is actually an API - Channel Acceptor is one... So you are free to implement your own Ingres adapter and invoke the Channel Acceptor... I think the current module structure should be changed... The Ingres Adapter is an SPI, so the module dependency should be in the project: <dependendcy>
<groupId>io.holunda</groupId>
<artifactId>camunda-bpm-correlate-starter</artifactId>
</dependendcy>
<dependendcy>
<groupId>io.holunda</groupId>
<artifactId>camunda-bpm-correlate-ingres-1</artifactId>
</dependendcy>
<dependendcy>
<groupId>io.holunda</groupId>
<artifactId>camunda-bpm-correlate-ingres-2</artifactId>
</dependendcy> not just a dependency to an ingres with transitiver starter dependency... So the Ingres Adapter should not re-export the starter dependency I think...I'll fix this ASAP. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I'm just studying the lib and got a little bit confused by the ingres concept and the class
ChannelMessageAcceptor
. Wouldn't it be better to just have an API through which some calling code could hand a message over to this lib? I.e. the lib would become passive at this place.The calling code would be responsible for receiving the messages from the channels (this obviously depends on the technology). And then this glue code would call the lib's API and tell "here's a message to deliver". The channel the message has been received over could become part of the metadata. I would not create a dedicated field for this. If an app needs this information it could create a message header with a "stadardized" name.
The concept of an adapter would then not be needed anymore. Of course the functionality would still have to be present, but the concept would not lie in the lib space.
Beta Was this translation helpful? Give feedback.
All reactions