Reasoning:
* Not all code needs an actual User object. And even if, most code
doesn't need it to be validated. That's expensive.
Let the users decide.
* setUserObj() is almost never called anyway. And the few places that
call it go the extra mile and create a User object just to please this
setter. We can avoid or at least postpone this.
* All callers already fall back to getUser() when there is no
getUserObj().
* For a while we try to replace the User class with much smaller
interfaces, whenever possible. This is a chance to remove of one more.
* A "user IP" is a concept that doesn't even exist in this code. The
setter writes to the same property as setUsername(). This makes it
very easy to use these methods wrong, and this indeed already happened
in some places.
Change-Id: I6687305a5be68e8a068f11482625a0a6bd9626f2
This is almost always null. All callers expect this already and fall
back to getUser().
It looks like setUserObj() is sometimes called with false. Luckily the
users I can find use the ?: operator and behave the same, no matter
if they get null or false. Let's fix it anyway to make the code less
surprising.
Depends-On: Id019f633a19f925faa1e5890a9b7818bb9e81a84
Change-Id: I128c21c60f6bb017521218933c22e6f1754e9133
This is to be used within the FileImporter extension to allow
adding custom loggers to this import process.
Change-Id: I4a6c573fc0a69b06d696cd2afca9226fb492a9bc
