The primary reason JarUtils was removed is it didn't seem to have anything to do with VFS. Most of the usage could be replaced by having a standard SuffixMatchFilter containing the valid JAR suffixes to use for matching jars. This is similar to the already existing SuffixExcludeFilter named JARFilter in deployers.xml. This could then be injected into whatever components need it in a similar fashion to JARFilter. If having static access to the filter or the suffixes is required, then something could get resurrected in deployers, since that seems to be the most fitting place.
There was some discussion on this --> http://community.jboss.org/thread/148212Previous VFS2 used JarUtils, which contained known archive suffixes. If the file didn't match any of those, it was considered plain file (not-archive). So no zip-handling context was created on top, hence no found inner entries. New VFS3 has no JarUtils anymore, and it's this code in VFSClassLoaderClassPathDeployer if (canSeeParent == false || (canSeeParent && parentClassPath.contains(file) == false)) { try { Automounter.mount(unit.getRoot(), file); } that mounts your .bak archive -- since "*" was used to filter the contents of jboss-service'xml' classpath. Putting "*.jar" there should fix your problem -- dunno if this should be the proper fix? On Mar 10, 2010, at 11:46 AM, Dimitris Andreadis wrote:I suppose you could control that from conf/jboss-service.xml? Still it's a different behavior, as you suggest <server> <!-- Load all jars from the JBOSS_HOME/server/<config>/lib directory and the shared JBOSS_HOME/common/lib directory. This can be restricted to specific jars by specifying them in the archives attribute. TODO: Move this configuration elsewhere --> <classpath codebase="${jboss.server.lib.url}" archives="*"/> <classpath codebase="${jboss.common.lib.url}" archives="*"/> Jaikiran Pai wrote:I see a new behaviour with VFS3 in JBoss AS. Earlier in AS-5/6 (with VFS2) and AS-4 (without any VFS), to try out some quick fixes, i used to rename existing jar files to end with .bak name and replace them with the new patched jar file. So for example, if i had a fix in jboss-ejb3-core.jar, i would: 1) Rename the JBOSS_HOME/common/lib/jboss-ejb3-core.jar to JBOSS_HOME/common/lib/jboss-ejb3-core.jar.orig.bak 2) Place a patched jboss-ejb3-core.jar in JBOSS_HOME/common/lib 3) Restart the server The server would then pickup the new patched jar file and ignore the .bak file. After testing the fix, i would then revert back to the original jar file by renaming it back to its original name. However, with the recent upgrade to VFS3 in AS trunk, i notice that even the .bak is used for classloading (following is the output from -verbose:class JVM argument): [Loaded org.jboss.ejb3.EJBContainer from file:/NotBackedUp/jpai/business/jboss/wc/jbossas/trunk/build/target/jboss-6.0.0-SNAPSHOT/common/lib/jboss-ejb3-core.jar.orig.bak/] Looks like VFS3 picks up this non .jar suffix file for classloading. Is this expected? Shouldn't it be looking for only .jar files (atleast in this context)? regards, -Jaikiran _______________________________________________ jboss-development mailing list jboss-development@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development_______________________________________________ jboss-development mailing list jboss-development@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development_______________________________________________ jboss-development mailing list jboss-development@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development