Good java/j2ee app shared hosting December 19, 2006
Posted by javafoo in hibernate, java, java hosting, javanotes, struts basic.1 comment so far
…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.
hibernate mysql date ClassCastException September 27, 2006
Posted by javafoo in hibernate, javanotes, mysql.1 comment so far
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.
Capturing n-to-n relationships, Hibernate etc. September 18, 2006
Posted by javafoo in ER - Entity Relationship, OOAD, hibernate, javanotes.add a comment
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. 
