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

[John Bailey]

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/148212



On 3/10/10 5:15 AM, Ales Justin wrote:
> 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
>>      
>
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-development/attachments/20100310/f1d15e93/attachment.html