joshskeen.com

On the project I'm on, I have to develop against a slightly older version of Jboss (5.1.0 GA specifically), which comes with out-of-date libraries for hibernate and jpa. After some tweaking I found the following steps would let me package my own jars and override the jboss classloader. Nowhere could I find this clearly documented on the jboss website - so I hope this helps save someone some time!
1) I added this code to my app

log.info("hibernate version :: " + org.hibernate.cfg.Environment.VERSION);

running it gives:

09:31:27,923 INFO  [EspUser] hibernate version :: 3.3.1.GA

2) i removed

hibernate-annotations.jar
hibernate-commons-annotations.jar
hibernate-core.jar (3.3.1)
hibernate-entitymanager.jar
hibernate-jpa-2.0-api-1.0.0.Final.jar

from my buildpath and lib directory. the lib directory in my project holds all the jars my project needs to reference, but are currently included with jboss.
3) I added

hibernate-commons-annotations-4.0.1.Final.jar
hibernate-core-4.1.0.Final.jar
hibernate-entitymanager-4.1.0.Final.jar
hibernate-jpa-2.0-api-1.0.1.Final.jar

to war/web-inf/lib & to my buildpath
4) I added a new file, war/web-inf/jboss-classloading.xml. here are the contents:

<?xml version="1.0" encoding="UTF-8"?>
<classloading xmlns="urn:jboss:classloading:1.0"
             export-all="NON_EMPTY"
             import-all="true"
             parent-first="false">
</classloading>

5) the old code at step 1) needs to be updated to: log.info("hibernate version :: " + org.hibernate.Version.getVersionString()); since hibernates api between 3 and 4 apparently changed

6) stop and restart jboss completetly and then run - the code now gives:

12:14:54,658 INFO  [EspUser] hibernate version :: 4.1.0.Final

7) victory!

In GWT, to fire an event on an element and trigger your change handlers you may have setup do:

DomEvent.fireNativeEvent(Document.get().createChangeEvent(), inclusionCriteriaSelect);

This way, any UI logic you've set up on form elements that are event driven can be reused.

It seems to me unintuitive to have things floating around = to null but able to call methods. for example:

class Foo{ 
static void doStuff(){ } 
}
Foo foo = null;
foo.doStuff(); //works

The fact that though foo is null and is invoking a static method makes sense when carefully considered, but reduces the clarity of code when trying to understand large amounts of it at once.. this leads to increasing confusion as the system becomes more complex! This gets even more confusing when the relationship between the Type of null and the relationship of its static methods becomes more complex. for example:

 public class Foo {
   static int fubar = 42;
   Foo getFoo() {
     return null; 
   }
   public static void main(String args[]) {
   Foo foo = new Foo();
   System.out.println(foo.getFoo().fubar);
  }
}
// output : 42

c# on the other hand takes the approach of disallowing the calling of static methods on class instances. this intuitively seems easier to understand.
Update - Eclipse can be configured to trigger warnings for "indirect access to static members" under Java > Compiler > Errors/Warnings.

A rails 3.0 web storefront for my art glass side business, skeenglass.com Uses sammy.js for the frontend, and Google checkout integration for the CC processing gateway. Deployed on heroku for extra cool-points. Source-code available here for the curious :P

If you've run into an issue where GWT loads the DateBox component and incorrectly sets the start day to something strange (I was getting Monday, rather than the correct Sunday start day), the problem is a bit vexing and the solution isn't obvious at first. There's no way to change the start using the DateBox api - instead, it's actually tied to the application's il8n/locale settings.

After watching the first video in the lecture series "MIT 6.046J / 18.410J Introduction to Algorithms", I took a crack at writing an implementation of the insertion sort algorithm the professor described.