Open dispalt opened 1 month ago
Hi @dispalt ! Thank you for highlighting the issue 🙌 I was planning a release soon, so I can also include the Thread.currentThread().getContextClassLoader()
patch into the release. Let me know whether you feel comfortable with contributing or shall I do it 😄
@dispalt, could you please also describe what class loader you would need in the Play app? Is it this method? https://www.playframework.com/documentation/2.3.x/api/java/play/Application.html#classloader()
So this is just for dev; however, what play does is put all your deps in a single Classloader and your current code in a different class loader which is kinda similar to what sbt does with its various class loading strategies. So the issue isn't normally presented in sbt unless maybe you are using the turbo mode.
I haven't tested my proposed change yet as a separate library I copied some code and put it in zio.temporal
namespace and it worked (which I would expect), so Ill try to test this, I think it will cover more cases and if it doesn't its easier to much around that like I've had to with other java-centric libraries
Honestly I am not sure how to fix this without some mutable secret variable. Maybe ill just maintain my tiny little shim and we can call it good. It might be good to add something to the docs though, ill maybe submit a PR?
Hi there!
Great library.
So I am running into an issue using the stub proxy and particularly this call is failing to produce the right classloader due to a combination of SBT and play framework.
I've since replaced these methods locally but was thinking if there was a way either where I can reflect and change this (because I am assuming I am a minority) or something else. It's not really that easy to make configurable, but I was thinking at least
Thread.currentThread().getContextClassLoader()
might be easier to muck around with since I can deal with that.