Info

Login

Channels

APIs

Credits

  • cheeser
  • ernimril
  • joed
  • kinabalu
  • lunk
  • ojacobson
  • r0bby
  • ThaDon
  • ricky_clarkson
  • topriddy

« 2019-06-12

2019-06-13

2019-06-14 »

Nick Message Date
acidjnk [acidjnk!~acid@mue-88-130-58-035.dsl.tropolys.de] has joined #glassfish [01:47]
poikilotherm [poikilotherm!~poikiloth@zb0011.zb.kfa-juelich.de] has joined #glassfish [04:03]
skakelaar [skakelaar!~skakelaar@160.48.234.77] has joined #glassfish [09:27]
skakelaar Can anyone tell me if MQ8 will run with Glassfish 3? [09:27]
pdurbin Glassfish 3 is pretty old. I'm sure you know this. But at least Oracle used to support it. Maybe they still do. I don't know. [09:42]
skakelaar Some 3rd party Payara took over [09:44]
skakelaar All Application Servers that support the Java EE 7.0 specification - GF supports up to Java EE 6... so hard NO [09:45]
acidjnk [acidjnk!~acid@mue-88-130-58-035.dsl.tropolys.de] has joined #glassfish [10:47]
whartung What?s MQ 8? [01:08]
pdurbin Maybe it's this: https://en.wikipedia.org/wiki/IBM_MQ [01:53]
_Tenchi_ Java and JEE didn't stop garunteeing backward compat until recently [02:27]
_Tenchi_ MQ8 should run with JEE6 or JEE7 [02:28]
_Tenchi_ i'm actually baffled by how good the backward compatibility actually was haha [02:29]
_Tenchi_ i have one final project deployed on glassfish3 that i'll be moving to jee8 soon... it'll be interesting to see how much needs to be changed to get it to work [02:30]
_Tenchi_ moving stuff from v3 to v4 was surprisingly easy... only problems i ran into were actual regressions in the subcomponents of gfv4 [02:31]
_Tenchi_ not compatibility issues... just plain bugs [02:31]
pdurbin Cool but 4 to 5 is killing me. :) [02:33]
pdurbin Did we talk about http://balusc.omnifaces.org/2015/10/the-empty-string-madness.html ? [02:36]
whartung looks lovely pdurbin [02:39]
pdurbin ) [02:40]
_Tenchi_ the empty string stuff has been a problem since the dawn of http haha [02:45]
_Tenchi_ the fact that it was never specified anywhere how applications must interpret it left a HUGE chasm that we're paying for all these years later [02:46]
_Tenchi_ in the dataverse case, i think you've allowed it to go a step further and relied upon primitive autoboxing and string-to-numeric-primtive things to make things even worse [02:47]
_Tenchi_ but i remember back in the late 90s and early 2000s having scripts as part of the build process that would scan through php code to look for places where developers had not conformed to the standardized interpretation rules of the empty string stuff [02:48]
_Tenchi_ the problems were so difficult to find after the fact, and even more difficult to fix retroactively, it was worth the trouble to set the standards ahead of time and validate compliance [02:49]
_Tenchi_ we didn't have the refactoring tools back then that we do now ;) [02:49]
pdurbin yeah [02:51]
pdurbin I tried to prove that INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL=true isn't working in our app on Glassfish 4.1 this morning but I couldn't. I'm probably testing it wrong. [02:54]
_Tenchi_ the problem with that setting is that it's global for the entire webapp [02:55]
_Tenchi_ it's highly probably that you have some places that assume empty string is an empty string or a numeric value of 0 [02:55]
_Tenchi_ so you change the value of that setting and probably break a few things that you're not immediately aware of [02:56]
_Tenchi_ and if you have multiple webapps, you have to make sure that value is the same across all of them if they share components and stuff [02:56]
pdurbin Just one webapp deployed to Glassfish for us. [02:56]
_Tenchi_ what you really need to do is decide on which setting is best, and then change all code to work with it [02:57]
pdurbin I just printed out that blog post. 4 pages. [02:57]
_Tenchi_ that balusc blog post? hahaha [02:57]
_Tenchi_ the take away from that post is that since you only run on glassfish you're better off than had you been running on multiple containers [02:58]
_Tenchi_ despite all the headache, you should feel lucky lol [02:58]
pdurbin ) [03:01]
_Tenchi_ regarding testing though... at some point you'd probably do well to build a thorough test harness for all your stuff... one that can be maintained over time [03:03]
_Tenchi_ the rate at which JEE and stuff is going to be changing now, you're going to be in a touch spot if you don't have a way to test [03:04]
pdurbin Yes, I recently stood up https://jenkins.dataverse.org which is why it's such a mess. :) [03:04]
pdurbin That's actually the other thing I'm doing right now. Trying to get our tests to run reliably in docker. It's weird. On the first run it's fine but on the second run I start getting 500 responses from Glassfish. I don't know why. [03:05]
_Tenchi_ i remember glassfish having problems with redeploying... so many problems that i'd always trust a deploy from scratch over a redeploy [03:06]
_Tenchi_ I wouldn't re-use a docker instance and redeploy into it... i'd rebuild the image with the new war and run a new container with new image every time [03:07]
pdurbin That's what we do. docker rm at the start of every run. Then spin up a new container. [03:07]
_Tenchi_ good [03:08]
_Tenchi_ and jenkins runs inside a container, or jenkins coordinates build the docker image and launching a container from that new image ? [03:08]
pdurbin The latter. [03:08]
_Tenchi_ ah ok... i see a lot of people trying to get the former to work but i've never tried [03:09]
_Tenchi_ requires running docker within docker which can be done, but needs to goofy bind mounting stuff or something [03:09]
_Tenchi_ maybe that's no longer required since docker can talk ssh now but that's only recent [03:09]
pdurbin Here's where we spin up a docker image: https://github.com/IQSS/dataverse-jenkins/blob/ad6a20e64eb7bcabf1e9593d6a0566a973667373/IQSS-dataverse-api-test-suite-docker-aio-develop.xml#L45 [03:09]
pdurbin pdurbin's title: "dataverse-jenkins/IQSS-dataverse-api-test-suite-docker-aio-develop.xml at ad6a20e64eb7bcabf1e9593d6a0566a973667373 IQSS/dataverse-jenkins GitHub" [03:09]
whartung yea it?s kind of sad that you have to kill the container to redeploy, or jump through something as coarse as a docker thing to do it. [03:52]
_Tenchi_ you dont necessarily have to kill the container to redeploy, but I consider it a best practice... and to be fair, it's not so coarse [03:55]
_Tenchi_ definitely less coarse than deploying into a VM kind of thing [03:56]
whartung for production we redeploy and then restart. For dev, I only typically restart when ?permgen? is full from too many redeploys (though that hasn?t happened oftern with Java 8, of course) [03:56]
whartung sometimes I?d like to be able to kill the container, and ?undeploy? without the container being up (i.e. just hack the domain.xml). But I?ve never hunted down what else I need to clear out to properly ?undeploy? that way. [03:57]
_Tenchi_ yeah i've always wanted a definitive way of doing that too... totally separate from the context of containers or operating environment [04:00]
_Tenchi_ you can use a docker container the same way you use a vm... provision (run), stop, start again, deploy new artifacts into it, etc... but that's not ideal [04:01]
whartung in tomcat you can do that (I think), since you can ?deploy? via an external context.xml ? your code can be in an entirely different place than the container. That said, I think that can happen with GF do, but it?s underdocumented as to how. I?m pretty sure you can deploy from an exploded EAR directory and it will use it in place. [04:01]
_Tenchi_ it might be the case that you can do it in glassfish too, i just dont know if it's garunteed to work [04:02]
_Tenchi_ it seems to work, but i dont know if it can be relied upon haha [04:02]
whartung because if you can do that, you can just ?build to the directory? kill GF and restart it [04:02]
whartung be nice to deploy from the maven target directory [04:02]
whartung a restart has to be faster than a redeploy, if nothing else it saves a copy step [04:03]
_Tenchi_ well, that's kind of how i do it [04:03]
_Tenchi_ i have maven being run as part of the docker image build [04:03]
whartung but do you deploy an EAR file in the end? [04:03]
_Tenchi_ yeah war or ear [04:03]
whartung yea I?m talking a pre-expanded directory [04:04]
_Tenchi_ and it's not "the end" [04:04]
_Tenchi_ no, i dont use pre-expanded, though it probably would be better [04:04]
_Tenchi_ but workflow-wise it would be the same [04:04]
_Tenchi_ building the docker image would include invoking maven to do the build of the artifact... and then the resulting artifact is included into the docker image [04:05]
whartung here it is: asadmin deploydir [04:05]
whartung yea, see, mount the deploy dir ?remotely? in the docker container [04:05]
whartung (I think you can do that) [04:05]
_Tenchi_ yeah, you can do that, but i just incorprate it directly into the image [04:06]
_Tenchi_ the thing about docker images is that they're fine-grained [04:06]
_Tenchi_ they're layered, so build an image just pulls the most recent from the cache and changes the files that are different for the new image [04:07]
_Tenchi_ i use war/ear so the entire war/ear is always different resulting in a longer build time... but using an expanded version would speed things up as only the changed files would need to be incorporated [04:08]
_Tenchi_ but my builds are already fast enough, so i'll just leave that as a later optimization that i haven't had a need for yet [04:08]
_Tenchi_ and the bulk of the time used in building the docker image is the maven process [04:09]
_Tenchi_ everything else is cached [04:09]
_Tenchi_ the docker run command is not much more than waiting for the appserver to fire up and deploy the app [04:09]
_Tenchi_ but all the other stuff like the appserver configuration, health checking scripts, exrtra debug or profling agents, all that stuff can be incorporated into the same build flow... it's very nice [04:10]
_Tenchi_ most of the classic pissing around with keeping configuration maagement modular and syncronized goes away [04:11]
_Tenchi_ but the fine-grained layering/caching of the images is a huge benefit for tight iterations during development [04:12]
_Tenchi_ and reverting back to previous states is instantaneous :D [04:12]
whartung the build and deploy cycle takes sevearl minutes for me, without running the tests. [04:15]
_Tenchi_ maven and appserver deployment? or building docker images? [04:20]
_Tenchi_ not sure why you'd have so much overhead in building docker images, but maybe your not doing it correctly or there's something in there very early on that keeps the image build from hitting cache or something like that [04:21]
_Tenchi_ i've seen a lot of shops treating docker more like VM hypervisor technology than thin container tech, and they don't realize what they're missing out on [04:22]
_Tenchi_ usually it's when they've kind of adopted more modern containerization stuff but aren't all-in yet and need to retain various levels of backward compatibility [04:22]
_Tenchi_ haha most often i see this in shops where they're just waiting for the ancient sysadmin to retire before killing off the legacy backwards compatibility workflows hahahaha [04:23]
jelmd [jelmd!~purple@92.117.63.147] has joined #glassfish [04:27]
pdurbin Maybe he'll take the Sun pizza boxes with him. [04:46]
_Tenchi_ yeah those pizza boxes were neckbeard compliant but not hipster compliant [04:54]
_Tenchi_ ok good news... with v6.8.0 and highlevel rest api, i'm seeing speeds back down to 18ms [05:17]
_Tenchi_ woops [05:18]
whartung no I don?t yse docker [05:26]
whartung just to compile, build, and deploy [05:26]
whartung my EAR is 1.3G [05:29]
_Tenchi_ wow [05:42]
whartung Doesn?t everyone bundle Scala and Clojure in their EAR?? [05:43]
whartung O.o [05:43]
_Tenchi_ haha [05:43]
whartung our Lib POM has 800 java files in it. (our app is basically: app-ejb, app-lib, app-war ? our -lib has 800 files in it [05:45]
whartung I know I know, ?2 whole minutes to build!!!!!? [05:45]
whartung yea, well, it?s not the 80?s. and it?s the smae whether it?s a simple code change or the entire thing, since we ?clean install? like everyone else. [05:46]
whartung better to suffer through it than fight the weird stuff that happens when you don't. [05:46]
_Tenchi_ yep, i totally underdtand [05:57]
_Tenchi_ understand* [05:57]
_Tenchi_ 2 min is a nice window for bio breaks and coffee refills [06:00]
pdurbin whartung: do you really have Scala and Clojure in your EAR? [06:04]
whartung another project has clojure, but we do bundle scala and groovy! >.< [06:06]
whartung it?s awseome: scala, groovy, jersey(!), axis(!!), spring(!!!), struts (!!!!), velocity (twice! lol), jackson AND gson? [06:09]
whartung good times [06:09]
whartung oh look, guice too! Spring, Guice, CDI ? good to have all the bases covered. [06:10]
whartung we rely on a common library shared within the company, so we have a lot of detritus dragged with us [06:10]
_Tenchi_ sounds like you have a few <scope>provided</scope> tags missing from your build haha [06:13]
whartung well, we need to add exceptions. We load the common-lib, it drags in the internet. [06:19]
pdurbin I keep thinking I should try out Clojure. [06:39]
whartung have you done any lisp in the past? [06:44]
pdurbin nope [06:45]
whartung I geuss it?s as good as any to start with, I?ve neve rused it myself. [06:45]
whartung clojure that is [06:45]
whartung I like lisp, though. it?s neat. [06:46]
pdurbin Have you used Common Lisp? [06:47]
whartung but ya know what? when 90% of what you do is CRUD, mapping these 100 fields to those 100 fields, and reporting? it really doesn? tmuch matter what language you use ? they?re all equally tedious. [06:47]
whartung yea [06:47]
whartung I have infamy in the CL community even! [06:47]
pdurbin do tell [06:48]
whartung https://www.reddit.com/r/programming/comments/uhse/guerilla_lisp_the_opus/ [06:50]
pdurbin bookmarks it [06:52]
pdurbin whartung: really nice story [08:07]
jdlee [jdlee!~quassel@45-24-178-181.lightspeed.okcbok.sbcglobal.net] has joined #glassfish [09:16]
jdlee [jdlee!~quassel@unaffiliated/littlezoper] has joined #glassfish [09:16]
_Tenchi_ [_Tenchi_!~phil@d-207-255-80-203.paw.cpe.atlanticbb.net] has joined #glassfish [11:38]