Hey guys, I need wiser and more patient heads than my own to help me with a Java/JSP problem that keeps cropping up. I have openjdk8 installed (FreeBSD). I'm running tomcat8 like this, which is the default configuration installed by the tomcat package: /usr/local/bin/jsvc -java-home /usr/local/openjdk8 -server -user www -pidfile /var/run/tomcat8.pid -wait 30 -outfile /usr/local/apache-tomcat-8.0/logs/catalina.out -errfile &1 -classpath /usr/local/apache-tomcat-8.0/bin/bootstrap.jar:/usr/local/share/java/classes/commons-daemon.jar:/usr/local/apache-tomcat-8.0/bin/tomcat-juli.jar -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=/usr/local/apache-tomcat-8.0/conf/logging.properties -Djava.endorsed.dirs=/usr/local/apache-tomcat-8.0/endorsed -Dcatalina.home=/usr/local/apache-tomcat-8.0 -Dcatalina.base=/usr/local/apache-tomcat-8.0 -Djava.io.tmpdir=/usr/local/apache-tomcat-8.0/temp org.apache.catalina.startup.Bootstrap I have a JSP page with this in it: code:
code:
I hosed with this a little while ago and swapped out libraries and things and it mysteriously started working, but then last night it broke again (I suspect after I rebooted, implying that something changed in the tomcat startup parameters). Thing is, I don't have any idea where to look to see why it's not finding these libraries. I poke through /usr/local/openjdk8 and nothing looks familiar. People discussing problems like this seem to usually point to JAVA_HOME not being set properly, but I've got it set in my (root) environment, and -java-home is being specified in the tomcat startup options. Can someone please help me understand what's going on here? Thanks.
|
|
# ¿ Mar 9, 2015 14:05 |
|
|
# ¿ May 9, 2024 15:37 |
Here's a more focused demo of the above:code:
code:
code:
code:
|
|
# ¿ Mar 9, 2015 16:25 |
Yeah, I do need the graphics libs; I'm directly using stuff like ImageIcon. I'll check to see if there's a headless version that I installed by mistake or something. E: Not that I can tell. There's a /usr/local/openjdk8/jre/lib/amd64/libawt_headless.so in the install; I'm not sure what that tells me though.
|
|
# ¿ Mar 9, 2015 19:41 |
There are installable ports for openjdk8 (which includes a jre), and openjdk8-jre; I only had the former installed, now I'm trying the latter. Both have (in different places): code:
Tried running with -Djava.awt.headless=true too. E: And just to be clear: it only seems to be <c:> that fucks everything up. If I change this one particular <c:set> near the top of the file: <c:set var="basepath_local" value="${sessionScope.basepath}" scope="page" /> to <c:set var="basepath_local" scope="page" value="/usr/local/apache-tomcat-8.0/webapps/ROOT" /> Then it all works fine, including the ImageIcon calls and stuff that uses awt/swing. And it's not because of sessionScope; same thing happens if I use a variable from a different scope. Data Graham fucked around with this message at 20:03 on Mar 9, 2015 |
|
# ¿ Mar 9, 2015 19:56 |
Hokay. So what it seems to be doing is trying—and failing, for some unknown reason—to set a variable, but then afterwards whatever was causing the exception recovers its bearings and everything is fine. I had a <c:catch> around some input validation stuff a little further down the initial page I was working on, which was swallowing the java.awt exception and then allowing the rest of the script to proceed normally, including all the stuff using AWT. That's what was making debugging this thing so confusing. So here's what works, 100% of the time so far: code:
|
|
# ¿ Mar 9, 2015 20:43 |
It's not a servlet, just a plain old JSP. I've never done anything with servlets, and am pretty unclear on what goes into making one. I've been trying to hackishly try tomcat6 to check if that fix is to blame but can't get it running properly. The page in question is an image uploader. I'm setting various session variables and then calling this JSP via AJAX with a form post. Theoretically the session variables should all be available, and they are, but apparently when the JSP is first being initiated the first JSTL <c:set> tag that refers to an external variable triggers this weird "can't find java.awt" thing. Like, I can <c:set var="foo" value="bar" /> but not <c:set var="foo" value="${bar}" />. So this also works: code:
Data Graham fucked around with this message at 23:09 on Mar 9, 2015 |
|
# ¿ Mar 9, 2015 23:07 |
Aha, I see. Thanks, I'll try that.
|
|
# ¿ Mar 10, 2015 02:06 |
I apologize in advance for this. I wouldn't want my worst enemy to have to stare down the barrel of a keytool question. Trying to import a newly generated code signing cert from GoDaddy. The file is in .spc format, which I take to mean PKCS#7. I'm following these instructions, which people seem to be saying are good: https://support.godaddy.com/help/article/4780/java-code-signing-generating-a-csr But maybe they're written for a different version of java or something, because in steps 3 and 4, the -storepass option seems to require an argument in my version, but they seem to think you can just toss it in there without one. (If I leave it out, it prompts me for the password, which I prefer anyway.) But I keep getting this: code:
code:
I'm not sure what to do from here. Anyone wrestled with this one lately?
|
|
# ¿ Mar 10, 2015 22:09 |
Nah, it's in the right format; apparently GoDaddy always uses .spc for its files, which are in binary PKCS#7. Which you can clearly infer from their download page: Turns out I was using the wrong alias name, as I should have been able to figure out from the helpful exception message, I guess. (Also it seems openjdk has its own ideas about what kinds of options keytool should support, so you use -importcert instead of -import, but -import still works as an alias to -importcert, even though it isn't listed in the options) Data Graham fucked around with this message at 02:48 on Mar 11, 2015 |
|
# ¿ Mar 11, 2015 02:26 |
13 year old girls posted:I knew it was a good move posting here today. :iamafag:
|
|
# ¿ Mar 15, 2015 21:34 |
Leave little notes to your future self in your comments!
|
|
# ¿ Mar 24, 2015 01:02 |
Volguus posted:Maybe you're right, maybe I am a bad programmer. I have learned over the years to pick my battles, however. Always try to improve, always try to do the right thing, but look at your surroundings, look at what can you do and let some things go if you have to. Change them if you can on the fly, and if you hit a wall ... make your decision then if you want to continue or not. You are sounding like a stubborn little child who's not going to do his homework unless the exact amount of cake is present on the table. No more, no less. And throws a tantrum until the cake arrives on the table. Good luck, is all I can say. Principle #96: Don't pick your battles. Fight them all. Probably the single most contentious of these from when I worked there, and it sounds crazy, but the reasoning was that if you allow yourself to tolerate badness on a small level or in something that's only tangentially related to what you're doing, it feeds into lots of other adjacent aspects of what you do. A) it leads you into a mindset where you find it more acceptable to tolerate badness in other areas; B) it leads to you not "thinking like an owner" and to allowing poo poo to persist just because it's not your job; C) it sets a poor example for others, who will learn to accept that some stuff just sucks and isn't worth improving. Of course not every place is a crazy meritocracy cult, so yeah, you do what you gotta do.
|
|
# ¿ Mar 27, 2015 03:10 |
How I wish they cold come up with normal names for things, like "propagate" or something.
|
|
# ¿ Sep 5, 2015 00:31 |
"While I'm at it I'll just fix this bug" The burned hand teaches best.
|
|
# ¿ Sep 30, 2015 23:55 |
Elias_Maluco posted:Its funny to think javscript and java share the "java" word, considering that JS is the complete opposite when it comes to OOP features, variable types and stuff. More "maddening" than "funny". Literally the only reason it's called JavaScript instead of ECMAScript or LiveScript whatever is that some bright bulb at Netscape decided that because they were shipping the hot new version 2.0 with a Java runtime, the new in-page scripting language Brendan Eich wrote should be co-branded with it.
|
|
# ¿ Nov 2, 2015 02:58 |
Squashy Nipples posted:Also, I'm a big fan of the Sams Teach-yourself books. The "Java in 24 Hours" starts off REALLY slow if you already know how to program (it doesn't get into Objects until chapter 10!!!), but it gave me a lot of contextual information about how Java is used, and how it's evolved. Sweet, glad to hear you like those
|
|
# ¿ Nov 16, 2015 19:33 |
Rather not say for reasons, but I wrote a couple and tech edited several others. No Java ones though.
|
|
# ¿ Nov 16, 2015 22:32 |
I'm still maintaining a massive site that I built all in Perl CGIs in the late 90s. I'm like three generations of MVC structure ahead in my day job and new projects, but part of me likes keeping the old poo poo around just to remind me how good we have it now.
|
|
# ¿ Jan 21, 2016 14:33 |
Put some more prints in so you can see which loop it's getting stuck in and why.
|
|
# ¿ Sep 8, 2016 22:09 |
So when does x change?
|
|
# ¿ Sep 8, 2016 23:14 |
'Scool, that's why this was a valuable exercise
|
|
# ¿ Sep 9, 2016 01:45 |
Such as not using java? I actually don't mean that to sound snarky. I'm really wondering: what are the benefits of using Java for web dev, when there are plenty of other stacks available that don't require you to muck around with IDEs or roll your own DAOs? Is the performance benefit that significant? Or is it all about scale, for maintainability of large codebases?
|
|
# ¿ Oct 9, 2016 22:02 |
For web it's always seemed way more straightforward For editing code on remote servers and all. I'm happy to use an IDE for stuff like iOS, where it's clearly necessary, but it seems like huge overkill for webdev.
|
|
# ¿ Oct 10, 2016 15:52 |
Well yes, that's how I normally work for any project with significant size. I've just never seemed to need anything more than basic syntax coloring for most stuff, and dependencies don't tend to be much of an issue with sandboxed environments and such. My happy place these days is Django, but I've built JSP sites and lots of other stuff back to the days of Catalyst and raw Perl and poo poo. At the very least I can agree that JSP's idea of template/scriptlet separation is a horrorshow, but I'm glad there are better ways nowadays that don't mean "you have to write three big boilerplatey class files for every model".
|
|
# ¿ Oct 10, 2016 16:20 |
I suppose front-to-back or back-to-front depends on how bigendian you are
Data Graham fucked around with this message at 20:28 on Oct 12, 2016 |
|
# ¿ Oct 12, 2016 20:25 |
Sometimes fate just has it in for you. "release" is a keyword now, but it wasn't back when I first designed the system
|
|
# ¿ Nov 16, 2016 00:33 |
In my experience, and I may be completely misunderstanding how it works, but I've spent years trying to make my way through the impenetrable fog of 15-year-old documentation and incoherent developer forum posts, and would love to be corrected, but... JSP tells you to do database operations and queries in the templating language (EL), i.e. <sql:query> . Which is fine if you just want to do simple queries and loop through the results and spit them out into HTML. But the moment you try to do anything more complex, like I dunno doing some math operations on your query results, or formatting strings, or doing file manipulations, you have to pass that data into the scriptlet space (<% %>). Which is a completely separate world from the EL layer, with its own namespace and its own context and its own everything. And never the twain shall meet. You can't pass complex variables (like query result rows) to or from scriptlets. The best you can do is read attributes from the pageContext and set them back as attributes into the pageContext after you're done with your scriptlet, which makes for insanely clunky and repetitious code. Or at least I've found no simple way to do it; you have to cast and prep and attribute-pass every individual value separately. People writing how-tos always say you're never supposed to do any serious complex code in scriptlets; you're supposed to write beans and build DAOs and stuff to feed the templates from the back-end. Which is great, that's how I'd much rather do it, if it weren't a massive amount of code to write in itself. But JSP is very insistent that you do your <sql:query> stuff in the EL layer, not in the back-end. So basically there are two competing philosophies battling it out: simple query magic in the EL template, and full-fledged DAO modeling in the Java layer. And JSP doesn't help you out at all if you're doing the latter; you're basically starting from scratch and may as well use some other MVC framework like Struts or something and forget about the EL templating stuff entirely. Again, I could be completely missing some huge major piece of the puzzle. But I've been fighting with JSP for one project of mine for years now and it makes me weep every time I want to do something as simple as write my gently massaged query results to a logfile, and I cannot believe anyone would want anyone to go through it the way I have, though for the life of me that's the only conclusion I can draw from the docs/community.
|
|
# ¿ Jan 22, 2017 05:06 |
Looks like a mixin to me.
|
|
# ¿ Feb 1, 2017 12:54 |
Database, that's like a spreadsheet right ??
|
|
# ¿ Apr 10, 2017 13:34 |
Volguus posted:No, providing options is generally good. No, it does not have to increase the level of technical expertise to use your product. It can, and yes there are horror stories from the 90s software that have gone too far, but it doesn't have to. Removing options is simply an effect of laziness and nothing else disguised under "user friendliness". There is absolutely nothing "friendly" to the user if I dictate how my product should be used. There is 100% friendly if I provide sane defaults and allow the user to customize if/when they feel like it. And is perfectly ok if that "when" is never. I sure didn't have enough of this argument circa 1997.
|
|
# ¿ May 17, 2018 13:33 |
Yeah PyCharm's got some goofy-rear end ideas of how keybindings and such are supposed to work in macOS. Scrolling and searching in the Terminal pane feels like I'm having a bad dream where I scream but nothing comes out and every button I try to press gets further and further away
|
|
# ¿ May 10, 2021 23:08 |
chippy posted:That seems to be the thing that people try to do themselves an alarming amount of the time. I worked on a website once that the client had built a good amount of themselves, including some home-rolled crypto and they wouldn't let me touch it. Who among us has not had this experience. Some dunning-kruger enthusiast writing his own ColdFusion password hashing algo that is "secure" because it calls a series of obscurely-named functions in various different files named after characters from his favorite book so it will be impossible for a hacker to untangle "Don't use a standard crypto library, that's just what they'd be expecting"
|
|
# ¿ Mar 4, 2022 04:54 |
|
|
# ¿ May 9, 2024 15:37 |
Still pisses me off. What a dumb rear end in a top hat move
|
|
# ¿ Jul 11, 2023 03:12 |