<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<p><font size="+1">The primary reason JarUtils was removed is it didn't
seem to have anything to do with VFS. &nbsp; Most of the usage could be
replaced by having a standard SuffixMatchFilter containing the valid
JAR suffixes to use for matching jars.&nbsp; This is similar to the already
existing SuffixExcludeFilter named JARFilter in deployers.xml.&nbsp; This
could then be injected into whatever components need it in a similar
fashion to JARFilter.&nbsp; 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.</font></p>
<font size="+1">There was some discussion on this --&gt;
<a class="moz-txt-link-freetext" href="http://community.jboss.org/thread/148212">http://community.jboss.org/thread/148212</a><br>
<br>
<br>
<br>
</font>On 3/10/10 5:15 AM, Ales Justin wrote:
<blockquote cite="mid:E19014B3-E979-4F21-B1A3-65D55C6FB1C3@gmail.com"
 type="cite">
  <pre wrap="">Previous 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 &amp;&amp; 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:

  </pre>
  <blockquote type="cite">
    <pre wrap="">I suppose you could control that from conf/jboss-service.xml?

Still it's a different behavior, as you suggest


&lt;server&gt;

   &lt;!-- Load all jars from the JBOSS_HOME/server/&lt;config&gt;/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
   --&gt;
   &lt;classpath codebase="${jboss.server.lib.url}" archives="*"/&gt;
   &lt;classpath codebase="${jboss.common.lib.url}" archives="*"/&gt;


Jaikiran Pai wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">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 
<a class="moz-txt-link-freetext" href="file:/NotBackedUp/jpai/business/jboss/wc/jbossas/trunk/build/target/jboss-6.0.0-SNAPSHOT/common/lib/jboss-ejb3-core.jar.orig.bak/">file:/NotBackedUp/jpai/business/jboss/wc/jbossas/trunk/build/target/jboss-6.0.0-SNAPSHOT/common/lib/jboss-ejb3-core.jar.orig.bak/</a>]

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
<a class="moz-txt-link-abbreviated" href="mailto:jboss-development@lists.jboss.org">jboss-development@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/jboss-development">https://lists.jboss.org/mailman/listinfo/jboss-development</a>
      </pre>
    </blockquote>
    <pre wrap="">_______________________________________________
jboss-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:jboss-development@lists.jboss.org">jboss-development@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/jboss-development">https://lists.jboss.org/mailman/listinfo/jboss-development</a>
    </pre>
  </blockquote>
  <pre wrap="">

_______________________________________________
jboss-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:jboss-development@lists.jboss.org">jboss-development@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/jboss-development">https://lists.jboss.org/mailman/listinfo/jboss-development</a>
  </pre>
</blockquote>
<br>
</body>
</html>