If Lombok generates your equals and hashCode methods I personally wouldn't spend time testing it. They know what you're doing, and you'd be testing Lombok more than your own code.
If your IDE generates your equals and hashCode methods you need to test it thoroughly. Sure, what it has generated now will work just fine, but if you add a field and forget to update equals and/or hashCode, your method(s) may be broken.
I like to take control, so I write my own (parameterized) equals tests. What I basically do is create one instance, then compare it with:
* null * a different type (usually a String)
* for each field, an object of the same type with just that field set differently
Because I always use Objects.equals for nullable fields I don't bother checking with null and non-null separately. If you'd do that, you get 4 tests for each field for the null / non-null combinations (although you can combine a few).
As for hashCode, I don't really test that as well. I do test that the object's hashCode is the same when called twice, and that it's the same as an equal object. If fields are not used in hashCode you'd need to test with objects with different values for these fields as well.
The NumberFormatException tells you what the input was. In this case it was null, which simply means that the "name" parameter was not sent correctly. This probably occurs because the first time you go to this URL, you don't pass the "name" parameter yet.
Java looks at the declared type, not the actual type, when determining which methods can be called. The declared type is not your anonymous inner class' type, but Main. Since that has no init method, you can't call it.
That latter is expected, because (unfortunately) arrays inherit their toString (and equals and hashCode) implementations from Object. That means they get something that looks very cryptic. In this case, the [ indicates it's an array; the Ljava.lang.String; is the array's component type (so it's a String), and then come the @ and the system hash code in HEX.
You can (probably) also do this with one host. Just use a <Location> (or <LocationMatch>) element in your Apache configuration, and define the custom routing there. Note that the location matters, at least if you're using multiple <Location> and/or <LocationMatch> elements - as far as I know, they are evaluated from top to bottom.
However, I'd say the more pressing concern is the actual error. There's apparently something going wrong in your 'add-customer.htm' Thymeleaf template, on line 39, column 52. The logs should show you more information, but that's where you now need to focus on first.