[jboss-dev] VFS3 (in AS trunk) - Non .jar file handling

[Ales Justin]

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 && 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development