search

mvysny / vok-orm

Mapping rows from a SQL database to POJOs in its simplest form
MIT License
22 stars 4 forks source link

annoying warning if no validator #11

Closed DALDEI closed 5 years ago

DALDEI commented 5 years ago

If I dont have a JPA validator and dont want one I get an annoying warning from:

    LoggerFactory.getLogger(VokOrm::class.java).warn("vok-orm failed to build the default validator, using no-op", ex)

Any way to shut this up ? ( short of blocking all warnings from VokOrm::class )

mvysny commented 5 years ago

Sorry, probably no other way besides configuring logging or adding hibernate-validator on your classpath. Note that hibernate-validator doesn't (luckily) have anything to do with JPA :)

But you're right: logging the stacktrace is definitely an overkill. I'll remove the stacktrace, then the warning would be just one line (and perhaps can be downgraded to INFO), which could be more tolerable. What do you think?

DALDEI commented 5 years ago

Its a good start. A better is to sell me a clue what one would have to do to instal this magic unicorn and why I would want to ? I google'd the infinite wisdom font, installed dependency in gradle and the warnings didnrt go away. The only reason I took the 15 minutes to do so wasn't because I wanted it, I just wanted the #%#% message to go away. I got neither the joy of a new toy nor the slack of a pestering robot. I did get 10 minutes of my life wasted :)

The subtlety of this is that I A) Didn't know I wanted this 'feature' B) Still Don't know I want this feature (works fine without it, why add it ? ) C) Not sure it IS a feature but its annoying me like one :) D) WTF I gave it my 10 minute best shot and -- its still crying wolf F) Wolf. What is the significant panic attack I should be fearing by not figuring out how to shut this thing up 'the right way ' (dynomite, gasoline, bonfire, very tall cliff, creative curses) Sure 'validation' sounds nice but its more subtle then lets on -- like the 'blinken lights' in your car -- 2 /3 of the time they flash (also annoying) -- because they are broken -- not what it is they are supposedly spreading panic about.

Compromise: an opt-in ENV or Property that enables annoying you when you dont toe the liine - default being warning -off or at best trace. a

This is actually an issue because Im attempting to demonstrate to my boss that using Kotlin could be A Good Thing. He is highly skeptical and instantly camped it with 'the other JVM 'shiny toys' that end up largely useless while promoting the awesomeness of being vendor-locked into mega-monolithic-frameworks like Spring ("boot" the New Spring -- it looks small and harmless .. )
So anything that comes up unsolicited with a scary looking message about the world coming to and end and cats sleeping with dogs and Kotlin Programmers being Anarchists .. might make me have to rip out the offender before he walks by and sees it scroll off my screen tarnishing an otherwise elegant experience. -- He'll certainly be putting Extra Stars and Points in his favor with the "Kotlin is useless and just for Wimps" philosophy.

And oddly, when asked about how Kotlin interoperates with some of the seriously heavy-weight 'features' of Java that have grown over the years to attempt to address fundamental flaws in the language -- My answer was that for the most part you can still use them (annotation processing, dependency injection, soul-selling slavery to God Of Spring) -- but I find mostly I simply don't need them anymore -- A good deal of the fun of learning kotin was one by one ripping out the various add-on tools that never did quite work right but I couldn't live without (lombok, etc) and now I find "Why would I WANT to ? " -- So I have myself thinking -- what is it that is so ingrained into the programming ecosystem that the very thought of it not being there starts a panic alarm. Something which I've never used, never missed, and only glossed over in the Jave docs as sonn as I read "Must be provided by 3rd party implementation such as JEE ..." and now as Im learning to lighten my load so I can crawl into through the eye of the needle -- and not missing all those extra toys ... I find it -- well -- ironic, somewhat funny, a tad annoying, but most clearly illuminating my slowly consolidated viewpoint of starting with "Just Say No" - first -- I didnt need it or miss it for 20 (30?) years -- why now has the beast started becoming awake and fighting for its pending demise ... Poetic Good night - dont take me too seriously (I am serious but not serious-serious)

mvysny commented 5 years ago

Ugh, I feel your pain with Spring promoters. It's human nature to defend one's experience, even though obtained through self-torture and mind-crushing study of DI and Spring. Stockholm syndrome maybe?

My two cents: Java people grew at a point in time which sparkled programming. Frameworks were few, competition was non-existent, and so people could grok frameworks even though they grew complex. The complexity was digestible since the users grew with the framework. Now Java folk are obsessed with their experience; unable to change their course they are lost. They realize that simplicity endangers them; they fight back with condescendence ("that thing is just a child's play, shoo away while we study The Real Thing TM"). It really shows when the person is also an ass.

The IT world has changed. There is so much of everything; the IT landscape is changing rapidly and there is no time to understand complex. Only the simple and usable will survive (consider this: when you pick up new library, you either discover how to use it within 1 minute or you move on). The worshippers of complex are growing old and diminishing. Students try to pick up Spring, grew disgusted with the complexity and go to node.js. Unless Spring reinvents itself, it will pass out with this generation of programmers.

Now to the practical stuff. You've probably started to see this message because somebody removed a library which implements JSR303 validations. Just add it back and you'll be fine:

compile("org.hibernate.validator:hibernate-validator:6.0.13.Final")
// EL is required: http://hibernate.org/validator/documentation/getting-started/
compile("org.glassfish:javax.el:3.0.1-b08")

That being said, I'm demoting the WARN message to INFO, and logging the stacktrace as DEBUG. I'll also add a FAQ section to the documentation fully documenting the validation stuff.

mvysny commented 5 years ago

Could you please review https://github.com/mvysny/vok-orm#validations whether it makes any sense?

I admit that the inclusion of JSR303 could be a bit hasty move; also it is annotation-based which is usually a smell. Yet I wanted to have validations on entity level; Vaadin provides JSR303 support out-of-the-box; JVM folk usually know JSR303; I couldn't find any sensible annotation-free validation library, and so I've picked JSR303 for now.

DALDEI commented 5 years ago

This works great ! Once I stepped down the 13 steps from my High Horse :) -- The real problem I had was that I had no clue what the necessary dependencies were, nor how to shut up the warning, nor any known need for it -- any 1 of the 3 would suffice :) Now I have all 3 -- well 2 of 3 -- don't need validation for this project but its a good thing to have. Tested with and without the dependencies cited and works fine.

FYI, I have no complaint at all about using JSR303 annotations -- they exist for a reason and are as far as I know the adopted set to use in such situations. I just didn't know how to either enable nor disable them -- so stuck in no-mans-land-hell of no bread or cake.

Additional docs are perfect, particularly " (don't worry it will not pull in Hibernate nor JPA)" -- seriously that's the first thing I think when give a jar that includes words like "hibernate" or "glassfish" ( "Oh No ... now whats THAT going to drag in now ... ")