Since the intent is to access the latest snapshot of the
Application IInitializer list, why not simply have the
InitializerStringResourceLoader loadStringResource
method call
Application.get().getInitializers().
I would suggest that it is cleaner.
And, yes, I know that Java's unmodifiableList is a flawed
attempt at having a cheap mutable to immutable transformation.
Sadly, its the best Java standard library can offer.
Richard
On 02/14/2012 01:19 AM, Sven Meier wrote:
Hi Richard,
you're right, this implementation looks 'curious' but it was intentional.
Note the javadoc of Collection.unmodifiableList():
'Query operations on the returned list "read through" to the specified
list'
Sven
Am 13.02.2012 23:58, schrieb richard emberson:
While looking at the extensions code,
I noted that in the 1.5.4 InitializerStringResourceLoader
constructor that the list of IInitializer is empty but
in the InitializerStringResourceLoader loadStringResource
method there are two initializers in that same IInitializer list.
So, how can this be?
Well, in Application, first the initializers list is
wrapped in a Collections.unmodifiableList and returned
by the Application getInitializers method. This is
called when creating an instance of the InitializerStringResourceLoader.
Later, the Application load(properties) method is called
which, in turn, calls addInitializer twice which adds
two IInitializer to the Application's initializers list.
Now, the InitializerStringResourceLoader loadStringResource
is called and, behold, the InitializerStringResourceLoader
IInitializer list now has two members.
It seems that, under the covers, Application and
InitializerStringResourceLoader
share the same IInitializer list!!! This sharing is, well,
not documented, rather, its depends upon the implementation of
Collections.unmodifiableList.
So, I don't wish to criticize; maybe this was the intent;
maybe its very clever; but for me its, well, curious.
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Quis custodiet ipsos custodes
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
