Sorry for the delay. A number of us were traveling when you sent it.

The reason the class is final is just following the common practice of explicitly disallowing inheritance unless the class is explicitly designed for it. The rationale behind the practice is that a class that allows inheritance essentially has a fixed implementation that can not evolve without potentially breaking compatibility. Additionally if the class has concurrency behavior, inheritance that is not designed around an explicit synchronization contract can lead to all kinds of bugs.

If you do want to use mock testing, there are frameworks like easymock which can generate proxies for you, and your test code stays quite clean.

On Oct 17, 2015, at 9:40 AM, Greg Hellings <greg.hellings@gmail.com> wrote:

Ping.

--Greg

On Oct 8, 2015 11:41 AM, "Greg Hellings" <greg.hellings@gmail.com> wrote:

I'm trying to mock out the HttpServerExchange object in my tests, but
I apparently cannot do so because the class is declared final. Why is
it final? Does that give Undertow anything beneficial?

If there's good reason to not remove the final, I can just wrap the
object in a proxy class that's not final, but I'd rather not do that
just to get around limitations in mocking. Another alternative would
be for me to skip unit tests on the handler methods and leverage
integration tests.But there are sometimes bits of logic in the handler
that I want to Unit Test directly.

Any help would be appreciated.

--Greg

_______________________________________________
undertow-dev mailing list
undertow-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev