Silly me, I totally overlooked the `synchronized` keyword on this method.  Right, not a double checked locking anti-pattern.

Yeah, so long as the skin information is being stored in portlet preferences, it's not going to be much fun trying to do more at context initialization time.  That's part of what's driving my feeling that this wants to be an object model with its own DAO and JPA persistence and so forth.  More a real part of uPortal-the-container and less down-inside-a-portlet.  No doubt can still have a `SkinCssIncorporationPortlet` and a `SkinManagementPortlet` as UIs for making use of, administering skins even with moving some of the skin implementation up into the portal and not so much down inside a portlet.  But if the portal had everything it needed to poke a `SkinDao` to grab all the skins, LESS->CSS them all, at context init time, we might be in business in getting that work done at uPortal context init time rather than at render time.  Could then use uPortal's jGroups cache invalidation strategy for propagating change throughout the cluster -- editing via portlet on uPortal node 2 would update and persist via JPA down to uPortal database, then fire jGroup cache invalidation message to invalidate caches on other uPortal nodes 1, 3, ..n, which nodes would then pull from database.  Finally, get some kind of proactive cache re-population going on invalidate, and could get the runtime recompiles happening asynchronously from rendering as well.