This content has been marked as final.
Show 8 replies
-
1. Re: VFS and JBossAS initialization
adrian.brock Nov 3, 2008 10:29 AM (in response to alesj)"alesj" wrote:
In order to speed/cache things up, I suggest the following addition:
bootstrap.xml<bootstrap xmlns="urn:jboss:bootstrap:1.0"> <url>initialize.xml</url> <url>classloader.xml</url>
Where initialize.xml would look like:<!-- The JBossAS initializer configuration. --> <deployment xmlns="urn:jboss:bean-deployer:2.0"> <bean name="VFSCache"> <constructor factoryClass="org.jboss.virtual.spi.cache.VFSCacheFactory" factoryMethod="getInstance"/> <uninstall method="stop"/> </bean> <bean name="JBossVFSInitializer" class="org.jboss.virtual.plugins.cache.PreInitializeVFSContexts"> <property name="initializedVFSContexts"> <list elementClass="java.net.URL"> <value>${jboss.lib.url}</value> <value>${jboss.server.lib.url}</value> </list> </property> </bean> <bean name="SingletonSchemaResolverFactory" class="org.jboss.xb.binding.sunday.unmarshalling.SingletonSchemaResolverFactory"> <constructor factoryClass="org.jboss.xb.binding.sunday.unmarshalling.SingletonSchemaResolverFactory" factoryMethod="getInstance"/> <install method="addJaxbSchema"> <parameter>urn:jboss:caching-classloader:1.0</parameter> <parameter>org.jboss.classloading.spi.vfs.metadata.CachingVFSClassLoaderFactory10</parameter> </install> </bean> </deployment>
The first bean just says we should stop cache after we're done.
The 2nd one pre-initializes some of the most commonly used vfs roots,
hence pushing matching contexts into vfs cache.
The last is VFSClassLoaderFactory metadata that works off the vfs cache.
Why CachingVFSClassLoaderPolicy?
Remember our isA/hasA discussion?
Is a vfs classloader policy a vfs cache or can a vfs classloader policy
have a vfs cache?
If like me you think it is the latter then it is not a subclass it is a property
(although you might conceivable temporarily subclass to experiment with
adding the property).
The scalability problem of maintaining and supporting a whole new schema should be
a warning sign. Are you going to create a new schema for every new feature?
I'm already running this, which results in this minimal cache:
- http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186390#4186390
What do you think? -
2. Re: VFS and JBossAS initialization
adrian.brock Nov 3, 2008 10:37 AM (in response to alesj)Also, I think you're trying to solve the problem at the wrong level.
As we discussed before when I put the original VFS file caching in the
VFSClassLoaderPolicy, this was just a temporary workaround because
the VFS didn't have such behaviour itself. -
3. Re: VFS and JBossAS initialization
alesj Nov 3, 2008 3:27 PM (in response to alesj)"adrian@jboss.org" wrote:
Is a vfs classloader policy a vfs cache or can a vfs classloader policy
have a vfs cache?
I didn't want to change current impl at the following code:/** * Get virtual file for uri. * * @param uri the uri * @return virtual file for uri * @throws Exception for any error */ protected VirtualFile getVirtualFile(URI uri) throws Exception { return VFS.getRoot(uri); }
instead doing an override that uses the newly added caching VirtualFile instance re-usability:protected VirtualFile getVirtualFile(URI uri) throws Exception { return VFS.getCachedFile(uri); }
Perhaps I can use VFS::getCachedFile directly in the original impl?
Hence no need for the additional class.
VFS::getCachedFile:/** * Get cached file. * * If VFSContext matching the rootURL parameter is cached * this method will return cached virtual file * else it will use VFS::getRoot(rootURL). * * @param rootURL the root url * @return the cached virtual file * @throws IOException for any error * @throws IllegalArgumentException if the rootURL is null */ public static VirtualFile getCachedFile(URL rootURL) throws IOException { VFSCache cache = VFSCacheFactory.getInstance(); return cache.getFile(rootURL); }
-
4. Re: VFS and JBossAS initialization
adrian.brock Nov 4, 2008 8:43 AM (in response to alesj)Why isn't this just based on the isCachable() attribute?
-
5. Re: VFS and JBossAS initialization
alesj Nov 4, 2008 8:58 AM (in response to alesj)"adrian@jboss.org" wrote:
Why isn't this just based on the isCachable() attribute?
Dunno. Probably just some temp hype with super classing everything. :-)
I'll add this, making it true by default.
I think this kind of URI --> VirtualFile code should mostly use this newly added VFS::getCachedFile method.
Unless you're really sure you need to create new VFSContext (that's what VFS::getRoot does)
or you're absolutely sure this resource is not cached, hence introducing performance impact, you should use the old way. -
6. Re: VFS and JBossAS initialization
adrian.brock Nov 4, 2008 9:20 AM (in response to alesj)It already exists it comes from the ClassLoadingMetaData
It specifies whether you are allowed to cache resource hits, i.e. whether resources
could disappear at random.
I agree its probably not relevant for the roots of the vfs classloader
since they have to exist (see determineVFSRoots): -
7. Re: VFS and JBossAS initialization
alesj Nov 4, 2008 9:26 AM (in response to alesj)"adrian@jboss.org" wrote:
I agree its probably not relevant for the roots of the vfs classloader
since they have to exist (see determineVFSRoots):
Yeah, it's not really related, but I guess we can re-use it. -
8. Re: VFS and JBossAS initialization
alesj Nov 4, 2008 9:30 AM (in response to alesj)"alesj" wrote:
Yeah, it's not really related, but I guess we can re-use it.protected VirtualFile getVirtualFile(URI uri) throws Exception { if (isCacheable()) return VFS.getCachedFile(uri); else return VFS.getRoot(uri); }