Alex Lieb

Ranch Hand
+ Follow
since Jul 02, 2015
Alex likes ...
Netbeans IDE Notepad Java
Merit badge: grant badges
I'm 23, my favorite IDE is notepad, the most embarrassing thing I'm willing to admit in public is I don't know how to flip a bit with my bare hands, and I've been coding in SuperAssembly++  for 24 years.
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Alex Lieb

Marking resolved because in spite of how frustrating and dissatisfying the resolution is, I suppose it is now resolved...
Two reasons!

First, one of our shop's general coding style guidelines is to try to use the most basic, native, non-library-aided methodology possible in any given scenario. If there's no strict need to involve X Y or Z thing, tool, or utility, don't use that thing. Prefer over $("input[name='country']"). Almost all of the JavaScript on our site uses old notation and methodology. We have jQuery, but we only added it to our project because there were certain styling things we wanted to do that we could not do without using jQuery.

Second, I don't see a reason this code shouldn't work as is, and I don't want to just fix it by going around it. I'm afraid if I do that, since I do not understand the bug, it'll continue to crop up in unexpected ways in the future. Also this is the most JavaScript-intensive page on our site; about 2070 lines of JS go into making this page work, and if I fixed this by just using jQuery, I would have to rewrite almost all of that. The way this code is failing tells me that there's likely some solution that would live at the page-scope or request-scope level, and I think it'd be easier in the short term and better in the long term to find that solution.

I have a page that works just fine on Firefox and Chrome, but under certain circumstances it fails in IE.

How it fails:

When calling document.forms[2].<fieldName>, certain fields are returned as undefined. Not all of them, just some of them. Obviously they must have *something* in common, but so far I haven't been able to find a link. There's no correlation relating to load order, which JSP they belong to (This page is built using multiple includes), whether they're hidden/shown, id, name, value, or input type. However it is the same fields on every load.

I know the fields *are* present in the page though. If I run the following things in the console, for example, I would get these responses:

Say there's an input in the third page form and it's the... What the heck, the fifth field on the page, like this: <input type="hidden" name="country" value="Canada"/>

So... It's definitely *in there*; whatever method Javascript uses to find it by navigating the DOM is just failing.

When it fails:

Only for certain machines running IE11, only on this particular page, and only when trying to access the site running on our test server. So when I try to go to <ourtestserver>.com/blahpage, it fails; when I try to go to localhost:8080/blahpage, or <anyLocalAddress>:8080/blahpage, it works. Http vs https makes no difference. And I've tried this on uh.... At least 9 machines so far. It's failing for 2 of those machines, and is working on the other 7. So I'm really lost at this point, but somehow this bug has to lie at the cross section of these 3 factors:

The specific version of IE11 installed on one machine vs another.
Some difference between responses received from our test server and from a local host.
The page itself vs other pages on our site.

Has anyone else seen anything like this before, or can anyone offer any advice, hints, or at this point even complete guesses as to why this could be happening?

I'm trying to set up a new cloud server to run Glassfish applications. I've got our SSL certificate installed, I have Java 8 installed, I have Glassfish 4.1 installed, and Glassfish itself is starting up just fine, but it's failing to deploy the admin GUI.

There's a multi-exception stack that gets thrown in the domain log every time I try to start Glassfish, and it's long, but I think it all stems from it failing to initialize an instance of JceSecurityManager.

This is the full stack trace:

I'm not really sure what to make of all that except that something, somewhere, is having a really bad day trying to load up some classes it needs to handle SSL connections. I have the SSL certificate installed, but if I'm understanding this correctly, that should be a moot point at this juncture because it isn't even getting to the point where it tries to use a certificate because it isn't even loading all of the security classes.

When I try to load the admin GUI by going to <TheServer>:4848, it loads the page, but it never lets you actually log in; the status thing just has a little rotating circle next to it forever.

Based on the fact that the error is being thrown in the method "getConfiguredPermission", it seems possible that somehow Java is having issues finding or using some kind of configuration file, but I'm not sure how I would go about figuring out which files to look for. I have a suspicion that something may be set up wrong because I didn't just install Java 8 immediately; I installed Java 7, uninstalled Java 7, then installed Java 8. So I'll try reinstalling Java next, but I think the odds of that working are relatively low.

Has anyone seen this kind of issue before, and if so, does anyone know what's causing it to fail to load/instantiate those classes?
6 years ago

So I have some PDFs that I'm using in a web project; we've done this loads of times with a bunch of PDFs, but this is the first time I've run into an issue that we couldn't solve by either editing the PDF or forcing PDFBox to do a bunch of stuff to the files to get them to work. The PDFs in this project all come from different places; some of them are given to us by clients, some of them we built ourselves from scratch using PDFStudio 11, some of them we've been using for years and years and years, and they were originally .jasper files, but we've converted them into standard PDFs and built on them, and some, like the ones causing issues now, were originally Jasper files (I think?) and were converted (Again, I think?) using "iText by (r0.92)", which appears to have come out in 2002...

For some reason, the fonts embedded in these forms are Helvetica, Helvetica, Helvetica-Bold, and... Zapf-Dingbats. And Zapf-Dingbats is the only font with its encoding attribute listed as "built-in"... Every time I try to set a form field in this PDF using PDFBox, it says

> java.lang.IllegalArgumentException: U+0057 ('.notdef') is not available in this font's encoding: built-in (Type 1)

Or U+Whatever-Other-Character-It-Runs-Into, which is... You know, perfectly logical since the only font that gets loaded into the AcroForm by PDFBox is Zapf Dingbats.

I'm really not sure where this thing went wrong; when I first put this PDF together in PDFStudio and added the new form fields so we could use it in the new version of the site, it was working just fine, but for some reason now every time I save it in PDFStudio 11 it reverts all the fonts back to Zapf Dingbats, even if I change them. I have my preferences set to embed fonts, but it just really likes Zapf Dingbats for some reason. I suspect it has something to do with the PDF itself, and not PDFStudio, because we've been using PDFStudio for all our other PDFs and they've been working just fine. My suspicion is that I opened the PDFs to make some small change between now and ~1-2 months ago, and didn't realize that the fonts were messed up, so when it saved that way and became stuck that way, I didn't realize it immediately.

There's 4 PDFs which have this issue; they have about ~110, 80, 50, and 20 fields in them. I've tried optimizing it, and it appears to have just optimized it to have *better* Zapf Dingbats, if it made any changes at all, and I don't really have anything available to me to edit PDFs other than PDFStudio 11... PDFs and the PDF Specification are not really my strong suit; I can make the things from scratch pretty easily, but when I run up against configuration issues, resources/embedded file issues, or any other kind of document properties issues with existing PDFs, or PDFs with unusual formatting, I usually end up having to do a lot of googling, and it doesn't usually turn up many helpful results because I'm not familiar enough with how PDFs are constructed to know exactly which terms to look for. It would take some time to rebuild these by hand, but I would at least know what I was doing if I did it that way.

My question now is; is there any way to get it to stop reverting the fonts back to its favorite font in the world, Zapf Dingbats, and start embedding/using Helvetica (or anything else) again using the tools at hand, or would it potentially be easier to just take the background image out of the original converted PDF and rebuild the form itself from scratch?
I think we figured it out in a manner of sorts...

Our apache server or our ssl config or some weird magic internet machine working in the background; I forget which thing it is, is set up to invalidate sessions if they make certain types of requests over http instead of https? And the reason this issue shows up on test but not production is we still allow http requests on test. If you try to make an http request on production, it'll send you instead to wherever you were going, but over https. It doesn't *let* you use http. On our test site though, it does *let* you use http... Like, you're totally allowed, we're just, you know, going to invalidate your session every time you try to make a request that doesn't explicitly carry along the session ID in the request. Or something.

As you may have gathered by now, I am incredibly sketchy on the details. Partially because we fixed it yesterday and I forgot I asked this question on here until just now, and partially because although I did set up the apache server and tell it how to play nice with Tomcat on this particular domain I'm generally still kind of a noob in the world of port forwarding/SSL config/secure connection handling and all that jazz. I am not yet server-fu enough for that plane of enlightenment. The point is this won't impact how the site runs when we do push it to the production environment, and for the test environment we just have to remember to make sure our requests start with https://
7 years ago

I'm trying to deploy a new version of our work site thing on our test site, and I'm running into a bug that I have no idea how to account for.

Everything is working locally, so I deployed the project to our test site. I was able to log in  to the project just fine, and submit some forms, but the moment I followed any navigation path that didn't include a form submission, it would lose track of the session. Requests that included the session ID in the queryString were also able to go through just fine, but if you were to click on a link which had an href of, say, "", it would tell you your session was expired and kick you out.

So... I tried logging into the old version of the same project, which has been and is currently hosted on the same server, to see if that was happening there too. It was not. So I went back to the new version again and suddenly everything was working and it stopped losing track of the session. I had also changed a setting in some other random place while I was checking the old version to see if it had the bug too, so I figured whatever setting I'd changed had fixed it.

Then later on in the day, I rebooted the server and tried to log back into the new version of the site, and it did the exact same thing... Curious, I logged in to the old version, then closed the tab and logged back in to the new version, and once again, it stopped forgetting who I was. I would love to throw every config file in my project at you guys, because I'm aware that just a bland description of the issue isn't

There is something weird going on here. Somehow these two projects are still linked in the mind of the machine, and I'm not sure how or why. We're demo'ing this on Thursday, so I'd like to iron out most of the major bugs before then, but I do have a workaround that'll work for the moment. So it's not urgent, but if anyone knows why this might be happening or what I can do to fix the new version of the site so it works the same way the old one does, or if anyone knows why logging in to the *old* site would have any impact on the *new* site's ability to keep track of my session ID, that would be awesome.
7 years ago
I found it. Derp. Derp derp.. Derrrrrp. I feel bad for spending this much time on this.

I changed the names up, but what this boils down to is that hidden property up there should have been called "descriptionOfTheThing", not "theThing". The JS was treating theThing as if it had no options list because the first one it found *didn't* have an options list... Because it *wasn't* a dropdown selector.

So yeah. It's working now. I can't believe I didn't see that earlier. I realize that I probably could have avoided this kind of issue by... You know, not giving my variables names like "thing" and "thingDesc", but unfortunately I have to do it that way at the moment for reasons relating to a necessary discrepancy between labels and their values, and relating to the circumstances in which they're saved and reloaded on other pages.

Also it turns out the javascript I had initially was working just fine, even though on further review of it I'm seeing things that I feel *shouldn't* work, so I'm going to continue using that. I liked the jQuery thing, but it isn't noticeably faster, and the other possible benefit I could get would be improved code readability. I feel like the benefits in that area were mild... I'm going to keep using the old way for now because I know what it does, I know why and how it does it, and until I have a chance to fix it everywhere at once I'd rather not start changing it all piecemeal-like, but I'm thinking I will change that over to use jQuery one of these days.
Using 'i' as the index did not work. I did learn something though:

clearDropDown isn't working either, it just looks like it's working... But again, I'm confused because it *is* working in the other pages with lists built the exact same way.


I didn't realize you could use jQuery for this; thanks!

I now have this:

And it works now, but unfortunately I have less than zero understanding of *why* it works. And until I understand why it works, I'm not really going to be able to apply it freely in other situations, and I won't understand why I have to use this here and the other code is acceptable on our other site. Also this does append all the options to the list, but because clearDropdown is failing silently, it doesn't clear out old options, so you end up with that value=0 "---" still in the list after it populates, and if I were to select the year multiple times I'd end up with a never-ending frankenlist. I'd like to get rid of that, but I'm still not clear on why clearDropDown doesn't work on this page in the first place.
Derp. I meant to say this:

> It works because it doesn't try to call .length on selField.options

I'm trying to make a page update a dropdown using an ajax request. The idea is there's a few dropdowns in a row on this page where you don't know what the options for the next one will be until the previous one is selected.

I could solve this pretty easily by just submitting the page every time a dropdown is selected, but that would be cumbersome and inconvenient and more complicated than it should need to be. We would prefer to just make an ajax call when a dropdown is selected to get the items to put in the next list, then populate it in the onreadystatechange function.

I'm running into a strange bug though. Right now I have this as my onreadystatechange function: (Names changed for secret spy reasons)

There's multiple lists like the one above, and each one calls a function onchange that populates the options in the next one.

Soooo the issue is when you try to select the first one in the page I'm working on now, it has an issue with this:

> selField.options[selField.options.length] = oItem;

Because it says selField.options is undefined. I actually ran into  this exact same problem on an unrelated page a week ago or so and I realized that whenever the options list only had one item in it, it treated it as if it were NOT a list; so when you tried to get "options" from the field, it didn't find an options list and thought it was undefined. But I know it's still able to add options to the list because note: It doesn't have  *zero* options,  it has 1 option. The line that adds that option is in a different function, but it looks like this:

> selField[0] = new Option('---', '0');

It works because it doesn't try to call .options on selField; it just tells it "Hey, I want to set the first index"; so it doesn't throw a "selField.options is undefined" error, and so on and barf and so on... I know it's that the options object itself is undefined because I called on it in the console and it told me it was undefined there too, so the issue is technically with the .length part, since I'm making a call on an undefined object, but the root of the issue is that it thinks selField.options === undefined.

But this is the weird part to me: I did not have to deal with this on the other page, which is currently working. But I *did* have to deal with this on an unrelated dropdown-populating javascript function. It appears that these seemingly identical lists on different pages are having different behavior at different times for no apparent reason but that seems unlikely, which leads me to believe that there's a reason this is happening that I'm just not aware of; something to do with how arrays work in javascript, or how dropdown selectors work. What would cause javascript to treat a list with 1 option as a list in some cases and act like it's undefined in other cases?

For now I'm going to see if I can get it to work by using "i" as the array index in the options-population loop; it does appear to be able to add options to the list even if it says it's undefined when you call .length on it, which doesn't make sense if the object really is undefined, but I'm going to try it anyway and come back here in a bit with the results.
I'm having some issues here; I've got a page I'm working on that sends Ajax requests and updates the page with information from the responses.

The requests are sent in a particular order, but their response may or may not arrive in the same order. I need it to handle the responses in the order they were sent though.

I've been looking into Promises, and they look like they could be really useful! There's a few problems though:

1) I am not at all familiar with the different implementations, there appear to be many, many implementations, and they're all subtly or sometimes not-so-subtly different.

2) Native implementation is not supported by any versions of IE... Almost all of our users use IE.

Now our site already has jQuery loaded and on board and whatnot, so I can use stuff in the jQuery 1.9.1 library, but the closest thing to Promises they seem to have are Deferreds... Which I cannot make heads or tails of. They don't appear to work like promises exactly, and I can't get it to manually resolve the things; they seem to just decide they're resolved whenever they feel like it.

So my question is; is there a way I can get the behavior I'm looking for using just the stuff in the jQuery library, or am I going to have to get another library for this; and if so, do *any* of them work with Internet Explorer?
Duuuude... Coding is trippy.

I figured it out.

It goes back to this:

...I sidestepped some other steps entirely, but there's one database call that has an unfortunate combination of attributes: We *do* need it to happen, and we care about what it returns, and it sometimes takes a long time to execute.

So I realized there was only one thing it could possibly be doing in that time, since it's not connecting to a new datasource and it doesn't know it needs to connect to a new database yet. The only thing it was doing was getting a connection from the pool...

I looked up the connection pool behavior and found that it does NOT do look-ahead, but I was reminded of something that sent me in the right direction: the connection pool has to create and destroy connections as they're needed; most of the time when I'm just testing stuff by myself, I have the luxury of thinking of it as a single connection object that gets passed around, because I'm the only user using the project, so that's more or less how it *behaves*. But that isn't what the connection pool is; it stores a single Connection *Pool*, from which *multiple* connections are drawn, so if you ask it for a connection while one is in use, it has to make a new one, and from then on, unless it determines that there isn't enough activity to warrant having the second one around, it'll get rid of the second one.

Earlier on in the code, I decided to run a separate query in a separate thread because it was ok to run that query asynchronously. The method that runs that query is executed *directly* before the getImportantNumber method, so I figured it probably wasn't done running yet, so when it tried to run that query, it had to create a new connection and add it to the pool. So to test that, I told it to run the separate thread method 3 times instead of 1;

The first time it runs the separate thread query, it takes 0 milliseconds to get the connection.
The second time, it took 14 milliseconds to get the connection
The third time, it took 15 milliseconds to get the connection
And when it ran the importantNumber query after that, it also took 14 seconds to get the connection, and I couldn't find a way to log it and it goes by too fast to check in the debugger, but I'd be willing to bet that at that moment there were 4 Connections stored in the connection pool. So apparently it takes about 14-15 milliseconds to create a database connection and add it to the pool.

This also explains why the delay appears to only show up the first time you run that method; it's not about that method, it's about the current size of the connection pool and the threaded method that runs immediately before it. If I wait a while and let the connection pool decide it doesn't need all those connections any more, then try it again, it'll probably have that delay again the next time I call that method even if I don't restart the program.

Man, this stuff is just really cool...
7 years ago
Note: I was doing this all while connected to a database 8 states away, and I was under the impression that in production we would also have to deal with a database/project location separation like that for at least a few more months, but apparently I will not, so if I want to get a good approximation of how long a process would take on production I should actually be connected to my local database. So I did that. The query execution/response times are way lower now, but that spike the first time you run getImportantNumber is still evident, and I'm still curious about why.

The first time you call that method, it takes about 20-25 milliseconds to run "getConnection" and about 4-8 milliseconds to actually execute the query. This is interesting because it means the most important factor in both of these database interactions isn't execution time; it's transmission time. So for some reason it's deciding that this method's first call to getConnection, which should be identical to all the getConnection calls before it, needs to go through about 4 or 5 times as many request/response cycles with the database as you would need to execute a simple query. I feel like there *has* to be some kind of lookahead going on here...
7 years ago