JBVFS-67, VFSCacheFactory.getInstance(String defaultCacheImp

[starksm64]

I want to add a VFSCacheFactory.getInstance(String defaultCacheImpl) factory method so we can set the cache to use in the beans descriptor rather than having to set a system property. I would say this value takes precedence over the system property:

 public static VFSCache getInstance()
 {
 return getInstance(null);
 }
 public static VFSCache getInstance(String defaultCacheImpl)
 {
 if (instance == null)
 {
 synchronized (lock)
 {
 if (instance == null)
 instance = AccessController.doPrivileged(new VFSCacheCreatorAction(defaultCacheImpl));
 }
 }
 return instance;
 }

 private static class VFSCacheCreatorAction implements PrivilegedAction<VFSCache>
 {
 private String defaultCacheImpl;
 VFSCacheCreatorAction(String defaultCacheImpl)
 {
 this.defaultCacheImpl = defaultCacheImpl;
 }

 public VFSCache run()
 {
 try
 {
 String className = defaultCacheImpl;
 if(className == null)
 className = System.getProperty(VFSUtils.VFS_CACHE_KEY);
 if (className != null)
 {
 log.info("Initializing VFSCache [" + className + "] ...");
 ClassLoader cl = VFSCacheFactory.class.getClassLoader();
 Class<?> clazz = cl.loadClass(className);
 VFSCache cache = VFSCache.class.cast(clazz.newInstance());
 cache.start(); // start here, so we fall back to default no-op in case start fails
 log.info("Using VFSCache [" + cache + "] ...");
 return cache;
 }
 }
 catch (Throwable t)
 {
 log.warn("Exception instantiating VFS cache: " + t);
 }
 log.info("Using VFSCache [NoopVFSCache] ...");
 return new NoopVFSCache();
 }
 }

[alesj]

Fine by me.

[starksm64]

So are we doing another CR or putting out the GA with this issue?

[alesj]

So are we doing another CR or putting out the GA with this issue?

I'll do another CR with this addition,
as I'm doing Deployers anyway tomorrow.

So that it gets a few Hudson runs over the weekend,
probably going GA early next week.

[starksm64]

I can do the CR4 today then so I can speed up the profileservice testing.

[alesj]

I can do the CR4 today then so I can speed up the profileservice testing.

OK.
Just make sure you do 'svn update' on the branch, as I did some small re-factoring.
Not being like me on my MC CR4 release, where I forgot to pick up Kabir's changes. :-(
Re-doing the whole release.

[starksm64]

Ok, I'm in sync and I moved the completed JBVFS-66 to the CR4.

[starksm64]

Its released and used by jbossas trunk r80622 with the default vfs cache impl to org.jboss.virtual.plugins.cache.TimedVFSCache in conf/initialize.xml

[alesj]

Thinking about it, VFSCacheFactory::getInstance with just String parameter is not enough.
As some VFSCache impls have some parameters that you need to set.
e.g. LRUVFSCache needs to take min and max

I'll add VFSCacheFactory::getInstance(String, Map),
pushing that map into constructor if not null.