WebSphere Portal error - "Puma requested entity type Group from VMM but received Entity"

Got this error when trying to upgrade from WebSphere Portal 6.0 to 7.0.

com.ibm.portal.puma.SchemaViolationException: EJPSG0053E: Puma requested entity type Group from VMM but received Entity.

This sets a record for one of the most unhelpful errors ever. It can be caused by a bad entry in LDAP - in my particular case, it was a few groups whose objectClasses (groupOfUniqueNames and top) had somehow been saved with base-64 encoding instead of as plain text, although the values themselves when decoded were correct. The same exact LDAP directory was also working fine with WebSphere 6.0.

One of IBM's pages implies that the configuration itself is broken - when in my case, the configuration was perfectly fine and the problem was a bad entry in LDAP. The error gives no help tracking down the broken entry.

https://www-304.ibm.com/support/docview.wss?uid=swg21419580

Other IBM resources imply that the specific configuration issue is making sure that the group and user LDAP object classes are unique - i.e., don't use "top". In my case, I was doing pretty standard stuff - groupOfUniqueNames and inetOrgPerson.

http://publib.boulder.ibm.com/infocenter/wpzosdoc/v6r1/index.jsp?topic=/com.ibm.wp.msg.doc/messages/com.ibm.wps.puma.resources.Messages.html

https://www-304.ibm.com/support/docview.wss?uid=swg1PK80507

Javascript, getYear and cookie expiration

Chrome and Firefox both return an offset from 1900 for date.getYear() instead of a four-digit year (pre-Y2K, a two-digit year). So new Date().getYear() returns 111 instead of 2011.

Old news, right? Well, I've been getting away with this for a while and not realizing it, in logic to expire cookies, and didn't notice until switching to Chrome.

The cookie expiration function was something like this

Date d = new Date();
d.setYear(d.getYear() - 1); // last year = 110
document.cookie = "COOKIE_NAME=; expires=" + d.toGMTString();

Firefox was happily setting the cookie's expiration to the year 0110, which was wrong but still accomplishing the end goal of expiring the cookie.

Chrome, on the other hand, mangled toGMTString to only print the three digits "110" and was not interpreting the cookie as expired.

Of course, the better question is why write this code yourself anyway, when jQuery, Dojo, etc., all have their own cookie APIs.

Javascript associative array and iteration order

I just noticed that some browsers, like IE9 and Chrome, don't preserve insertion order of keys when iterating with a for-in loop ["for (key in array)"]. Although technically Javascript never guaranteed preserving order in a for-in loop, so many popular browsers did anyway that I was taken by surprise.

The Chrome behavior is especially odd - it preserves order of insertion for non-numeric keys, but iterates numeric keys in numeric order first. It also coerces numeric strings to numbers.

This code example illustrates

var foo=new Object();

foo["111_"] = 1;
foo["222_"] = 2;
foo["333_"] = 3;
foo["444"] = 4;
foo["555"] = 5;
foo["666"] = 6;

var str = "";
for (var key in foo) { 
  str = str + foo[key] + " ";
}
document.write(str);

In Chrome this prints "4 5 6 1 2 3". In IE 7, IE 8, and Firefox, it prints "1 2 3 4 5 6".

This behavior (particularly the coercion of numeric strings) has been tracked as a bug in Chrome - but unclear whether it will ever be fixed
http://code.google.com/p/chromium/issues/detail?id=37404

ECMAScript spec says "order of enumerating... is not defined"
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf