-
Notifications
You must be signed in to change notification settings - Fork 2
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
Fix missing threadPoolSize param in TransactionalOutboxBuilder.build #29
Conversation
ad3e158
to
20c02f5
Compare
Allowed for missing thread-pool parameter to not break backwards compatibility, even though it was not intended before. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👏 for the contribution! 🎉
I've left some comments to check and also, don't forget to bump the version appropriately (example commit, README relevant section).
@JvmName("from") // for a nicer groovy API | ||
internal fun FixedThreadPoolExecutorServiceFactory(threadPoolSize: Int? = null): FixedThreadPoolExecutorServiceFactory { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, what's the benefit of this? 🤔
Could you provide an example of how it looks w/o it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Without the annotation, the function is exposed like this:
def factory = FixedThreadPoolExecutorServiceFactoryKt
.FixedThreadPoolExecutorServiceFactory(null)
Groovy has no knowledge about extension functions. Technically, all extension functions are compiled into static methods inside a class, so that's how we can call them outside Kotlin.
Tbh, the factory is called only once, so it does not make such a difference. Up to you if keep it or not.
import io.github.bluegroundltd.outbox.executor.FixedThreadPoolExecutorServiceFactory.Companion.DEFAULT_THREAD_NAME_FORMAT | ||
import io.github.bluegroundltd.outbox.executor.FixedThreadPoolExecutorServiceFactory.Companion.DEFAULT_THREAD_POOL_SIZE |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are those imports really needed? 🤔 (their definitions are in the same file, no?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sadly, yes. Tbh I am not sure why they are necessary either.
My first thought was to extract the constants outside of the class to top-level fields. This way we can keep them private, and we would no longer need the imports. But I didn't apply the refactor to avoid creating extra non-functional differences.
f8a45ea
to
c94a36c
Compare
…uild Signed-off-by: George Papadopoulos <[email protected]>
Signed-off-by: George Papadopoulos <[email protected]>
c94a36c
to
3cf2bfe
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
No description provided.