by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Martin Vysny
    @mvysny
    Good luck :-D I've tried Ruby but dynamic languages aren't really my cup of tea. I guess it also goes the other way, it may be that your colleague will hate static typing
    Martin Vysny
    @mvysny
    6- looks like the problem is not sql2o per se, but the hibernate-validator, or rather it's dependency, org.glassfish:javax.el (expression language, used to 'interpolate' validation errors). It's also used by JSP which is included in every servlet container. So both WAR and Tomcat may contain the el.jar, and maybe T7's classpath isolation is not that strong. Long story short, either try to upgrade to T9, or get rid of hibernate-validator and javax.el
    David Lee
    @DALDEI
    suggestion on the later ?
    how to most easily remove the requirement to have validator referenced
    first inclination is fork the project and nuke all the places that use it
    But mayb eif I revert adding it in the first place -- which I did only to shut up the error message that happened when I didnt --
    now that thats not an 'error' anymore -- mightwork
    which circles back to why I tried to avoid tomcat in the first place :)
    ( its class loader is hell
    But your right, Intellij works quite well with it
    re: collegue - no he hates Javascript and dynamic lanagues -- but its the only way he found he was able to write a 'modern web app'
    David Lee
    @DALDEI
    myself, I have a goal 'in search of the holy grail' to find just the exact hybrid of static and dynamic -- which by my own terms is likely impossible :)

    e.g. with Kotlin - its close but I want to be able to define ONLY an interface and then 'derive' data classes from it withouth having to re-specify all the members
    you cant quite do that with either class or property delegation.

    So I cheated

    I have code using 'byte buddy' that generates an instance of a concrete class given an interface -- very close to java's Proxy implemenation, except it generates an actual class
    with properties, and works given non-interfaces (abstract or other) classes as well.

    In fact it works with simply a map of name/type
    which allows me to convert a jdbc ResultSet into a sequence of concrete classes without having pre-defined the class
    which in turn I give to vaadin -- where it can make Grid and forms etc using its default data binding
    without ever having to have pre-defined an interface or a class at runtime.

    Which means I just re-invented Groovy :(* :(

    David Lee
    @DALDEI
    'In Theory' (aka havnet wriiten it yet) works with json schema -- which in turn implies it works with swagger/openapi REST interfaces aquired at runtime
    But it doesnt (yet) give me what I really wanted -- an actual class at source/editing time that the IDE can type check and provide hints etc.
    So I can do somethig like 'val result = sql("select * .."); callSomeFunction(result.field1,result.field2) '
    and have 'result.field1' etc staticly typed
    For that I need some kind of kapt or other mechanism that does dynamic source or class generation while typing
    Martin Vysny
    @mvysny
    Karibu-DSL actually only depends on javax.validation:validation-api; it should be able to work without hibernate-validator and javax.el. So you only need to exclude hibernate-validator from your dependencies. If you're using Maven or Gradle, then simply use the dependency exclusion mechanism those two tools provide.
    I think that classloaders are built into every container, to allow WAR undeploy and classpath isolation. Of course all of that has been deprecated by docker since nobody is going to deploy more than one WAR into Tomcat these days. Yet there is a way - you can use Jetty and tell it to not to use classloaders at all. See https://github.com/mvysny/vaadin-on-kotlin/blob/master/vok-example-crud-jpa/src/test/kotlin/example/crud_jpa/Server.kt for an example on how to do that.
    Martin Vysny
    @mvysny
    Good work with the byte buddy idea :) I personally prefer to have actual entity classes to have proper auto-completion.
    Even though that means that I have to write them by hand. Or maybe you could generate those entity classes one time, then commit them to git?
    David Lee
    @DALDEI
    Morning/Afternoon !
    I was about to write you about the most painful waste of 24 hours I can remember for a LONG time -- (i.e. last time I tried to debug into tomcat ---) ARG -- that HURT.
    BUT -- now I get to write you about the most pleasant 10 minutes where I FINALLY GOT IT TO WORK
    by 3am (my time) I had finally given up all hope -- atleast for any app that even hints at thinking about MAYBE using el-api.jar or hibernate -- the 'DLL Hell' was hell.
    I tried probabably 100+ maybe more -- permiations of every thing I could think of and read even translating old google posts from russian, chineese, and some languages I didnt bother to even find out what -- and it was a viscious cycle of either class-not-found, war/exploded not build or deployed, early crash on startup, jar files being filtered by tomcat's 'for your own good' -- jvm, source, binary, and all imaginable incompatibilities, non-existance of reference libraries of prior versions claimed to work etc.
    David Lee
    @DALDEI
    But my non-vok-orm web project pretty much worked -- usually -- as long as I didnt touch anthing -- which pushed me further into oblivian knowing there MUST BE A WAY
    As yet 'one more last try' I actually followed your tutorial exactly -- including the exact tomcat version. (9something).
    I had tried with variations of 7 & 8 .. and the higher number I got the worse problems got -- so didnt try 9 -- yet
    this morning I downloaded from the apache site a fresh 9, unzipped it into a temp dir untouched (i.e. NOT installed via rpm or otherwise evern running a single installer or putting it anywhere 'expected')
    Deleted my .idea directory and re-imported the project from scratch taking all defaults.
    Setup a tomcat9 server -- with all defaults
    added the the Gradleexploded-war artifact (squinting hard while hitting OK because I have no clue where thats coming from -- its not any of the gradle tasks I know of )
    Clikced "debug" -- while at the same time getting ready to also type 'rm -rf' to avoid any further temptation to poke my eye with a sharp stick over and over
    Voila!
    Damn it ... makes sense though -- the TINY difference between 'It Just works whats the problem?' and "24 non-stop
    hours of torture later and still no progresss" --- is 'wafer thin'
    David Lee
    @DALDEI
    With an invisible infinately tall wall between the two such that if you are on one side you simply cannot imagine that there is another side -- let alone how to get tehre
    Anyway -- thanks !!!~! This is the FIRST time I've succeeded at debugging tomcat in any form whatsoever thats close to tollerable --
    with a bonus -- I got DCEVM working perfectly -- it takes seconds, not minutes, from source change to runtime -- a feat I had presumed relegated to HTML programmer's for eternitity.
    NOw to get those 24 hours (and a lifetime) back so I can catch up on my 'day job' before everyone else gets in :)
    As for 'real entity classes' in source -- I FULLY AGREE -- However -- always a 'but ... '
    There are many cases I work with (sometimes intentionally because they are interesting challenging problems) -- where it is either too tedious, error prone, or effectivey impossible
    To hand create and maintain 'proper' entity classes
    David Lee
    @DALDEI
    An example being runtime ad-hoc user-initated queries into arbitary data sources and services -- which may either not be known at author time (or sometimes even compile time),
    OR whos schema is partially or fully dynamic and/or determined by some form of introspection ( parsing the bodies of unknown web services , result sets from user defined data sources etc).
    Precisely the use case that the data binding in Vaadin implements -- from the perspective of the vaadin library authors (not the users). The presumption is that the user has 'in hand' already a concrete instance of a well-known (to them) class -- and that the library does not know of this beforehand.
    Extend that 1 or more dimensions -- to where the 'user' is in the same conceptial place -- where either the classes are unkown - or worse, do not exist (yet?) as actual distinct JVM classes .
    David Lee
    @DALDEI

    A differnt motivation -- it seriously pains me (becuase its 'SO CLOSE' ) that to implement certian types of APIs -- at minimum any class structure that uses an interface or abstract class --
    that one has to manually re-implement the exact same code over and over -- 'boilerplate' -- the sort of thing Kotlin strives to avoid -- yet doesnt quite ...
    interface A {
    val b : String
    }

    now if I want to every have an "A" I MUST re-implement every member one by one.
    class aA : A {
    override val b : String /// ARRRG -- DOUBLE ARG because I now need an initializer too !!!!
    }

    EVEN IF all I am doing is using a data binding library like Jackson
    val aaa : A = objectMapper.readValue<aA>( file)

    IF one has a very flat or simple set of classes its not bad -- data classes are great --
    data class A( val b: String )

    that even works with no initializer with jackson ( val a = objectMapper.read<A>(file) )

    But the second one needs variants or extensions ( particularly if in seperately compiled projects -- like a api impl + interface)
    as soon as you need any kind of class derivation the problem explodes --
    Even the wonderful class delegation -- REQUIRES BOTH an interface and a concrete class just to delegate yet a third class ...
    class X(a : A ) : A by a // Beautiful !!! EXCEPT

    you need now at minimum 2 classes fully and redundantly implemented, often more.
    interface A { ... blah }
    class aA : A { override every member AND at least 1 constructor AND provide all initializers }
    then usuually
    class bA: A { otherwise why are you using derivation ? unless you have atleast 1 variant }

    So now the beautiful 1 liner 'poster child' for all thats wonderful about Kotlin --
    is totally shattered into a mess and tossed on the floor (metaphorically )
    That is just so philosophically painful I cannot help but try to find a remedy -- something OTHER then 'spring' which brings too much its own pain :)

    So .. as a 'fascinating puzzle' -- I can now write code like this ( not quite perfect yet -- but satisfying even if I dont actually do it :)

    interface A { any number of members defined ONCE }

    ....

     val a : A = configure { 
            from( systemDefaults )
           from( userProvidedConfigFile )
          with(  optionalyProvidedMapOrObjectToFillInMissingBits )

    }

    done.
    or with the proper 'conventions' (i.e. vast amount of code ELSEWHERE :)
    val a = configure<A>{ with( appDefaults ) }
    editableForm<A>( a ) {
    title("Awesome Dynamicaly generated Form from Only an Inteface" )
    }

    .

    To mis-use a local expression "Now we're cooking with Gas!"
    David Lee
    @DALDEI

    The NEXT STep -- get the interface definition dynamically from some outside source -- like a openAPI spec, json/xml schema, introspection of a CSV file's headers --
    Or simply from a manually created interface
    At development time -- with IDE support.
    that boils down to some form of source (or .class ) generation in realtime as you author.

    A simple but painfuly illusive variant of this -- when you want a class that expoes val or var differently to differnt consumers. A common case is to AVOID the above magic configure( ) function and allow 'constructor like' syntax in source but on a immutable class.
    Essentially what the copy() method does -- but not limited to data classes or initial constructor calls -- taking a partially created object and adapting or completing it.
    Or simply where an internal /private class could make use of a 'var' in a type safe encapusualted way but only expose 'val' -- without having to implement parallel/redundant classes and a bunch of boilerplate copy code

    Enough ranting for the day !!! Im just on a 'super high' of finally getting BOTH the tomcat and hot-loading problems to work in a 'real world' case ..
    Wow.
    ( last example: the gradle kotlin-script (build.kts) is a great example of the kinds of use case and user-experience Im after -- that cannot be done in any straight-forward way )
    Martin Vysny
    @mvysny
    Glad to hear that Tomcat 9 works for you. I tend to download Java-related stuff instead of using package manager, since that could make couple of folders read-only (security), tiny dependency difference here and there, and it can make a ton of difference exactly as you experienced.
    Regarding the exploded war: perhaps Intellij adds its own task? Something along these lines: https://discuss.gradle.org/t/how-to-build-only-exploded-war-with-gradle/23168 . It always worked for me so I never gave it second thought :)
    Regarding aA - I think that designers deliberately avoided interfaces to have a state; but I don't remember the exact design reason. Another reason could be to stay compatible with Java.
    Karan Kumar
    @knjk04

    Hi,

    I got here by following a link on Karibu's GitHub page (https://github.com/mvysny/karibu-testing). Is this room also for Karibu testing?

    Martin Vysny
    @mvysny
    Hi, sure thing! How can I help?
    Karan Kumar
    @knjk04
    Thanks for your reply. I had some issues with getting Karibu to run at first, but I got it working in the end!
    Martin Vysny
    @mvysny
    Awesome, good to hear that! Sounds like the documentation might benefit from additional documentation.
    Could you describe what kind of troubles you had please?