We have very nasty problems using Betamax with Java/Glassfish/Jersey
The problem: jetty-server uses SLF4J 1.6.x and the fat pig glassfish-embedded-all carries SLF4J 1.5.6.
at java.lang.Class.forName0(Native Method)
I tried to change the order of dependencies but didn't find a solution.
A patched version of glassfish-embedded-all w/o SLF4J didn't work either.
Would it be possible to start jetty in an external process?
I've been bitten by this too. It's particularly nasty because Jetty doesn't express its slf4j dependency via maven; it's an optional runtime dependency.
I think what you propose is a good idea. You could then run a Betamax 'server' either standalone or with a forked process from a maven/gradle build. The annotated tests would just override proxy settings so they connected to the running Betamax .
I'd like to help you, at least with some testing, if you like.
Tell me, if I can support you (Java knowledge: excellent, Groovy: not yet).
BTW, would #47 for using HttpClient decorator solve the issue with jetty? Maybe this would be a better investment?
Yes #47 would also solve the issue but I'd like to maintain the proxy as an option & I think it would be valuable to implement this functionality.
I apologize that this has gone for so long overlooked. We currently do not have plans to support running Betamax in a forked process. Our most recent efforts have been to simplify, refactor, and reduce dependencies. I would say a fork is a natural evolution as long as we can get it to play nice with Maven, but we're still a ways out from that.
If you're still interested, we should discuss a feature request and build some acceptance criteria.