Wake up and smell the java

So I have been trying to put together a design approach document for over a week. I have been struggling to articulate a difficult design concept. I was afraid it was getting too wordsy as it was running over 3 pages. With a mixed audience for the design review, it had to be crisp and not appear as rambling forever. I drafted and re-drafted over the week and knew that with an audience with an attention span of a 2 year old (or is it a 4 year old), I couldn’t get across what I was trying to say.

But with two hours to the meeting, clarity struck. I was replacing paragraphs with patterns, words were just flowing and I had it reduced to 1 page, bullet pointed and all with space to spare. The meeting did actually go well and people got what I was trying to say.  It’s funny how clarity always strikes at the nth hour. Just as the Zen master said.

Recent happenings in my app have led me to this epiphany: If something seems to be computationally impossible and it still seems to work or not work, chances are you are looking at the wrong piece of code. Hint: Log statements that should show and don’t, should be a clear indication of that. And yes I still hate debuggers and will not use them, unless I have to

I sometimes mistake one for the other. Of course a simple search on Google or wikipedia will clear this. But it doesn’t seem to stick with you, unless you understand, assimilate and put it in your own words. So here goes, for me authentication means, the authenticating entity (a server, for ex.) needs to know, that you are, who you say, you are (simplest mechanism: username/password). Authorization is the second stage to authentication: Ok, now I know you are ‘joeblack’ (you have been authenticated), so what are trying to do? what roles do you have (admin, user etc.)? Given your roles, can you do what you are trying to do? There, now I will never mix them up, hopefully.

So I am trying to automate an application A at work, that needs to talk to another system B(also j2ee based), via http. But system B does not expose its applications as services and also certain applications need a user to login. So here’s what I do, I decide to write a http client that will emulate a login on system B (it’s a jsp on system B), grab the session cookie and then call the protected servlet on System B. Sounds simple enough.

But looks like it was going to be a long evening. I call login.jsp on system B and look at the logs on system B, seems like system B liked the username and password and it was also passing back the session cookie to my http client. But the subsequent call to the servlet in system B was failing, due to invalid authentication. After spending a couple of hours trying to debug my http client, I realize that the login.jsp on System B is doing a http redirect (well the HTTP 302 code should have tipped me off), so even though I was using the correct username and password the authentication was failing. So I add setInstanceFollowRedirects(false) on the HttpURLConnection object and everything starts working.  I don’t really care about the content that login.jsp delivers, so my client does not need to redirect. There is also a setFollowRedirects(boolean) static method that works on the class, so use caution when using this method as opposed to the instance method.

That is my lesson for the day and I will stick my head out of the window for a blast of that chilly mid western breeze.

I can’t describe the kind of high I get when refactoring my own code and that too code that was only written a month ago. And when doing it to my own code, I can be as ruthless as I want to be, without coming off as a jerk or being too intrusive. Right now I can’t believe the kind of bloated code I wrote a month ago, I am reprimanding my self (the month old self) and patting my back (the current self), at the same time. Everything looks and feels so much better now, crisp and concise, each in it’s own little silo. So go ahead, don’t be bashful, refactor away, as many times as possible. You will realize how naiive you were just a few weeks ago. Ok I think I will stop now, sorry this is not exactly a technical kind of post. Just a feel good post, something I wanted to share.

…is non-existent. Sorry I let the title fool you. So, I have been working on this small project (struts, hibernate, mysql stack) on the side. No the project did not warrant the need of java, I could have hacked it in good ol’ perl/PHP/Python, take your pick. But the people(University of ..midwest) who wanted it done, thought java was cool and the help that I got, could only program in java (yes, this is the case mostly, you can hardly find programming language agnostic programmers these days). I digress, anyhow, the app was done, everything seemed to work on my trusty laptop. The demo went fine and the client asked to have it deployed. They left the hosting to me. Piece of cake huh! Hardly, I discovered. It’s the ‘E’ for enterprise in j2ee, it’s just not meant for shared web hosting, you are better off with dedicated servers and your own IS staff to maintain it. Most of the shared service providers will not give you your own java VM and/or tomcat/jboss/resin to play with, the security policy files are too restrictive(rightly so, it’s their server they don’t want you to muck around) and you will need to know all the libraries in your app that will need permissions (mostly by trial and error). The support staff are *nix demi-gods, most of them will reply promptly, even at unearthly hours(they need to get a life), but will draw a blank with any Java webapp help. All in all not a pleasant experience. Of course this has changed a bit now, there are some mature java webapp aware hosting providers out there, you can find them with a little googling. But it comes at a premium, not really helpful when you are on a budget. So if your project is small and you can get away with some simple scripting language-mysql magic, that can be hosted on the $19.99/month hosting service in the midwest, put your foot down, educate the client, stay away from java. Yeah, I know this piece of advice, coming from javafoo. But that’s how it is.

java.lang.ClassCastException
[java]     at org.hibernate.type.DateType.deepCopyNotNull(DateType.java)
[java]     at org.hibernate.type.NullableType.deepCopy(NullableType.java)

Does this look familiar. This happens when you define a java.util.Date field in the POJO and try to map it to a mysql ‘date’ datatype. This happens because a ‘date’ datatype represents only the date part and does not include the time part in mysql world, whereas java.util.Date is date+time. Although in Oracle and DB2 and probably other databases a date datatype is actually date+time. If the corresponding field is defined as a ‘datetime’ type in mysql then you should be fine. Also when using hibernate cfg doclet to create the database schemas do not explicitly say type=”date”, let reflection take care of it. Otherwise doclet will map it to date datatype for mysql, which will cause you this grief, leave it to doclet and it will correctly map it to datetime.

In this latest project of mine I was thinking about the various ways to map struts actions. I had done this, a couple of different ways and was wondering if there was a classification out there. And sure enough someone had already done this and instead of paraphrasing, I will just provide the link, here at TSS. Another thing/caveat about using named form-beans accross actions For ex, in your struts-config.xml, if you have a form-bean:

<form-bean name=”xyzForm” type=”package.web.XYZForm” />

and you want to use the same form accross two actions:

<action path=”/processAction” type=”package.web.action.ProcessAction”
parameter=”process”
name=”xyzForm” validate=”true”…..

<action path=”/displayAction” type=”package.web.action.DisplayAction”
parameter=”display”
name=”xyzForm” validate=”false”….

Notice here, I am using the same named form-bean for two actions, in the display action I don’t want to validate the form, but in the process action I want to validate the form. In this case I was in for a surprise, the validate=”true” wasn’t working for the process action. This is because the form params are set only once per form-bean. To overcome this, define two different named form-beans of the same type or if you still want to reuse the form-bean, set validate to true for both actions and within the validate method, based on a parameter decide if you want to validate or not.

So I was trying to capture a one-to-one relationship in Hibernate. I really started thinking about n-to-n relationships and how you can get confused as to where the foreign key goes. I came up with this thumb rule if you have a one-to-many or a many-to-one realtionship the foreign key column id always goes into the “many” end. For ex: I have a one-to-many relationship between Order and OrderLineItem. Since the OrderLineItem is the many end, it will end up holding the Order_id field. So what happens when there is a many-to-many relationship, in that case you have a link table which will hold the primary key ids of both the objects as foreign keys.

Going back to the one-to-one problem, the hibernate config task was not adding the foreign key id, so as a work around I changed it to many-to-one. When I found that it was already mentioned on the hibernate site:

There are two varieties of one-to-one association:

• primary key associations
• unique foreign key associations

So I had effectively done option 2.

Also when creating one-to-many relationships there is a caveat. I was running into constraint violations and found this on the hibernate site: “If the <key> column of a <one-to-many> association is declared NOT NULL, Hibernate may cause constraint violations when it creates or updates the association. To prevent this problem, you must use a bidirectional association with the many valued end (the set or bag) marked as inverse=”true”.” or do away with all foreign key constraints, I opted for the second option.

If only we spend more time on reading documentation. But there’s no better way than learning from mistakes and then struggling to solve them and finally solving them and then realizing that it was already documented.

That’s the way most of us started our first Java program.

Well I had a lot of “Hello World” moments with Java and seemed to be stuck in second gear for a couple of years. It was just something I had to know, since it was sort of the coolest thing since sliced bread. And friends and acquaintances who worked in Java technologies, looked down upon us lowly structured programming types. Then suddenly the company I worked for, decided to jump on the Java/J2EE bandwagon. All hell broke lose, there were rumours of downsizing us and only having a small maintenance team to manage the legacy system and employing new people to work on developing a new J2EE based system. There was downsizing, some of us were spared and even given an opportunity to upgrade ourselves. But there was a catch, there would be no formal training, we would have to prove our mettle by learning it on the job. So from ‘Hello World’, I was thrown at working on a full fledged J2EE system. I think that’s when we really learn and learn faster, under pressure. We were given step fatherly treatment for a while, the new J2EE kids on the block were the pampered ones. With the latest laptops, their xp programming, their uml diagrams and OO design patterns, we were in awe of these demi gods. But slowly, painfully things fell into place. A side effect of this was that there was not much time to really understand things or organize the knowledge.

Once the job pressure lightened or rather I learned to live with it, I decided to go to school for a Masters degree and I specialized in OOAD (Object Oriented Analysis and Design). That helped a lot, gave me mandatory study time and the project/homework helped me to take a step back and really learn things.

About last year I had started this blog: Common Knowledge in Java which was, sort of a naiive attempt to document a few notes, observations, gripes, struggles, musings and experiences in my trysts with developing Java/J2EE applications, going through interviews in that field etc. This may be common,trivial knowledge, but I just created it to sort of act as a repository for me. If someone else finds it useful, good for them. If someone wants to belittle this or thinks, “well this is sort of basic, you should already know that”, good for them too. But remember, consciously or unconsciously there are times when we do things without thinking and miss out on something really basic. So this is what I am hoping to do, document some eureka moments of mine.