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* >
