A neat improvement to the port finder thing would be a way for it to work over multiple JVMs. That is, it won't work reliably when you use the fork option in surefire. The only workaround I know would be to use different starting ports for every test (separated by about 50-100 ports perhaps?). Kind of hard to enforce a lock or singleton across VMs without some networking code which would get a bit complicated. Then again, maybe not so much. I might try this out sometime.
On 26 June 2014 10:00, Gary Gregory <garydgreg...@gmail.com> wrote: > I got rid of the new finder class in favor of the existing one. If I reuse > the one from Mina it does not work due to port range issues. > > Gary > > Gary > > > -------- Original message -------- > From: Matt Sicker > Date:06/25/2014 11:02 (GMT-05:00) > To: Log4J Developers List > Subject: Re: Finding free ports > > I think AvailablePortFinder was a class I copied from Camel. > > > On 24 June 2014 23:24, Gary Gregory <garydgreg...@gmail.com> wrote: > >> We have two ways of finding free socket ports: >> >> - org.apache.logging.log4j.test.AvailablePortFinder has been around for a >> while, and >> - org.apache.logging.log4j.core.net.FreePortFinder which is a new class I >> refactored out of a bunch of duplicate code in the Flume tests. >> >> We need to pick on way of doing this. FreePortFinder gets my vote because >> it is simpler. >> >> Thoughts? >> >> Gary >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> Java Persistence with Hibernate, Second Edition >> <http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> > > > > -- > Matt Sicker <boa...@gmail.com> > -- Matt Sicker <boa...@gmail.com>
