I have a lot of test-suites that all have a behavior that matches single-instance with lots of heavy resource lifting and ordered-methods so I think it would be many years of expectation.
Of course, I always keep in mind that I might find some other way to rewire the tests so that they would be compatible with instances PER_METHOD but, to date, I am stuck with what I have. On Tue, Mar 3, 2026 at 8:29 AM Federico Mariani < [email protected]> wrote: > I don't think we're going to remove it anytime soon. The deprecation > targets only the old API methods in favor of JUnit 5 (and 6) best > practices, which in this case means using the @TestInstance annotation with > PER_CLASS. > > To be honest, both LegacyCamelContextManager and TestInstance PER_CLASS had > a bug that went unnoticed because they aren't widely used in Camel, most > Camel tests use the default PER_METHOD lifecycle, which is why we never > caught it earlier. > > Out of curiosity, how much time do you expect to save with PER_CLASS > compared > to PER_METHOD? > > Il giorno lun 2 mar 2026 alle ore 19:38 Santiago Acosta < > [email protected]> ha scritto: > > > Thank you for putting in the fix. > > > > I have just one follow up question/concern. Is the > > LegacyCamelContextManager going to disappear? > > > > The javadoc for the class reads: > > A {@link CamelContext} test lifecycle manager based on the behavior that > > was built in {@link CamelTestSupport} up to Camel 4.7.0 > > > > Should I prepare for a future where the PER_CLASS strategy no longer > > applies? > > > > On Mon, Mar 2, 2026 at 1:58 PM Federico Mariani < > > [email protected]> wrote: > > > > > Hello Santiago, > > > > > > Thanks for reporting it, I managed to reproduce the issue, as you > > reported, > > > the CamelContext is not stopped after tests complete. > > > > > > I opened https://issues.apache.org/jira/browse/CAMEL-23116 and > > > https://github.com/apache/camel/pull/21679 . You are correct, the > issue > > is > > > that *.stop()* is a NO-OP method in the *LegacyCamelContextManager*, > > while > > > *.close()* is supposed to do a full clean up. > > > > > > Regards, > > > Federico > > > > > > Il giorno dom 1 mar 2026 alle ore 13:09 Santiago Acosta < > > > [email protected]> ha scritto: > > > > > > > Hi > > > > > > > > I am doing a big upgrade jump from 4.6.0 to 4.17.0 and I have hit a > > snag > > > > regarding my tests (I use CamelTestSupport with the PER_CLASS > > > annotation). > > > > > > > > While I was trying to understand why some of my test classes > processes > > > leak > > > > into the next test class, I discovered that my clean up routines > where > > > not > > > > being executed "after stop" and causing all sorts of noise. > > > > > > > > I went down the rabbit hole to find why my clean up routines were not > > > being > > > > executed correctly and found that > > > > the LegacyCamelContextManager::doStopCamelContext method is called in > > the > > > > method ::close. > > > > > > > > The interface describes that CamelContextManager::close (copied from > > the > > > > source code) > > > > > > > > Close the manager (this is run after all tests have been executed) > > > > > > > > > > > > *However, I cannot seem to find where or how this ::close function is > > > being > > > > called.* > > > > > > > > Are we supposed to call this method ourselves? > > > > > > > > I know that the 4.6 -> 4.8 jump is quite big but I think I have > solved > > > all > > > > of my quandaries except for this one which has taken me quite a while > > to > > > > pin down. > > > > > > > > > > > > > -- > > Best regards, > > > > *Santiago Acosta Arreaza* > > > -- Best regards, *Santiago Acosta Arreaza*
