Sorry, I wasn't clear at all,
Consider the class in question: org.apache.stratum.jcs.JCS
protected static void ensureCacheManager()
{
if ( cacheMgr == null )
{
synchronized ( GroupCacheAccess.class )
{
if ( cacheMgr == null )
{
if ( configFilename == null )
{
cacheMgr = GroupCacheManagerFactory.getInstance();
}
else
{
cacheMgr = GroupCacheManagerFactory
.getInstance( configFilename );
}
}
}
}
}
public static void setConfigFilename( String configFilename )
{
JCS.configFilename = configFilename;
}
So we need to be able to call getFilename and then ensureCacheManager
later. Of course, there are other problems here, a change in
architecture might be a better way to work around this concern. As we
work on more runtime configuration flexibility I think we will be able
to find a better solution. For now removing the double check and making
ensureCacheManager synchronized seems like the safest option.
> > Unfortunately JCS requires predictable initialization orders in a lot of
> > these cases (things must be configured before getCacheManager is called
> > for example). I don't know how safe it is to rely on the classloader for
> > this case. It seems like we have to incur the cost of synchronizing the
> > 'ensureCacheManager' method if we want to be truly safe.
> >
> > Thanks,
> > James
>
> The initialization of the static{} is predictable. In fact, it is documented
> that it happens before the constructor is called. Read the Java language
> spec.
That can't possibly be true for a static variable. My understanding is
that static initialization is done at the time of first active use,
which is too early for the above to work unfortunately.
Clever solutions welcome of course.
-- jt
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
