IUserLayout declares a method getCacheKey() that isn't called anywhere.
In AggregatedLayouts, this is implemented via a uPortal-custom
GuidGenerator class, in which I think I've found a threadsafety bug:
http://www.ja-sig.org/issues/browse/UP-1804
In SimpleLayout, getCacheKey always returns null.
Since the only use of GuidGenerator is for ALM implementation of
getCacheKey(), and since nothing calls getCacheKey(), my proposal at
this point is to eliminate all of these -- GuidGenerator, the
getCacheKey() method declaration on IUserLayout, the getCacheKey()
implementation in SimpleLayout, and the getCacheKey() implementation in ALM.
http://www.ja-sig.org/issues/browse/UP-1805
Eliminating classes and interface methods in a patches branch is
normally not allowed in consideration of "backwards compatibility".
Given that nothing is calling this code and if anything did call this
code, it would get IDs of questionable uniqueness, how do we uPortal
developers feel about making an exception here and eliminating this
baggage in the active patches branches as well as /trunk?
Andrew
--
You are currently subscribed to [email protected] as: [EMAIL
PROTECTED]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev